# TakeInterest Web & iOS ADA / Accessibility Checklist (WCAG 2.1/2.2 AA)

Effective date: January 7, 2026
Last updated: January 7, 2026

Purpose: Provide a thorough, repeatable checklist for ADA-aligned accessibility across web and iOS. Target conformance is WCAG 2.1 AA (required) and WCAG 2.2 AA (recommended). Use this for design, implementation, QA, and release sign-off.

How to use:
- Mark each item as Pass/Fail/NA and record evidence (screenshots, URLs, issue IDs).
- If an item is NA, document why and confirm there is no equivalent functionality.
- Any Fail item requires an owner and remediation plan before release.

Scope:
- All public pages, authenticated flows, marketing pages, onboarding, settings, account, checkout/subscription, and help content.
- Web app (Next.js) and embedded widgets, if any.
- iOS app (SwiftUI/UIKit) including all screens, navigation, and system integrations.
- Third-party content that ships with the product (React Flow, Firebase Auth, etc.).
- Exported content (PDFs, CSVs) where applicable.

Conformance target:
- WCAG 2.1 AA required.
- WCAG 2.2 AA recommended (Target Size, Focus Appearance, Dragging, Accessible Authentication, Focus Not Obscured).
- Apple Human Interface Guidelines for iOS accessibility.

Release gate (must pass before launch):
- Keyboard-only navigation for all tasks (web).
- VoiceOver can complete core flows (web + iOS).
- Visible focus indicator everywhere (web).
- Text scaling to 200% without loss of content/function (web).
- Dynamic Type supported at all sizes (iOS).
- Color contrast for text and UI components meets AA.
- Screen reader announces correct names/roles/states for all controls.
- Terms and Privacy are accessible from sign-up and footer; consent required before account creation.

## 1) Perceivable

Text alternatives
- [ ] All informative images have meaningful alt text.
- [ ] Decorative images use empty alt ("") or CSS background; no redundant announcements.
- [ ] Icon-only controls include accessible labels (aria-label or visible text).
- [ ] Complex images (charts/diagrams) have text summaries or data tables.
- [ ] CAPTCHA alternatives are accessible or offer audio/text alternatives.

Time-based media
- [ ] Videos have accurate captions for speech and relevant sound effects.
- [ ] Audio-only media has transcripts.
- [ ] Video players are keyboard accessible and expose play/pause/seek states.
- [ ] Autoplay media is avoided or can be paused/stopped.

Adaptable content
- [ ] Semantic headings (h1-h6) are in logical order.
- [ ] Lists, tables, and landmarks use correct HTML semantics.
- [ ] Reading order matches visual order (no CSS order issues).
- [ ] Forms have programmatic labels and associated instructions.
- [ ] Content does not restrict display to single orientation (WCAG 1.3.4).

Distinguishable
- [ ] Text contrast >= 4.5:1 for normal text; >= 3:1 for large text.
- [ ] Non-text UI components contrast >= 3:1 against adjacent colors.
- [ ] Color is not the only way to convey meaning (errors, status, charts).
- [ ] Content reflows at 320px wide with no horizontal scroll (except data tables).
- [ ] Text can be resized to 200% without loss of content/function.
- [ ] Text spacing can increase (line-height 1.5, letter-spacing 0.12em, word-spacing 0.16em) without breakage.
- [ ] Content on hover/focus remains visible until dismissed and is keyboard reachable.
- [ ] No flashing content above 3 flashes/second.

## 2) Operable

Keyboard access
- [ ] All interactive elements are reachable by keyboard (Tab/Shift+Tab).
- [ ] No keyboard traps; focus can move in/out of components.
- [ ] Custom components have proper focus handling and keyboard interactions.
- [ ] Skip-to-content link exists and is visible on focus.

