Accessibility in Web Design: Why Inclusive Design Is Now a Business Requirement

ADA Title III lawsuits targeting digital accessibility reached their highest recorded levels in 2025, according to UsableNet's annual report. The pattern is consistent: plaintiff's law firms identify non-compliant e-commerce sites using automated scanning tools, send demand letters citing violations of the Americans with Disabilities Act, and offer to settle before litigation. Settlement amounts average $50,000 per case; litigation costs significantly more. The companies targeted are not exclusively large enterprises — the majority of demand letters go to mid-market companies and growing startups, precisely because they are less likely to have legal teams who have audited their digital properties for compliance.

In June 2025, the enforcement period began for the European Accessibility Act (EAA), which extends mandatory digital accessibility requirements to private sector companies providing products and services in EU member states. Any company selling software, SaaS products, e-commerce goods, or digital services to European customers is now subject to enforcement — including North American companies serving European markets. The EAA enforcement mechanism operates through national market surveillance authorities, with fines calibrated to company size and infringement severity.

The business case for web accessibility is no longer primarily ethical — it is legal and financial. Fifteen percent of the global population lives with some form of disability, according to the World Health Organisation. In markets where this population has legal recourse for inaccessible digital products, the cost of non-compliance exceeds the cost of native accessible development by a factor that grows with company size and litigation exposure. This guide covers the current legal landscape, the WCAG 2.2 requirements that define compliance, the three implementation approaches and their real costs, a five-step technical implementation plan, two case studies, and the four accessibility mistakes with the highest remediation costs.

Record

ADA Title III digital lawsuits in 2025 — mid-market e-commerce companies are the primary targets, not just enterprises

WCAG 2.2, published by the W3C Web Accessibility Initiative in October 2023, is the current baseline standard referenced by the ADA (via DOJ guidance), the European Accessibility Act, and most international digital accessibility legislation. The legal demand is typically conformance to WCAG 2.2 AA — the intermediate conformance level, which is the enforceable standard in most jurisdictions. AAA conformance (the highest level) is considered aspirational rather than legally mandated in most markets.

For development teams transitioning from WCAG 2.1 compliance, WCAG 2.2 introduces nine new success criteria and removes one (4.1.1 Parsing, which was deprecated because modern browsers handle the underlying parsing issues automatically). The table below covers the new and significantly updated criteria most relevant to commercial web products.

Criterion

• ▸Cost: $15,000–$40,000 for standard web applications
• ▸Timeline: 6–12 weeks under deadline pressure
• ▸Legal protection during work: Partial — a documented remediation plan with a committed timeline reduces litigation exposure but does not eliminate it

• ▸Cost: $500–$2,000/year subscription
• ▸WCAG violations fixed: Estimated 20–30% of automated-detectable issues only
• ▸Legal protection: None — several lawsuits filed against overlay users specifically

• ▸Added cost on new builds: Zero — integrated into standard development process
• ▸Timeline impact: Zero additional weeks when designed in from the start
• ▸Legal protection: WCAG 2.2 AA conformance documentation with audit trail

Five Implementation Steps for WCAG 2.2 AA Compliance

