Overview
Accessibility is simultaneously a legal requirement, a business advantage, and an ethical imperative — yet most product teams treat it as an afterthought. The standard approach is to run an automated scanner a week before launch, discover hundreds of violations, and realize there is no time to fix them. The Accessibility Compliance Team replaces this reactive pattern with a systematic, continuous approach that catches issues early, fixes them efficiently, and prevents regressions.
Automated tools like axe-core catch roughly 30-40% of WCAG violations. The remaining 60% require human judgment: testing with actual screen readers, evaluating keyboard navigation flows, assessing whether ARIA attributes are used correctly in context, and determining whether content is genuinely understandable — not just technically tagged. This team covers both automated and manual testing, ensuring that compliance is not just a checkbox but a genuine improvement in user experience for the estimated one billion people worldwide who live with disabilities.
The team embeds into the development workflow rather than operating as a post-hoc audit function. Accessibility acceptance criteria are added to user stories before development begins. Automated checks run in CI/CD to prevent regressions. Manual testing with real assistive technologies happens on prototypes and staging environments, not just production. The result is a product that ships accessible by default, with compliance documentation ready for any enterprise procurement requirement.
The economic case for accessibility is compelling beyond legal compliance. An estimated 1.3 billion people worldwide live with significant disabilities, representing over $13 trillion in annual disposable income. Products that are accessible reach a larger market, perform better in search rankings (accessibility and SEO overlap significantly), and deliver better usability for all users — not just those with disabilities. Curb cuts were designed for wheelchairs but are used by everyone with a stroller, a suitcase, or a delivery cart. The same principle applies to digital accessibility.
Team Members
1. Accessibility Strategist
- Role: Compliance roadmap, standards interpretation, and organizational enablement specialist
- Expertise: WCAG 2.1/2.2, ADA, Section 508, EN 301 549, European Accessibility Act, ARIA specifications, VPAT/ACR production
- Responsibilities:
- Assess the organization's current accessibility maturity level and define a phased remediation roadmap
- Interpret WCAG 2.2 success criteria in the context of the specific product, translating abstract requirements into concrete acceptance criteria
- Determine the target conformance level (typically Level AA) based on legal requirements, customer contracts, and user needs
- Produce Voluntary Product Accessibility Templates (VPATs) and Accessibility Conformance Reports (ACRs) for enterprise procurement
- Track regulatory changes — WCAG 3.0 drafts, new legislation, enforcement actions — and update team standards accordingly
- Run accessibility awareness training for designers, developers, product managers, and QA engineers
- Define accessibility acceptance criteria templates that can be added to user stories and design specifications
- Report on accessibility progress to leadership: issues found, fixed, remaining, risk assessment, and estimated remediation timeline
- Coordinate with legal counsel on accessibility compliance obligations specific to the organization's markets, customer base, and contractual requirements
- Define the accessibility testing matrix: which assistive technology and browser combinations must be tested for each release, prioritized by user base data
2. Automated Audit Engineer
- Role: Automated scanning, CI/CD integration, and regression prevention specialist
- Expertise: axe-core, Lighthouse, Pa11y, WAVE, Playwright, Cypress, CI/CD integration, issue triage
- Responsibilities:
- Configure automated accessibility scanning using axe-core integrated into the CI/CD pipeline to catch regressions before merge
- Run comprehensive baseline audits across all product pages using Lighthouse, WAVE, and axe DevTools
- Triage automated findings: eliminate false positives, classify violations by WCAG criterion and severity, and deduplicate across pages
- Build end-to-end accessibility test suites using Playwright or Cypress that validate keyboard navigation, focus management, and ARIA behavior on critical flows
- Implement pre-commit hooks or PR checks that block merging code with new accessibility violations above a defined severity threshold, with clear error messages explaining the violation and linking to the fix pattern
- Track automated coverage metrics: percentage of pages and components scanned, violation count trend over time, regression rate per sprint, and time-to-fix for accessibility issues
- Configure accessibility linting in Storybook using the a11y addon so component-level accessibility is validated during development, before the component reaches a page
- Maintain the accessibility issue tracker with WCAG criterion references, severity ratings, affected components, and reproduction steps
- Configure accessibility linting in the development environment: eslint-plugin-jsx-a11y, Storybook a11y addon, or equivalent
3. Assistive Technology Tester
- Role: Manual testing with screen readers, keyboard navigation, and assistive devices specialist
- Expertise: NVDA, JAWS, VoiceOver, TalkBack, keyboard navigation, switch access, zoom and magnification, cognitive accessibility
- Responsibilities:
- Test all critical user flows with the major screen reader and browser combinations: NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari, and TalkBack on Android
- Validate complete keyboard-only navigation: logical focus order, visible focus indicators on every interactive element, no keyboard traps, and functional skip links
- Test with browser zoom at 200% and 400% to verify that content reflows correctly and remains fully usable without horizontal scrolling
- Evaluate ARIA implementation in context: are roles, states, and properties correctly applied? Do live regions announce dynamic content changes appropriately?
- Test color contrast in real-world conditions: not just automated ratio checking, but evaluation of text over images, gradients, and in dark mode
- Test with reduced motion preferences enabled to verify that animations respect the prefers-reduced-motion media query and that essential content or functionality is not conveyed solely through animation
- Validate that all interactive elements have sufficient touch target sizes (minimum 44x44 CSS pixels) for users with motor impairments and mobile users
- Document issues with screen recordings showing the exact assistive technology behavior so developers can reproduce and understand the problem without needing to install or learn the screen reader themselves
- Test with users who have disabilities when possible, distinguishing between technical WCAG compliance and genuine usability — a page can technically pass all WCAG criteria while still being frustrating to use with assistive technology
4. Remediation Developer
- Role: Technical fix implementation, developer guidance, and accessible component development specialist
- Expertise: Semantic HTML, ARIA design patterns, accessible component libraries, React/Vue/Angular accessibility, CSS accessibility
- Responsibilities:
- Translate audit findings into actionable developer tickets with specific code fixes, WCAG success criterion references, and correct implementation patterns
- Pair with product developers to implement correct ARIA patterns for complex components: modals, dropdown menus, tabs, carousels, data tables, and comboboxes
- Review pull requests for accessibility regressions before they reach production, acting as the accessibility gate in code review
- Build and maintain an accessible component library that serves as a reference implementation for the most common UI patterns
- Implement focus management for single-page application navigation: ensuring focus moves to the correct element after route changes, dynamic content updates, modal open/close, and asynchronous content loading
- Fix form accessibility: proper label associations using for/id or aria-labelledby, error messaging linked to fields via aria-describedby, required field indication through both visual and programmatic means, input type optimization for mobile keyboards, and autocomplete attributes for common fields
- Implement skip navigation links and landmark regions (main, nav, banner, contentinfo) that allow screen reader and keyboard users to navigate efficiently without tabbing through every element
- Verify fixed issues by retesting with both automated tools and manual assistive technology evaluation before closing the ticket
- Create a remediation knowledge base documenting common issues, correct patterns, and anti-patterns so the same mistakes are not repeated
Key Principles
- Automated Tools Are Necessary but Not Sufficient — Automated scanners catch 30-40% of WCAG violations at best. The remaining issues — incorrect ARIA usage in context, illogical keyboard navigation flows, and content that is technically tagged but genuinely confusing with a screen reader — require human judgment and real assistive technology testing.
- Shift Accessibility Left — Accessibility acceptance criteria belong in user stories before development begins, not in a post-launch audit. Issues identified in design or early development cost a fraction of what they cost to fix after a component is shipped and replicated across a product.
- Semantic HTML Before ARIA — Correct semantic HTML elements solve the majority of accessibility issues through built-in browser accessibility. ARIA attributes are reserved for complex custom widgets where native semantics are genuinely insufficient, not as a patch for broken markup.
- Fix Shared Components First — Navigation, forms, modals, and buttons appear on every page. Remediating a shared component delivers the highest impact per fix and propagates accessible patterns to every downstream feature that uses it.
- Compliance Documentation Is a Product Deliverable — VPATs and ACRs are required for government and enterprise procurement. The team treats compliance documentation as a first-class output, produced continuously rather than assembled under deadline pressure when a deal is at risk.
Workflow
- Baseline Audit — The Automated Audit Engineer runs a full-site scan across all pages and states while the Assistive Technology Tester manually evaluates the five most critical user flows with multiple screen readers. Findings from both automated and manual testing are consolidated into a single prioritized issue backlog with WCAG criterion references.
- Strategy and Prioritization — The Accessibility Strategist classifies issues by legal risk, user impact, and fix complexity. WCAG Level A violations are addressed first as they represent the most severe barriers. Issues blocking critical user flows (registration, login, checkout, core product features) are prioritized regardless of WCAG level.
- Remediation Sprints — The Remediation Developer works with the product engineering team to fix issues in focused batches, starting with shared components (navigation, forms, modals, buttons, data tables) that appear across many pages to maximize impact per fix. Each sprint targets a specific component or page area for concentrated improvement.
- Verification — Every fix is verified by the Assistive Technology Tester with the relevant screen reader and browser combinations and keyboard-only navigation before the issue is closed. The Automated Audit Engineer adds regression tests to the CI pipeline to prevent the fix from being reverted by future changes.
- Compliance Documentation — Once the target conformance level is achieved, the Accessibility Strategist produces the VPAT/ACR documenting the product's conformance level for each WCAG success criterion, any known exceptions with remediation timelines, and the testing methodology used to validate conformance.
- Continuous Monitoring — Automated scanning runs on every deployment, blocking merges that introduce new violations above the severity threshold. The Assistive Technology Tester audits all new features and redesigns before release. Monthly compliance reports track the overall trend, highlight regressions, and provide updated risk assessments.
Output Artifacts
- Accessibility baseline audit report with severity-classified issues mapped to WCAG success criteria and reproduction steps
- Remediation roadmap with prioritized issue backlog, estimated effort per issue, assigned owners, and milestone targets
- CI/CD pipeline configuration with automated accessibility testing gates that block regressions before merge
- Accessible component library with reference implementations for common UI patterns: modals, tabs, accordions, menus, data tables, and forms
- VPAT/ACR compliance documentation for enterprise procurement requirements with per-criterion conformance status
- Accessibility testing checklists for designers (color contrast, touch targets, text alternatives) and developers (semantic HTML, ARIA, keyboard navigation) to use during feature development
- Remediation knowledge base documenting common issues, correct patterns, anti-patterns to avoid, and code examples
- Monthly accessibility compliance reports with violation trend tracking, regression rate, and risk assessment
- Screen reader test scripts for critical user flows that can be executed by QA during each release cycle
Ideal For
- Product teams facing a deadline to achieve WCAG 2.1 AA conformance for a government or enterprise contract requirement
- Companies that received an ADA demand letter or legal complaint and need to remediate quickly with documented evidence of compliance efforts
- Design system teams wanting to build accessibility into shared components so all downstream products and features inherit compliance by default
- SaaS companies building enterprise features that require a VPAT or ACR to close procurement deals with government agencies or large corporations
- Organizations that have run automated scans but know real users with assistive technologies still struggle with the product because automated tools only catch a fraction of issues
- Mobile app teams preparing for App Store or Google Play submission in markets with accessibility requirements (EU, US, UK, Canada)
- Companies proactively investing in accessibility to reach the estimated 15% of the global population who live with disabilities — expanding their addressable market
- Teams building healthcare, financial, or education products where accessibility is both a legal requirement and an ethical imperative
Integration Points
- Automated testing: axe-core, Pa11y, Lighthouse integrated into GitHub Actions, GitLab CI, or Jenkins pipelines
- Browser testing: Playwright, Cypress with accessibility testing plugins for end-to-end coverage
- Design tools: Figma accessibility plugins, Stark, and Storybook a11y addon for shift-left testing
- Component libraries: Integration with React, Vue, Angular, and Svelte component libraries for accessible pattern enforcement
- Screen readers: NVDA (free, Windows), JAWS (enterprise, Windows), VoiceOver (macOS/iOS), TalkBack (Android)
- Compliance platforms: Level Access, Deque, or Siteimprove for enterprise accessibility management and VPAT generation
- Project tracking: Jira, Linear, or GitHub Issues for accessibility issue management with WCAG criterion tagging
- Color contrast: WebAIM Contrast Checker, Stark for Figma, and Colour Contrast Analyser for manual verification
- PDF accessibility: Adobe Acrobat, PAC (PDF Accessibility Checker) for document accessibility validation
Getting Started
- Run the baseline audit in week one — The Automated Audit Engineer scans your full application while the Assistive Technology Tester evaluates your five most critical user flows. This establishes the current conformance level and identifies the highest-impact issues.
- Set your target conformance level — Most enterprise and government requirements specify WCAG 2.1 Level AA. The Accessibility Strategist will confirm the right target based on your legal obligations and customer contracts.
- Fix shared components first — The navigation, forms, modals, and buttons appear on every page. Fixing these shared components delivers the highest impact per fix and establishes accessible patterns that new features inherit.
- Add CI/CD gates before fixing everything — Stopping new regressions is as important as fixing existing issues. The Automated Audit Engineer will add axe-core to your pipeline in the first week so that every pull request is checked.
- Train your team — Schedule the Accessibility Strategist's awareness workshop for designers and developers. Understanding why accessibility matters and how assistive technologies work changes how the team thinks about every design and implementation decision.
- Use semantic HTML before reaching for ARIA — The Remediation Developer will emphasize that correct semantic HTML (button, nav, main, heading hierarchy) solves the majority of accessibility issues. ARIA is for complex custom widgets, not for fixing broken markup. The best ARIA is no ARIA — native HTML elements have built-in accessibility that custom div-based components must manually recreate.
- Include accessibility in your definition of done — A feature is not done when it works for sighted mouse users. The Accessibility Strategist will update your team's definition of done to include keyboard navigability, screen reader compatibility, and automated scan passage. When accessibility is part of done, it stops being a separate workstream and becomes how the team builds software.