Focus management
- [ ] Focus order is logical and matches reading order.
- [ ] Visible focus indicators meet AA (not removed by CSS).
- [ ] Focus moves into modals/drawers and is trapped within until closed.
- [ ] On close, focus returns to the trigger or logical element.
- [ ] SPA route changes announce page title and move focus to main heading.
- [ ] Focus is not obscured by sticky headers/footers (WCAG 2.2 2.4.11).
- [ ] Focus indicator has sufficient area and contrast (WCAG 2.2 2.4.13).

Pointer and gesture access
- [ ] Multi-point or path-based gestures have simple alternatives.
- [ ] Drag-and-drop has keyboard or alternative input.
- [ ] Pointer cancellation is supported (no immediate action on down).
- [ ] Target size >= 44x44 CSS px for primary controls (WCAG 2.2).
- [ ] No unexpected actions on hover or focus.

Timing
- [ ] Timeouts are avoidable, extendable, or have warning prompts.
- [ ] Auto-advancing content can be paused or stopped.
- [ ] Sessions allow saving progress where possible.

Seizure and physical reactions
- [ ] No flashing above threshold.
- [ ] Motion/animation respects reduced-motion settings.

## 3) Understandable

Readable content
- [ ] Page language is declared (html lang).
- [ ] Language changes within content are marked (lang attributes).
- [ ] Acronyms and jargon are expanded on first use.

Predictable UI
- [ ] Navigation structure is consistent across pages.
- [ ] Components behave consistently (buttons, links, menus).
- [ ] Unexpected context changes do not occur without user action.

Input assistance
- [ ] Every input has a visible label; placeholders are not labels.
- [ ] Required fields are clearly indicated and programmatically conveyed.
- [ ] Error messages identify the field and the issue.
- [ ] Errors are announced to screen readers (aria-live).
- [ ] Suggestions for fixing errors are provided.
- [ ] Form submission errors move focus to the first error summary.
- [ ] For legal/financial submissions, confirmation and reversal options exist.
- [ ] Input autocomplete uses correct tokens (autocomplete="email", etc.).
- [ ] Consent checkboxes (Terms/Privacy) are required and not pre-checked.
- [ ] Consent text references the same policy versions shown in the links.
- [ ] Authentication does not require cognitive function tests (WCAG 2.2 3.3.8).
- [ ] Copy-paste allowed for verification codes and passwords.
- [ ] Previously entered information is not required again in same session (WCAG 2.2 3.3.7).
- [ ] Help mechanisms (contact, FAQ) are consistent across pages (WCAG 2.2 3.2.6).

## 4) Robust

Semantic structure and ARIA
- [ ] Use native HTML elements when possible (button, a, input).
- [ ] ARIA is used only when needed; no invalid roles/attributes.
- [ ] Accessible name, role, value are exposed for custom controls.
- [ ] Interactive elements are not nested improperly (button in link, etc.).
- [ ] Unique IDs for aria-labelledby/aria-describedby references.
- [ ] Status messages use aria-live or role="status".

Compatibility
- [ ] Works with current Chrome, Firefox, Safari, and Edge.
- [ ] Screen reader support validated (NVDA/JAWS on Windows, VoiceOver on macOS/iOS).

## 5) Content and Layout Patterns

Navigation and structure
- [ ] Landmarks present: header, nav, main, footer, and search if applicable.
- [ ] Breadcrumbs are accessible and announced.
- [ ] Headings summarize sections and avoid skipping levels.

Links and buttons
- [ ] Link text is descriptive out of context.
- [ ] Buttons are used for actions; links are used for navigation.
- [ ] External links warn users (aria-label or visible text).
- [ ] Icon buttons include accessible labels and states.

Forms and validation
- [ ] Error messages are tied to fields via aria-describedby.
- [ ] Validation does not rely solely on color.
- [ ] Inline help is accessible and announced as needed.

Legal and consent
- [ ] Terms and Privacy links are visible, keyboard reachable, and screen-reader friendly.
- [ ] Consent checkbox label is descriptive and announced as required.
- [ ] Users can access policies without losing form state.

