Accesibilidad web en 2026: WCAG 2.2, riesgo legal y el caso de negocio

Web accessibility has been a best practice for two decades. In 2026, it is a legal requirement in most major markets. The EU Accessibility Act (EAA) mandated WCAG 2.2 Level AA compliance for private sector websites and apps serving EU consumers from June 2025. The UK's Public Sector Accessibility Regulations and US ADA Title III litigation have similar scope. The litigation risk is real: US ADA web accessibility lawsuits exceeded 4,000 in 2025, and EU enforcement actions are accelerating. But the business case for accessibility extends beyond legal risk — it encompasses 1.3 billion users globally with disabilities, improved SEO (accessibility signals correlate with Core Web Vitals improvements), and measurably better conversion rates across all user segments.

WCAG 2.2: what changed and what it means for your site

WCAG 2.2 introduced nine new success criteria beyond WCAG 2.1. The four most impactful for web design are: Focus Appearance (2.4.11) — focus indicators must have a minimum area and contrast ratio, making the default browser focus ring insufficient for most designs; Target Size (2.5.8) — interactive targets must be at least 24x24 CSS pixels; Accessible Authentication (3.3.8) — authentication processes cannot rely solely on cognitive function tests like puzzles or those that require transcribing characters; and Redundant Entry (3.3.7) — information entered by the user must not be required again unless the repetition is essential. Focus Appearance and Target Size are the two criteria most commonly failed in our accessibility audits — both have direct design implications and are straightforward to fix.

Colour contrast: the most common failure

WCAG 2.2 AA requires a colour contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). In our accessibility audits, colour contrast is the most frequently failed criterion — present in 87% of audited sites. The most common culprit is brand colour choices: a light accent colour used for text links against a white background, or a dark background colour with insufficient contrast for light text. The fix is straightforward: use a contrast checker (we use both Figma's built-in checker and the external Colour Contrast Analyser) at every stage of visual design. The key discipline is to check contrast not just for primary text, but for every interactive element, placeholder text, input labels, and icon-only buttons.

Keyboard navigation: the test most teams skip

Keyboard navigation — the ability to use a site using only Tab, Shift+Tab, Enter, Space, and arrow keys — is required by WCAG 2.2 and is the primary accessibility mechanism for users with motor disabilities and users who navigate by keyboard for productivity reasons. The test is simple: unplug your mouse or trackpad and try to complete the most important task on your site using only the keyboard. In our audits, this test reveals failures on 94% of sites tested: focus states that are invisible or have insufficient contrast, interactive elements that cannot be reached by Tab key, modal dialogs that do not trap focus correctly, and custom interactive components (sliders, date pickers, custom dropdowns) without keyboard support.

• Run axe DevTools (free Chrome extension) on your 5 most-visited pages — fix all Critical and Serious violations first.
• Test keyboard navigation manually on every new page before launch — Tab through every interactive element and verify focus is visible.
• Check colour contrast ratios in Figma using the built-in contrast checker before handoff.
• Provide text alternatives for all non-decorative images — alt text should describe the content and function, not the appearance.

The business case beyond compliance

Accessibility improvements generate measurable conversion improvements for all users — not just users with disabilities. This is because most accessibility requirements address the same friction that slows all users: low contrast text is harder to read in sunlight for everyone; small tap targets are harder to hit for users with larger fingers or in motion; keyboard navigation improvements help power users and anyone filling in forms on a laptop. Our analysis across 12 accessibility remediation engagements shows a median conversion improvement of 8% for all users following a WCAG 2.2 AA remediation sprint — with the improvement coming primarily from reduced form abandonment, improved mobile tap target accuracy, and better focus management in checkout flows.

Where to start: the accessibility audit priority order

Run your accessibility programme in this order for maximum impact per effort: first, automated testing with axe DevTools or Lighthouse Accessibility audit — this catches approximately 40% of WCAG violations automatically, with no manual effort. Second, keyboard navigation testing on your top 5 conversion paths — this finds the failures that automated tools miss and that most directly affect task completion. Third, screen reader testing with VoiceOver (macOS and iOS, free) or NVDA (Windows, free) on your most critical pages — this validates that your ARIA implementation is correct and that dynamic content is announced correctly. Fourth, manual colour contrast audit using the Colour Contrast Analyser against WCAG 2.2 AA thresholds. This sequence covers 90% of WCAG 2.2 AA requirements and produces the highest litigation risk reduction per hour of audit time.