Web accessibility stopped being a compliance checkbox years ago. In 2026, roughly [VERIFY: 16% of the global population lives with some form of disability, per WHO 2024] — a market segment most enterprise sites still fail to serve properly. When your checkout, dashboard, or booking flow is unusable with a screen reader or keyboard navigation, you are not just facing legal risk; you are leaking revenue. The Web Content Accessibility Guidelines (WCAG), maintained by the W3C, are the global standard regulators and courts cite. WCAG 2.2 is now the operational baseline, and WCAG 3.0 is on the horizon. For companies operating across the US, EU, and LATAM, the question is no longer whether to comply — it is how to do it without rebuilding everything from scratch. This guide explains what changed in WCAG 2.2, how the four POUR principles translate into engineering decisions, which conformance level to target, the legal map by region, the audit tools your team should adopt, and why accessibility quietly improves SEO and conversion. ## WCAG 2.2 in 2026: What Changed WCAG 2.2 was published by the W3C in October 2023 and became the reference standard adopted by most regulators through 2025 and 2026. It adds nine new success criteria on top of WCAG 2.1, focused on users with cognitive disabilities, low vision, and motor impairments — groups that earlier versions underserved. The most impactful additions for enterprise teams: - **Focus Not Obscured (2.4.11, AA)**: the keyboard focus indicator cannot be fully hidden by sticky headers, cookie banners, or chat widgets. This single criterion breaks a surprising number of SaaS dashboards. - **Dragging Movements (2.5.7, AA)**: any drag-and-drop interaction must have a single-pointer alternative (click or tap). - **Target Size (Minimum) (2.5.8, AA)**: interactive targets must be at least 24×24 CSS pixels, with exceptions. - **Consistent Help (3.2.6, A)**: help mechanisms (contact, chat, FAQ) must appear in the same relative order across pages. - **Accessible Authentication (3.3.8, AA)**: no cognitive function tests (like remembering or transcribing characters) unless an alternative exists. Affects most CAPTCHA implementations. One criterion from 2.1 was removed (4.1.1 Parsing), since modern browsers already handle malformed markup. If your team is still auditing against 2.0 or 2.1, you are working from a deprecated baseline. ## The Four POUR Principles WCAG is built on four principles, known by the acronym POUR. Every success criterion maps to one of them. **Perceivable**: content and UI must be presentable in ways users can perceive. In practice: text alternatives for images, captions for video, sufficient color contrast (4.5:1 for normal text at AA), content that does not rely on color alone to convey meaning. **Operable**: all functionality must be available from a keyboard, users must have enough time to read and interact, and nothing should trigger seizures (no flashing above three times per second). This is where single-page applications frequently fail — custom components built without proper focus management lock out keyboard users entirely. **Understandable**: text must be readable, pages must behave predictably, and the system must help users avoid and correct mistakes. Clear form labels, descriptive error messages, and consistent navigation belong here. **Robust**: content must work reliably with current and future user agents, including assistive technologies. In modern stacks this means using semantic HTML, correct ARIA attributes, and testing across screen readers (NVDA, JAWS, VoiceOver). Framework choice matters here — we cover tradeoffs in our [React vs Angular decision guide](/blog/react-vs-angular-decision-guia). ## Levels A, AA, AAA: Which One to Target WCAG defines three conformance levels. Each success criterion is tagged with the lowest level at which it applies. | Level | Criteria covered | Typical use case | |-------|------------------|------------------| | A | Minimum. Blocks users if missing. | Internal tools, low-risk content sites | | AA | Industry and legal default worldwide | Public-facing enterprise sites, SaaS, ecommerce, government | | AAA | Maximum. Not required for entire sites | Specialized content for users with specific disabilities | **Target AA.** It is the level cited by the ADA Title III, the European Accessibility Act, Section 508 in the US federal sector, and most LATAM regulations. AAA is valuable for specific flows (for example, a health portal for low-vision users), but the W3C itself states AAA cannot be required for entire sites because some content cannot meet all AAA criteria. Teams that commit to AA and document conformance through a VPAT (Voluntary Product Accessibility Template) or an EU accessibility statement cover roughly [VERIFY: 95% of legal exposure scenarios across US, EU and major LATAM markets in 2026]. ## Legal Compliance by Region (US ADA, EU EAA, LATAM) The legal landscape hardened significantly between 2024 and 2026. **United States — ADA Title III**: the DOJ published a final rule in April 2024 requiring state and local government websites to meet WCAG 2.1 AA, with deadlines in 2026 and 2027 depending on entity size. For private businesses, courts have consistently interpreted the ADA as applying to commercial websites; WCAG 2.1 AA is the de facto standard cited in litigation. ADA Title III website lawsuits exceeded [VERIFY: 4,000 federal filings in 2024, per UsableNet tracker]. **European Union — EAA**: the European Accessibility Act became enforceable on June 28, 2025. It applies to ecommerce, banking, e-books, transport ticketing, and consumer electronics sold in the EU, regardless of where the company is headquartered. Non-compliance triggers fines defined by each member state, typically scaling with company size. **LATAM**: Colombia (Resolución 1519/2020 and updates), Brazil (Lei Brasileira de Inclusão, LBI), Mexico (Ley General para la Inclusión de las Personas con Discapacidad), and Argentina (Ley 26.653) all reference WCAG-aligned standards for public sector sites, with growing pressure on private companies that serve government or regulated sectors. For US multinationals with LATAM subsidiaries, the pragmatic path is a single global standard (WCAG 2.2 AA) documented once and audited per region. ## Audit Tools: axe, WAVE, Lighthouse Automated tools catch roughly 30–40% of WCAG issues, according to independent benchmarks including the WebAIM Million report. The remaining 60–70% require manual testing and user testing with assistive technology. A realistic stack: - **axe DevTools (Deque)**: the industry standard. Browser extension, CI integration via axe-core, and Figma plugin for design-time checks. False-positive rate is the lowest among automated scanners. - **WAVE (WebAIM)**: visual overlay that flags errors, contrast issues, and ARIA problems directly on the rendered page. Excellent for content editors and QA who are not developers. - **Lighthouse (Chrome)**: built into DevTools. Lighter accessibility audit (uses axe-core under the hood) but valuable because it runs alongside performance and SEO scoring. - **Screen readers**: NVDA (free, Windows), JAWS (Windows, enterprise standard), VoiceOver (macOS/iOS), TalkBack (Android). At minimum, test critical flows with NVDA + Firefox and VoiceOver + Safari. - **Keyboard-only testing**: disconnect the mouse for 30 minutes and try to complete your top three user journeys. Most teams discover blocking issues within the first five minutes. Integrate axe-core into your CI pipeline so regressions fail the build. Accessibility debt compounds the same way as security debt — cheaper to fix in the sprint it is introduced than six months later. If you are exploring autonomous tooling, our article on [agentic web development](/blog/agentic-web-development-que-es) covers where AI-assisted audits are heading. ## Impact on SEO and Conversion Accessibility and SEO share a surprising amount of DNA. Google's crawlers parse pages much like screen readers: they rely on semantic HTML, heading hierarchy, alt text, link descriptiveness, and clean document structure. Sites that meet WCAG AA tend to perform better on Core Web Vitals and on-page SEO audits — not because Google ranks accessible sites higher directly, but because the same practices that help assistive technology also help crawlers. Concrete overlaps: - Proper `

` through `

` hierarchy improves both screen reader navigation and SEO topical structure. - Descriptive alt text feeds image search indexing. - Semantic landmarks (`