Web Accessibility in 2026: The Business Case and Technical Guide to WCAG 2.2

The Lawsuit That Changed How a Company Builds Software

A mid-sized retailer was sued under the Americans with Disabilities Act in 2023 for having a website that their screen-reader-dependent customers could not use to complete a purchase. The settlement cost $175,000. The remediation cost another $280,000 to fix years of inaccessibility in a mature codebase. Total cost: $455,000. The estimated cost to have built accessibly from the start would have been under $30,000 — a 15x difference.

At CodeMiners, accessibility is a first-class requirement in every product we build. Here's what every development team needs to understand about building inclusive software.

The Business Case for Accessibility

The compliance argument for accessibility is real but incomplete. The business arguments are equally compelling:

• Market size — 1.3 billion people globally have disabilities; they represent $13 trillion in disposable income
• SEO benefits — accessible HTML (proper heading hierarchy, alt text, semantic elements) directly improves search engine crawlability
• Performance benefits — accessible code tends to be leaner, faster, and more standards-compliant
• Enterprise sales — WCAG compliance is required by government agencies and increasingly by enterprise procurement criteria
• Legal risk reduction — accessibility lawsuits have increased 300% since 2017

Accessibility is not a charity — it's sound product strategy.

WCAG 2.2: The Standard

The Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C, is the internationally recognized standard for web accessibility. It organizes requirements under four principles (POUR):

• Perceivable — information is available to all senses users have (alt text for images, captions for video)
• Operable — all functionality accessible by keyboard, no seizure-inducing content
• Understandable — content is readable, predictable, and provides error assistance
• Robust — content can be interpreted by a wide variety of assistive technologies

Compliance levels: A (minimum), AA (the legal standard in most jurisdictions), AAA (aspirational). Build to AA as the baseline.

Need an accessibility audit or want to build accessibly from scratch? We conduct WCAG 2.2 audits and implement accessibility fixes for web products. Get a free accessibility assessment →

The High-Impact Accessibility Fixes

WebAIM's accessibility surveys consistently find the same issues across the web. Fixing these covers 80% of common accessibility problems:

Color Contrast

Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Tools like the WebAIM Contrast Checker or browser DevTools make this easy to verify. This single issue affects millions of users with low vision or color blindness.

Image Alt Text

Every informational image needs descriptive alt text that communicates what the image conveys. Decorative images should have empty alt text (alt="") so screen readers skip them. This is the most commonly violated WCAG criterion.

Keyboard Navigation

All interactive elements (buttons, links, form fields, menus) must be reachable and usable with a keyboard alone. Tab order should follow visual reading order. Focus states must be clearly visible — don't suppress outline styles without providing an alternative.

Form Labels

Every form input must have an associated label element. Placeholder text is not a label — it disappears when the user types. Linked labels (using htmlFor in React / for in HTML) enable screen readers to announce field context while the cursor is in the field.

Heading Hierarchy

Headings (H1–H6) should create a logical document outline. Screen reader users navigate pages by jumping between headings. A page with five H2s and no H1, or headings chosen for visual size rather than semantic meaning, is navigational chaos for assistive technology users.

ARIA: When to Use and When Not To

WAI-ARIA (Accessible Rich Internet Applications) attributes let developers add semantic context to HTML elements that lack native meaning. The first rule of ARIA: don't use it. Use native HTML elements that have built-in accessibility semantics instead.

When custom components are unavoidable (custom dropdowns, date pickers, modal dialogs), ARIA roles and properties fill the semantic gap: role="dialog", aria-modal="true", aria-labelledby, aria-expanded. Incorrect ARIA is worse than no ARIA — it creates contradictions that confuse screen readers.

Testing: Automated and Manual

Automated accessibility testing catches approximately 30–40% of WCAG violations. Essential tools:

• axe-core — the most comprehensive automated checker; integrates with Jest, Cypress, and browser devtools
• Lighthouse — Google's built-in accessibility scorer, good for quick audits
• NVDA + Chrome, VoiceOver + Safari — test with real screen readers on the actual target platforms

Manual testing with a real screen reader is irreplaceable. It reveals interaction patterns and announcement issues that automated tools cannot detect. We include accessibility testing in our testing and QA guide.

Ready to make your product accessible and meet enterprise compliance requirements? We audit, fix, and build accessibly. Talk to our accessibility team →

Building a Culture of Accessibility

Sustainable accessibility requires cultural change, not just technical fixes:

• Accessibility requirements in design specifications (not a retrofit after development)
• Automated accessibility tests in CI/CD pipeline (block builds that introduce violations)
• Designer and engineer training on the most common issues
• Including people with disabilities in user testing panels
• An accessibility champion who owns the practice and tracks progress

Companies that build accessibility into their process from the start spend a fraction of what companies spend fixing it after the fact. The earlier in the product lifecycle you address accessibility, the cheaper it is.

The Legal Landscape in 2026

Accessibility law has become significantly stricter globally:

• EU Web Accessibility Directive applies to public sector and increasingly to private sector digital products
• EU European Accessibility Act takes full effect in June 2025 (already law, enforcement beginning)
• ADA lawsuits continue increasing in the US with no federal standard clarifying digital scope
• Canada's AODA requires WCAG 2.0 AA compliance for large private-sector organizations

The trend is clear: accessibility compliance is becoming mandatory for digital products globally, not just a best practice.

Start Now, Not Later

The most expensive time to fix accessibility is after the codebase is mature. Every component added without accessibility adds to the technical debt. Starting with accessible design tokens, semantic HTML, and keyboard navigation as defaults costs almost nothing in a greenfield project.

If you're building a new product or need to remediate an existing one, talk to the CodeMiners team. We design and build products that are accessible by default — and we audit existing products to identify and fix the issues that create legal risk. Explore our full design and development capabilities at our services page.