Run the current brand colour palette through a WCAG contrast checker — WebAIM Contrast Checker or Stark for Figma — and identify every colour pair that fails the 4.5:1 ratio for normal text or 3:1 for large text and UI components. The most common failures: light grey body text (#999999) on white (#ffffff) produces a 2.85:1 ratio, well below the 4.5:1 requirement; many brand primary colours used as text on white backgrounds fail when the primary is a saturated mid-tone. Adjusting failing colours requires a luminance change of 10 to 20 percent in most cases — not a full colour redesign, but a systematic validation that must be completed before development begins. Also check focus indicator contrast: WCAG 2.2's new 2.4.13 criterion requires focus indicators to meet a 3:1 contrast ratio against adjacent colours, and a minimum enclosed area of 2 CSS pixels.

Watch for: Thin-weight text (300 or 400 weight) on patterned or image backgrounds — these combinations are visually appealing in design but consistently fail contrast requirements when the background image varies in lightness. The fix is a semi-transparent overlay on the background or a move to a solid background behind the text.

Tab through the entire primary user flow using only the keyboard — no mouse. Every interactive element (links, buttons, form fields, dropdowns, modals, date pickers) must receive a visible focus state in the correct tab order, and the focus must never become trapped in a non-modal context. The most common critical failures: CSS outline: none or outline: 0 applied globally to remove the default browser focus ring without providing a custom focus style — this makes keyboard navigation invisible for all users who rely on it; modal dialogs that do not trap focus inside the modal when open, allowing keyboard users to tab behind the modal into the underlying page; and sticky navigation elements that obscure the focused element when the user tabs to a link near the top of the page (the new WCAG 2.2 criterion 2.4.11).

For React and Next.js applications, Nexentity's standard: every interactive component has an explicit :focus-visible CSS rule that produces a 2px solid outline in the brand's accessible accent colour, with a 2px offset. This applies on tab focus but not on mouse click, which avoids the aesthetic problem of focus rings appearing on mouse-clicked buttons while preserving keyboard accessibility.

Watch for: Navigation modals that trap keyboard focus — the user opens a menu by pressing Enter on a menu button, and the first Tab from that button exits the menu rather than moving focus to the first menu item. This requires explicit focus management: on menu open, focus is programmatically moved to the first menu item; on menu close, focus returns to the trigger button.

Every image in the product must be categorised as one of three types, each with a different accessibility treatment: informative (communicates content — requires descriptive alt text that conveys the meaning, not the visual description); decorative (adds visual interest but carries no content meaning — requires alt="" so screen readers skip it); and functional (an image used as a link or button — requires alt text that describes the function, not the appearance). The most common failure: decorative images with alt text describing their visual appearance ("abstract blue background"), which screen readers announce on every page, adding noise that degrades the experience for screen reader users. The second most common failure: the reverse — informative images (charts, product photos, infographics) with empty alt text, which removes the content from the accessible version of the page entirely.

Watch for: CMS-managed image libraries where alt text is optional or skipped at upload. The fix is a required alt text field in the CMS upload workflow, with a written policy distinguishing decorative and informative image categories.

Forms are the highest-risk accessible content type because they require both input and output accessibility: users must be able to navigate to and complete each field (input), and they must receive clear, associated error messages when validation fails (output). WCAG requires that error messages be programmatically associated with their field — not just visually adjacent, but connected via aria-describedby or aria-errormessage so screen readers announce the error when the field receives focus. A red border on a failing field with no associated error text fails this requirement, regardless of how clear the visual indication appears on screen. Error messages must identify the specific field and the specific required correction: "Email address is required" is compliant; "Please check your input" is not.

WCAG 2.2's new 3.3.7 Redundant Entry criterion requires that information already entered in a prior step of a multi-step process be auto-populated or available for selection — users should not re-enter their email address on step 3 of a checkout if they entered it on step 1. This requires state management at the form level, storing entered values and pre-filling subsequent steps.

Watch for: CAPTCHA-only authentication flows — WCAG 2.2 AA now requires that authentication not depend solely on a cognitive function test. An audio alternative to image CAPTCHA satisfies the requirement; a "I'm not a robot" checkbox or passkey/magic-link authentication satisfies it more cleanly.

WCAG 2.2's new 2.5.8 Target Size criterion requires interactive elements to meet a minimum 24×24 CSS pixel touch target. The most common failures: icon-only buttons in toolbars (share, edit, delete icons typically rendered at 16×16px), close buttons on modal dialogs, social share icons in blog footers, and navigation items in compressed mobile menus. The fix for elements that must remain visually small is to increase the clickable/tappable area without increasing the visual size — using padding to extend the touch target beyond the visible icon boundary. A 16×16px icon with 4px padding on all sides produces a 24×24px touch target while maintaining the 16×16px visual appearance.

Mobile accessibility testing must be conducted on a physical device with VoiceOver (iOS) or TalkBack (Android) enabled — emulators do not accurately replicate assistive technology behaviour on touch screens. Common mobile-specific failures not identified in desktop testing: swipe gesture conflicts between the app's custom gestures and screen reader navigation gestures; touch target sizes that pass on desktop but fail at the viewport sizes of the most common mobile devices in the target market.

Two Case Studies: Quantified Outcomes from Accessible Development

Situation: A US retail company generating $5 million annually received an ADA demand letter citing screen reader failures in the checkout flow. An internal audit confirmed that the product detail page and checkout sequence had no ARIA labels on dynamic price update elements, no programmatic error association on form validation failures, and keyboard focus trapping in a promotional modal that prevented keyboard users from reaching the Add to Cart button. Blind users experienced 100 percent cart abandonment on these flows.

Approach: Nexentity rebuilt the checkout flow using accessible React components. Dynamic pricing elements received live region ARIA attributes (aria-live="polite") to announce price changes to screen readers without interrupting ongoing navigation. Form errors were rewritten with programmatic association and plain-language descriptions. The promotional modal was rebuilt with a proper focus trap and an accessible close button meeting the 2.5.8 touch target requirement.

Results (6 weeks from audit to deployment): Assistive technology users completed checkout at a 45 percent higher rate. The codebase cleanup eliminated an estimated 200 hours of future remediation work as the component patterns established during the engagement became the standard for subsequent development. Projected annual revenue increase from the newly accessible customer segment: $300,000. Legal exposure: resolved through documented WCAG 2.2 AA conformance, avoiding litigation.

Situation: A UK B2B SaaS company was in active contract negotiations with three European enterprise buyers who required WCAG 2.2 AA certification as a procurement condition — a requirement that became standard among European public sector and large enterprise buyers following EAA enforcement. An internal accessibility audit found low-contrast data visualisation colour pairs, keyboard navigation that skipped critical reporting filter controls, and no focus indicators on custom dropdown components.

Approach: Nexentity redesigned the full UI component library to WCAG 2.2 AA standards. Data visualisation palettes were rebuilt using colour combinations that meet the 3:1 non-text contrast requirement and remain distinguishable under colour blindness simulation. Keyboard navigation was implemented across all filter and reporting controls. Custom dropdowns were rebuilt as accessible combobox components with proper ARIA roles, states, and keyboard interaction patterns per the ARIA Authoring Practices Guide.

Results (8 weeks): 100 percent pass rate on the third-party WCAG 2.2 AA audit required by the enterprise buyers. Accessibility-related support tickets decreased 20 percent as improved interaction clarity reduced confusion for all users. Three European enterprise contracts signed, totalling £850,000 in annual contract value — contracts that were blocked pending the compliance certification.

Four Accessibility Mistakes with the Highest Remediation Costs

export default function Layout({ children }) {

const mainRef = useRef(null);

const router = useRouter();

useEffect(() => {

// Move focus to main on every route change

if (mainRef.current) mainRef.current.focus();

}, [router.asPath]);

return <main ref={mainRef} tabIndex={-1}>{children}</main>;

}