Tables and data
- [ ] Tables use th and scope or headers/id associations.
- [ ] Sort controls are accessible and announce sort order.
- [ ] Large datasets have pagination or filters that are keyboard friendly.

Charts and data visualization
- [ ] Provide text summaries or data tables.
- [ ] Legends are accessible; color is not sole encoding.
- [ ] Zoom and tooltip content is keyboard accessible.

Notifications and toasts
- [ ] Announced to screen readers (aria-live polite or assertive).
- [ ] Dismiss buttons are keyboard reachable.

Modals, drawers, and popovers
- [ ] Role="dialog" or "alertdialog" with aria-labelledby.
- [ ] Focus management handled on open/close.
- [ ] Escape closes modal if appropriate.
- [ ] Background is not focusable while modal is open.

## 6) Visual Design Checklist

Typography and spacing
- [ ] Body text size is readable (>= 16px recommended).
- [ ] Line length is reasonable (45-90 characters).
- [ ] Text is not justified if it harms readability.

Color and contrast
- [ ] Contrast meets AA for all text and key UI.
- [ ] Focus states have strong contrast.
- [ ] Disabled states are distinguishable without relying only on color.

## 7) Engineering Checklist

Code-level checks
- [ ] eslint-plugin-jsx-a11y enabled and passing (if React/Next).
- [ ] No console warnings about invalid ARIA attributes.
- [ ] Keyboard events mirror pointer events for custom controls.
- [ ] aria-hidden is not used on focusable elements.
- [ ] Hidden content is not focusable.

SPA behavior
- [ ] Route changes update document title.
- [ ] Skip link targets main content.
- [ ] Focus is managed on route change or significant updates.

Performance and UX
- [ ] Content remains accessible during loading (skeletons are not focus traps).
- [ ] Loading states are announced (aria-busy/aria-live).

## 8) QA Test Plan (Manual)

Keyboard-only pass
- [ ] Complete sign-in/sign-up flows.
- [ ] Complete primary task flow (core feature).
- [ ] Settings/account changes.
- [ ] Form submission and error correction.

Screen reader pass
- [ ] VoiceOver (macOS Safari) on key flows.
- [ ] NVDA (Windows Firefox/Chrome) on key flows.
- [ ] Form fields announced with labels, errors, and required state.
- [ ] Charts and complex controls are understandable.

Zoom and reflow
- [ ] Browser zoom 200% and 400% (or 320px viewport).
- [ ] No overlap or clipped content; horizontal scroll avoided.

Contrast checks
- [ ] Use a contrast tool on primary text, buttons, and iconography.

Reduced motion/contrast
- [ ] Reduce Motion enabled: animations reduced and not required.
- [ ] High contrast mode (where supported) remains usable.

## 9) Known Exceptions and Risks

- [ ] Document any third-party widgets that do not meet AA.
- [ ] Provide fallback or alternative access where possible.
- [ ] Track all exceptions with owner and remediation target date.

## 10) Accessibility Statement (Recommended)

- [ ] Provide an accessibility statement page with contact method.
- [ ] Offer an accessible feedback channel (email/form).
- [ ] Track and respond to accessibility issues with SLA.

## 11) iOS App Accessibility (Apple HIG)

VoiceOver support
- [ ] All interactive elements have accessibilityLabel set.
- [ ] Buttons and controls have accessibilityHint for non-obvious actions.
- [ ] Custom views set isAccessibilityElement = true where appropriate.
- [ ] Correct accessibilityTraits applied (.button, .header, .selected, .adjustable, etc.).
- [ ] Grouped elements use accessibilityElements for logical ordering.
- [ ] Images have accessibilityLabel or are marked as decorative (isAccessibilityElement = false).
- [ ] Tables and lists announce row count and position.

Dynamic Type
- [ ] All text scales with system Dynamic Type settings.
- [ ] Layout adapts without truncation at largest accessibility sizes (AX1-AX5).
- [ ] Custom fonts use UIFontMetrics for scaling.
- [ ] Tested at default, Large, and AX5 sizes.

