| Myth | Reality |
|---|---|
| Automated scanners like axe-core or Lighthouse catch “most” accessibility problems, so manual testing is optional. | Industry testing from Deque and others consistently shows automated tools catch roughly 30-50% of WCAG success criteria; issues like meaningful reading order, focus management, and whether an ARIA label actually makes sense require a human — often a screen-reader user — in the loop. |
| Accessibility is a design responsibility; engineers just implement what design hands off. | Most real-world failures are structural — missing focus traps in modals, mis-ordered DOM nodes, client-side routing that never moves focus — and those are implementation bugs, not visual design flaws. That makes accessibility an engineering-process problem as much as a design one. |
| If your component library “looks” accessible, every product built on it inherits that compliance for free. | A design system only pays off when its accessible behavior (keyboard interaction, focus order, ARIA semantics) is enforced in the component’s code and tests — not just its Figma file — and product teams still owe their own page-level checks like heading structure and landmark regions. |
| The ADA and the European Accessibility Act are aimed at government sites, so most commercial products are unaffected. | The 2024 DOJ Title II rule covers state and local government sites and apps, but Title III litigation against ordinary commercial websites has been running for years, and the EAA’s June 2025 deadline applies broadly to EU-facing e-commerce, banking, and digital products regardless of where the company is headquartered. |
Before going further: this article is about accessibility as an engineering and compliance practice — the tooling, testing workflows, design-system architecture, and regulatory obligations that make a codebase conform to WCAG over time. That is a different subject from posts like Designing AI for Accessibility or AI for Accessibility: Helping People with Disabilities, both of which cover AI-powered assistive technology built for end users with disabilities. Here, the “user” of the practices below is your engineering team, and the deliverable is a pipeline that keeps a product conformant release after release — not an assistive tool a person with a disability installs on their own device.
Why Accessibility Needs an Engineering Practice, Not Just a Design Review
Most accessibility failures that show up in real audits are not visual design mistakes — they are code-level defects introduced during ordinary feature work. A developer adds a custom dropdown without keyboard support. A single-page app router swaps views without moving focus or announcing the change to a screen reader. A build pipeline ships a new icon button with no accessible name. None of these are things a designer’s mockup review will catch, because they only exist once the component is wired up in the DOM. That is the core argument for treating accessibility as an engineering practice: it needs the same guardrails as security or performance — automated checks in CI, linting at commit time, and regression tests that fail a build — because it degrades the same way test coverage or bundle size does, through thousands of small, well-intentioned commits.
The practical shift is moving accessibility left, the same way security teams moved static analysis into the developer’s local loop instead of a pre-release audit. Instead of one accessibility specialist manually reviewing a release candidate, the goal is a pipeline where obvious violations (missing alt text, insufficient contrast, unlabeled form fields, invalid ARIA usage) get caught automatically before a pull request merges, freeing human testers to focus on the judgment calls automation cannot make — reading order, meaningful sequence, whether an interaction actually makes sense to someone who cannot see the screen.
WCAG 2.2 as the Baseline Everyone Is Actually Testing Against
WCAG 2.2 became a formal W3C Recommendation on 5 October 2023, adding nine new success criteria on top of WCAG 2.1’s structure, covering things like focus not being obscured, minimum drag-alternative interactions, larger target sizes, and consistent help placement. It did not remove anything from 2.1 — it is additive — which is why most conformance programs describe their target as “WCAG 2.2 AA,” since that is now the de facto standard referenced by both regulators and enterprise procurement teams.
| WCAG 2.2 addition | What it actually requires | Common engineering fix |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | A focused element must not be entirely hidden by sticky headers, cookie banners, or chat widgets | scroll-margin-top / scroll-padding-top on focusable elements, z-index audits on overlays |
| 2.5.7 Dragging Movements | Any drag-only interaction needs a single-pointer alternative (buttons, keyboard controls) | Add explicit “move up/down” buttons alongside drag handles in sortable lists |
| 2.5.8 Target Size (Minimum) | Interactive targets need at least a 24×24 CSS pixel hit area, with limited exceptions | Pad tap targets in design-system button and icon components, not per-page |
| 3.3.7 Redundant Entry | Don’t force users to re-enter information already supplied earlier in the same process | Persist prior form state across multi-step checkout and signup flows |
| 3.3.8 Accessible Authentication (Minimum) | Login should not rely solely on a cognitive test (e.g., puzzle-solving) with no alternative | Support password managers, passkeys, or paste-enabled OTP fields |
The practical value of this table is that most of these fixes belong in shared component code, not individual pages — which is exactly why the design-system section below matters as much as the CI tooling section.
Automated Testing Tooling: axe-core and Lighthouse CI in the Pipeline
The two tools that show up in almost every serious accessibility engineering pipeline are axe-core, Deque’s open-source rules engine, and Lighthouse CI, Google’s automated auditing tool that itself runs on axe-core under the hood for its accessibility category. axe-core has been downloaded billions of times and is embedded in Playwright, Cypress, Selenium, and Jest integrations, which is what makes it usable directly inside unit and end-to-end test suites rather than as a separate manual step. Lighthouse CI adds the ability to set score thresholds and specific audit pass/fail gates directly in a CI job, so a pull request can be blocked the same way a failing unit test blocks it.
- Step 1 — Lint locallyAdd an eslint-plugin-jsx-a11y (or framework equivalent) rule set so obvious violations — missing alt attributes, invalid ARIA roles, non-interactive elements with click handlers — surface in the editor before a commit even happens.
- Step 2 — Unit-test componentsRun axe-core against each component’s rendered output in Jest or Vitest, treating accessibility violations as test failures the same way you would a broken snapshot.
- Step 3 — Gate pull requestsRun axe or Lighthouse CI against key user flows (checkout, signup, search) on every PR using Playwright or Cypress, and fail the build on new violations above an agreed severity threshold.
- Step 4 — Track score trendsStore Lighthouse CI historical results (via @lhci/server or a similar dashboard) so a slow regression across many small PRs is visible before it becomes a launch blocker.
- Step 5 — Schedule manual auditsReserve human screen-reader and keyboard-only testing for release candidates and any flow automation cannot fully validate — automation narrows what needs manual attention, it does not replace it.
Figure 1 — Where automated accessibility checks sit in a CI/CD pipeline
A horizontal pipeline diagram shows five stages left to right: “Local lint (jsx-a11y)” → “Unit tests (axe-core + Jest)” → “PR gate (Lighthouse CI / Playwright + axe)” → “Merge to main” → “Release candidate (manual screen-reader + keyboard audit)”. Below the first four stages, an arrow labeled “seconds to minutes, blocks merge” spans the automated portion. Below the fifth stage, a separate arrow labeled “hours, blocks release” marks where humans take over. A small annotation notes that roughly 30-50% of WCAG success criteria are reliably automatable, with the remainder requiring the manual stage.
The goal is not to automate everything — it’s to shrink the surface area that still needs a human tester by catching the mechanically-detectable failures earlier and cheaper.
Accessibility in Component Libraries and Design Systems
The highest-leverage place to fix accessibility bugs is the shared component library, because a fix made once in a Button, Modal, or Combobox component propagates to every product surface that consumes it — the same argument covered from a different angle in the accessibility-audit checklist inside our native-vs-hybrid-vs-cross-platform comparison, which touches on hit-target sizing and contrast at the mobile-app layer. A design system that only ships visual tokens (color, spacing, type) without codifying interaction behavior — focus order, keyboard handling, live-region announcements — leaves every consuming team to solve those problems independently, which is how inconsistent, under-tested accessibility creeps back in even when the visual design looks compliant.
Mature design systems (Adobe’s Spectrum, GitHub’s Primer, Shopify’s Polaris) treat accessible behavior as part of the component’s contract: a Modal component ships with built-in focus trapping and Escape-to-close; a Combobox ships with the correct ARIA 1.2 authoring pattern already wired to keyboard events; a Toast/notification component manages an ARIA live region so screen-reader users hear updates without the page stealing their focus. None of this is optional polish — it is the mechanism by which one team’s accessibility expertise scales to every team building on top of it.
| Component library approach | What happens to accessibility over time |
|---|---|
| Tokens-only design system (colors, spacing, type only) | Every consuming team re-implements keyboard and ARIA behavior independently; quality varies wildly and regressions are invisible until a manual audit finds them |
| Behavior-encoded component library (accessible interaction built into the component, tested with axe-core in the library’s own CI) | A fix or regression is caught once, centrally, before it reaches any consuming product; teams inherit conformant behavior by default |
Screen-Reader Testing Workflows That Actually Catch Problems
Automated tools cannot tell you whether a screen reader announces a page in a sensible order, whether a custom widget’s ARIA role matches its actual behavior, or whether an error message is announced at the right moment. That is why every mature accessibility program keeps a manual testing rotation using the combinations real users rely on: NVDA or JAWS with Chrome or Edge on Windows, and VoiceOver with Safari on macOS and iOS — that browser/screen-reader pairing matters because rendering and accessibility-tree quirks differ across combinations, and testing only in one produces false confidence.
A workable manual workflow does not require testing every page with every combination. Teams typically define two or three “critical path” flows (signup, checkout, core product action), assign a rotating owner to test them with a real screen reader before each release, and log defects the same way as any other bug — with severity, reproduction steps, and an owner. Pairing this with periodic testing from people who use assistive technology daily (not just engineers simulating it) surfaces friction that a scripted walkthrough misses, since fluent screen-reader users navigate very differently from someone new to the tool.
The Legal and Regulatory Landscape: ADA and the EAA
Accessibility engineering has a compliance deadline attached to it now in a way it did not five years ago. In the United States, the Department of Justice finalized a Title II rule in April 2024 requiring state and local government websites and mobile apps to conform to WCAG 2.1 Level AA; compliance dates were later extended, with larger public entities now facing an April 2027 deadline and smaller ones April 2028. Title II covers government entities directly, but the far larger practical exposure for commercial companies has been Title III litigation, where U.S. courts have for years treated an inaccessible commercial website as a form of disability discrimination, using WCAG conformance as the de facto evidentiary standard even without a codified regulation for private business.
In the European Union, the European Accessibility Act’s main compliance deadline landed on 28 June 2025, requiring conformance with EN 301 549 (which itself incorporates WCAG 2.1 AA) for e-commerce, banking, telecom, transport ticketing, and e-book platforms sold into the EU — regardless of where the company is headquartered. Products already on the market before that date get until 2030 or their next substantial update, whichever comes first, and micro-enterprises under 10 employees and €2 million revenue are exempt, but any product team shipping into EU markets now needs conformance tracked the same way they track any other regulatory launch gate.
Common mistakes
- Treating a passing Lighthouse accessibility score (or a green axe-core run) as proof of WCAG conformance, when both tools only cover a subset of automatable success criteria.
- Fixing accessibility bugs page-by-page instead of at the component level, so the same defect reappears in every new feature built from a copy-pasted pattern.
- Running screen-reader tests only in VoiceOver (or only in NVDA) and assuming the result generalizes to every combination your users actually rely on.
- Waiting for a pre-launch audit to surface accessibility debt instead of gating pull requests, which turns weeks of small regressions into an expensive last-minute scramble.
- Assuming EAA or ADA obligations only apply to consumer-facing government or EU-based companies, and missing that any product sold into those markets is in scope.
In practice
Teams that keep accessibility debt low tend to share one habit: they put an accessibility gate in the same CI stage as their unit tests and security scans — the same discipline covered in our secure coding practices guide, which treats quality gates as non-negotiable pipeline steps rather than optional reviews. They also require pull requests touching shared components to run against axe-core before merge, borrowing the same enforced-review discipline described in our guide to Git and version control in collaborative projects. The combination — automated gates plus scheduled manual screen-reader audits plus a design system that encodes accessible behavior once — is what actually holds conformance steady release after release, rather than treating it as a periodic fire drill.
Glossary
- WCAG
- Web Content Accessibility Guidelines, the W3C standard defining testable success criteria for accessible digital content, currently at version 2.2.
- axe-core
- Deque Systems’ open-source JavaScript accessibility testing engine, embedded in Lighthouse and most browser-automation testing frameworks.
- Lighthouse CI
- Google’s command-line and server tooling for running Lighthouse audits (including accessibility) automatically inside a CI/CD pipeline.
- ARIA
- Accessible Rich Internet Applications, a W3C specification for attributes that communicate roles, states, and properties of custom UI widgets to assistive technology.
- Focus trap
- A pattern that keeps keyboard focus contained within an open modal or dialog until it is dismissed, preventing focus from escaping to hidden background content.
- Live region
- An ARIA attribute (aria-live) that tells a screen reader to announce dynamic content changes without requiring the user to navigate to that content manually.
- Title II / Title III (ADA)
- Sections of the Americans with Disabilities Act covering state/local government services (II) and places of public accommodation, including commercial websites (III).
- EAA
- The European Accessibility Act, an EU directive requiring accessibility conformance for a defined set of products and services sold into EU markets from June 2025.
Key Takeaways
- Accessibility engineering is a code-quality discipline: automated gates, design-system enforcement, and CI checks, not a one-time design review.
- WCAG 2.2 is additive to 2.1 and is now the practical baseline most regulators and enterprise procurement teams reference.
- axe-core and Lighthouse CI catch roughly 30-50% of success criteria automatically — enough to shrink, not eliminate, the manual testing burden.
- Fixing accessibility in shared component libraries scales a fix to every consuming product; fixing it page-by-page does not.
- Manual screen-reader testing across real browser/AT combinations remains irreplaceable for judgment calls automation cannot make.
- ADA Title II (government) and the EAA (June 2025, EU-facing commercial products) are active regulatory deadlines, not hypothetical risk.
- This is a different topic from AI-powered assistive technology for end users — that’s a product category; this is an engineering and compliance practice.
FAQs
What is the difference between accessibility engineering and accessibility design?
Accessibility design focuses on visual and interaction choices — color contrast, layout, content structure. Accessibility engineering is the practice of enforcing those choices in code through automated testing, CI gates, and design-system architecture so they survive ongoing development rather than degrading with each new feature.
Does a passing Lighthouse accessibility score mean a page is WCAG conformant?
No. Lighthouse’s accessibility score is based on axe-core rules, which reliably automate roughly a third to half of WCAG success criteria. A high score means those automatable checks pass — it says nothing about reading order, meaningful ARIA usage, or whether an interaction is actually usable with a screen reader.
How is this article different from thetechtrends.tech’s AI accessibility posts?
Posts like Designing AI for Accessibility and AI for Accessibility: Helping People with Disabilities cover AI-powered assistive tools built for end users with disabilities. This article covers the engineering practice of making a product’s own codebase WCAG-conformant — testing tooling, design systems, and legal obligations — a different angle entirely.
What’s the fastest way to start testing accessibility in CI?
Add eslint-plugin-jsx-a11y (or the equivalent for your framework) for instant local linting, then wire axe-core into your existing Playwright or Cypress end-to-end tests for two or three critical flows. That alone catches a meaningful share of regressions before Lighthouse CI or manual audits are even set up.
Do I need to test with both NVDA/JAWS and VoiceOver?
Ideally yes. Screen-reader and browser combinations render accessibility trees differently, so a pattern that works cleanly in VoiceOver on Safari can still fail in NVDA on Chrome. Most teams rotate manual testing across at least one Windows and one macOS/iOS combination for critical flows before each release.
Does the European Accessibility Act apply to a US-based company?
Yes, if the company sells products or services into the EU market — e-commerce, banking, transport ticketing, e-books, and similar covered categories are in scope regardless of where the company is headquartered. The main compliance deadline was 28 June 2025, with some allowances for products already on the market until 2030.
What’s the highest-leverage place to fix accessibility bugs?
Shared component libraries and design systems. A fix to a Modal’s focus-trap logic or a Combobox’s ARIA pattern, made once and tested with axe-core in the library’s own CI, propagates automatically to every product surface that consumes that component — far more efficient than auditing individual pages.
Can automated tools fully replace manual accessibility audits?
No. Automated tools are excellent at catching mechanically detectable issues like missing alt text or insufficient contrast, but they cannot judge whether content order makes sense, whether an ARIA label is meaningful, or whether a workflow is actually usable — those require a human, ideally one experienced with assistive technology.
References
- “Web Content Accessibility Guidelines (WCAG) 2.2,” W3C, 2023/2024, https://www.w3.org/TR/WCAG22/
- “What’s New in WCAG 2.2,” Web Accessibility Initiative, W3C, https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
- “axe-core,” Deque Systems / dequelabs, GitHub repository, https://github.com/dequelabs/axe-core
- “Lighthouse,” Chrome for Developers, Google, https://developer.chrome.com/docs/lighthouse/overview/
- “Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities,” Federal Register / U.S. Department of Justice, 2024, https://www.federalregister.gov/documents/2024/04/24/2024-07758/
- “Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps,” ADA.gov, https://www.ada.gov/resources/2024-03-08-web-rule/
- “European Accessibility Act,” European Commission, https://ec.europa.eu/social/main.jsp?catId=1202
