Web Erişilebilirliği (WCAG 2.2): Artık Pazarlık Konusu Değil
In 2025, web accessibility lawsuits in the US exceeded 4,500 — a 15% increase from the previous year. The European Accessibility Act (EAA) came into force in June 2025, making WCAG 2.1 AA compliance a legal requirement for digital services across all EU member states. In 2026, the question isn't whether to invest in accessibility. It's whether you can afford the legal and reputational risk of ignoring it.
Beyond compliance, accessible websites perform better. They rank higher on Google (semantic HTML and structured content are both accessibility fundamentals and SEO fundamentals). They convert more visitors (clear navigation, readable text, and intuitive forms help everyone, not just users with disabilities). And they reach a larger audience — 16% of the global population lives with some form of disability.
The Legal Landscape in 2026
Three major legal frameworks now mandate web accessibility:
ADA (United States). The Americans with Disabilities Act doesn't explicitly mention websites, but federal courts have consistently ruled that websites of public-facing businesses qualify as "places of public accommodation." The DOJ has formally stated that WCAG 2.1 AA is the expected standard. Lawsuit settlements range from $10,000 to $6 million, plus required remediation costs. Plaintiff law firms have industrialized these cases — they use automated scanners to identify non-compliant sites and file demand letters at scale.
EAA (European Union). The European Accessibility Act requires that products and services sold to EU consumers meet accessibility standards. For websites and mobile apps, this means WCAG 2.1 AA compliance (with a strong expectation of moving to 2.2). Enforcement began June 2025. Penalties vary by member state but include fines, injunctions, and removal from the market. If your business serves EU customers, compliance is mandatory regardless of where you're headquartered.
AODA (Canada/Ontario). The Accessibility for Ontarians with Disabilities Act requires WCAG 2.0 AA for organizations with 50+ employees. Fines up to $100,000/day for organizations. While Ontario-specific, it sets the precedent for national Canadian legislation.
Additional requirements exist in Australia (DDA), UK (Equality Act), Israel, Japan, and South Korea. The global trend is unmistakable: web accessibility is becoming a baseline legal requirement in every major market.
WCAG 2.2: What Changed from 2.1
WCAG 2.2, published in October 2023, adds nine new success criteria. The most impactful for web developers:
Focus Appearance (2.4.11, AA). When a UI component receives keyboard focus, the focus indicator must be clearly visible — at least a 2px solid outline with a 3:1 contrast ratio against adjacent colors. No more barely-visible dotted outlines. This catches the common pattern of outline: none in CSS reset stylesheets that removes focus indicators entirely.
/* Bad — removes focus indicator */
*:focus { outline: none; }
/* Good — visible, accessible focus */
*:focus-visible {
outline: 2px solid #0066cc;
outline-offset: 2px;
}
Dragging Movements (2.5.7, AA). Any action that requires dragging (drag-and-drop reordering, slider controls, map panning) must have a non-dragging alternative. A sortable list must offer up/down buttons alongside drag handles. A range slider must accept direct input or keyboard arrow keys.
Consistent Help (3.2.6, A). If your site provides help mechanisms (contact info, chatbot, FAQ link), they must appear in the same relative location on every page. A chat widget that appears on the homepage but not on product pages fails this criterion.
Redundant Entry (3.3.7, A). Don't ask users to re-enter information they've already provided in the same session. If a user enters their shipping address, don't ask for it again on the billing page — auto-populate it or provide a "same as shipping" option.
Accessible Authentication (3.3.8, AA). Login processes must not require cognitive function tests (CAPTCHAs, memory-based puzzles) without alternatives. Passkey/biometric authentication, email magic links, or providing a CAPTCHA-free path must be available.
The Technical Checklist
WCAG 2.2 AA has 55 success criteria. Here are the ones that fail most often on B2B websites, with specific fixes:
Images without alt text (1.1.1). Every <img> needs an alt attribute. Informative images get descriptive text. Decorative images get alt="" (empty, not missing). Icons with meaning need accessible labels.
Missing heading hierarchy (1.3.1). Use <h1> through <h6> in logical order. Don't skip levels (h1 → h3). Don't use headings for visual styling — use CSS instead. Every page should have exactly one <h1>.
Insufficient color contrast (1.4.3). Normal text requires 4.5:1 contrast ratio against its background. Large text (18px+ bold or 24px+ regular) requires 3:1. Use tools like WebAIM's contrast checker. Common failures: light gray text on white, brand colors that look good but fail contrast.
Text resize breaks layout (1.4.4). When users zoom to 200%, the page must remain usable — no overlapping text, no horizontal scrolling on narrow viewports. Use relative units (rem, em, %) instead of fixed pixels for text and container sizes.
Keyboard accessibility (2.1.1). Every interactive element must be operable via keyboard. Tab to navigate, Enter/Space to activate, Escape to close. Custom components (dropdowns, modals, tabs) need explicit keyboard event handlers — native HTML elements (<button>, <a>, <select>) get keyboard support for free.
Focus management in modals (2.4.3). When a modal opens, focus must move into the modal. Tab cycling must stay within the modal until it closes. When the modal closes, focus must return to the element that opened it. This prevents keyboard users from getting "trapped" behind invisible overlays.
// Focus trap for modals
function openModal(modal, trigger) {
modal.showModal() // native dialog handles focus trapping
modal.addEventListener('close', () => trigger.focus())
}
Form error identification (3.3.1). Errors must be identified in text (not just color). "The email field is invalid" is accessible. A red border without explanation is not. Error messages must be associated with their fields using aria-describedby.
ARIA usage. The first rule of ARIA: don't use ARIA if native HTML provides the semantics. <button> is always better than <div role="button">. When ARIA is needed (custom widgets), follow the WAI-ARIA Authoring Practices patterns exactly.
Automated vs Manual Testing
Automated tools catch approximately 30-40% of accessibility issues. The rest require manual testing.
Automated tools catch:
- Missing alt text
- Insufficient color contrast
- Missing form labels
- Invalid ARIA attributes
- Heading hierarchy violations
- Missing document language
Manual testing catches:
- Whether alt text is actually meaningful (not just present)
- Keyboard navigation flow and focus order
- Screen reader announcement quality
- Complex widget behavior (accordions, carousels, date pickers)
- Dynamic content updates (AJAX loading, notifications)
- Video caption accuracy
The testing stack we use at Empirium:
| Tool | Type | Cost | Catches |
|---|---|---|---|
| axe-core (browser extension) | Automated | Free | ~40% of issues |
| Lighthouse accessibility audit | Automated | Free | ~30% of issues |
| WAVE | Automated | Free | ~35% of issues |
| VoiceOver (macOS/iOS) | Manual screen reader | Free | Screen reader experience |
| NVDA (Windows) | Manual screen reader | Free | Windows screen reader experience |
| Keyboard-only navigation | Manual | Free | Keyboard accessibility |
The workflow: run automated scans first (they take 30 seconds). Fix everything they find. Then do manual keyboard testing on every page — tab through every element, activate every button, open every dropdown. Finally, run through key user journeys with VoiceOver or NVDA.
For ongoing compliance, integrate axe-core into your CI/CD pipeline. Every pull request runs automated accessibility tests. New violations block deployment. This prevents regression — the most common cause of accessibility failures on sites that were once compliant.
The Business Case Beyond Compliance
SEO overlap. Semantic HTML (<nav>, <main>, <article>, <aside>) is both an accessibility requirement and an SEO signal. Proper heading hierarchy helps screen readers and helps Google understand page structure. Alt text on images is accessibility compliance and image SEO. Accessible sites naturally have better technical SEO.
Expanded audience. 1.3 billion people globally have a significant disability. 253 million have vision impairment. The spending power of people with disabilities in the US alone exceeds $490 billion. An inaccessible website excludes this market entirely.
UX quality correlation. Sites that pass WCAG 2.2 AA consistently score higher on user satisfaction metrics across all users — not just users with disabilities. Clear focus indicators help keyboard power users. High contrast text is easier to read in bright sunlight. Descriptive link text ("Read the full case study" vs "Click here") helps everyone scan pages faster. Conversion-first design and accessibility are not competing priorities — they reinforce each other.
Reduced maintenance cost. An accessible codebase is a well-structured codebase. Semantic HTML is easier to maintain than div soup with ARIA hacks. Proper state management for focus and visibility prevents the class of bugs where interactive elements become invisible, un-clickable, or trapped.
FAQ
Can I make my existing site WCAG 2.2 compliant without rebuilding? Usually, yes. Most accessibility issues are fixable with CSS changes (contrast, focus indicators), HTML adjustments (alt text, labels, headings), and targeted JavaScript fixes (keyboard handlers, focus management). A typical remediation project for a 20-50 page B2B site takes 2-4 weeks and costs $5,000-15,000. A full rebuild is only necessary if the site uses deeply inaccessible patterns (canvas-based rendering, entirely custom form controls, or page builder output that can't be modified).
Am I liable for third-party widgets (chat, analytics, ads)? Legally, yes — you're responsible for the accessibility of everything on your page, including embedded widgets. Practically, use the most accessible option available, provide alternative contact methods if the chat widget isn't accessible, and document your due diligence. If a vendor can't provide a VPAT (Voluntary Product Accessibility Template) or confirm WCAG compliance, consider a different vendor.
Do accessibility overlays (UserWay, AudioEye) actually work? No. Overlay widgets that promise one-click WCAG compliance don't work and can actually make accessibility worse. The National Federation of the Blind has formally opposed overlays. Multiple lawsuits have specifically named overlay-equipped sites as non-compliant. They add JavaScript bloat, interfere with screen readers, and provide a false sense of compliance. Spend the overlay subscription budget on actual remediation instead.
How often should I re-test for accessibility? Run automated tests on every deployment (CI/CD integration). Conduct manual testing quarterly or after significant design/content changes. Full audits annually. Accessibility regresses easily — a new component, a design update, or a content change can introduce violations that automated tools don't catch.
What's the ROI of accessibility beyond avoiding lawsuits? Studies show accessible e-commerce sites see 10-30% higher conversion rates than non-accessible equivalents. The SEO improvements from semantic HTML and structured content contribute to organic traffic growth. And the total cost of proactive accessibility (building it in from the start) is 10-50x cheaper than retroactive remediation after a lawsuit demand letter arrives.