Switch Control and Voice Control
- [ ] All controls reachable via Switch Control scanning.
- [ ] Controls have unique accessible names for Voice Control commands.
- [ ] No gestures that cannot be performed via Switch Control.

System accessibility settings
- [ ] Reduce Motion respected (UIAccessibility.isReduceMotionEnabled).
- [ ] Bold Text setting supported.
- [ ] Increase Contrast mode does not break legibility.
- [ ] Smart Invert and Classic Invert do not break images or icons.
- [ ] Reduce Transparency respected where applicable.

Touch targets
- [ ] Minimum 44x44pt tap targets for all interactive elements (Apple HIG).
- [ ] Adequate spacing between adjacent tap targets.

Navigation and focus
- [ ] VoiceOver rotor headings navigate correctly between sections.
- [ ] Magic tap (two-finger double-tap) triggers primary action if applicable.
- [ ] Escape gesture (two-finger Z) dismisses modals and popovers.
- [ ] Focus moves logically when views appear/disappear.
- [ ] Alerts and sheets are announced immediately.

## 12) Automated Testing

CI/CD integration
- [ ] axe-core or Lighthouse accessibility audit runs on every PR (web).
- [ ] eslint-plugin-jsx-a11y rules enforced with zero violations (web).
- [ ] Accessibility audit failures block merge.
- [ ] Xcode Accessibility Inspector used during development (iOS).
- [ ] XCTest accessibility audits integrated where supported (iOS).

Recommended tools
- [ ] axe DevTools browser extension for manual checks.
- [ ] Chrome DevTools Accessibility panel.
- [ ] Firefox Accessibility Inspector.
- [ ] Xcode Accessibility Inspector (iOS).
- [ ] Accessibility Insights for Web.

Regression tracking
- [ ] Baseline accessibility score recorded.
- [ ] Score changes tracked over time.
- [ ] New violations require owner and remediation plan.

## 13) PDF and Export Accessibility

PDF exports
- [ ] Exported PDFs are tagged for screen readers (PDF/UA).
- [ ] Reading order in PDF matches visual order.
- [ ] Images in PDF have alt text.
- [ ] Tables in PDF are properly structured with headers.
- [ ] Document title and language are set in PDF metadata.
- [ ] Links in PDF are navigable and have descriptive text.

Other exports (CSV, Markdown, RTF)
- [ ] CSV exports include header row for column identification.
- [ ] Markdown exports use semantic headings and lists.
- [ ] RTF exports preserve document structure.

## 14) Third-Party Component Accessibility

Known third-party components
- [ ] React Flow (Graph Explorer): Verify keyboard navigation and screen reader support.
- [ ] Firebase Auth UI: Verify form accessibility and error announcements.
- [ ] Any embedded iframes: Document accessibility status and alternatives.

Third-party audit process
- [ ] Each third-party component has documented accessibility status.
- [ ] Components with known issues have workarounds or alternatives.
- [ ] Vendor accessibility roadmaps tracked for components with gaps.
- [ ] Fallback content provided where third-party fails accessibility.

## 15) Mobile Web Considerations

Touch and gesture
- [ ] Touch targets minimum 48x48 CSS px on mobile (Android guidance).
- [ ] No hover-only interactions on touch devices.
- [ ] Pinch-to-zoom not disabled (viewport meta).
- [ ] Scroll containers are touch-scrollable.

Responsive design
- [ ] Content readable at 320px viewport width.
- [ ] No horizontal scroll except for data tables.
- [ ] Form inputs do not trigger unwanted zoom on iOS (min 16px font).
- [ ] Virtual keyboard does not obscure focused input.

Screen reader (mobile)
- [ ] VoiceOver on iOS Safari tested for key flows.
- [ ] TalkBack on Android Chrome tested for key flows.
- [ ] Touch exploration works correctly on all interactive elements.