Skip to content
Insight 8 min read

Web Accessibility in 2026: Legal Risk, Business Benefit, and How to Comply

A Sydney business receives a legal letter. Their website is inaccessible. No physical premises, no staff conduct — the claim is purely digital. This is no longer hypothetical. Accessibility is risk management, and the cost of getting it wrong keeps rising.

By Vero Scale Team ·

Web accessibility compliance in 2026

A business in Sydney receives a legal letter. The claim: their website is inaccessible to users with visual impairments. No physical premises were involved. No staff were accused of discriminatory conduct. The claim is purely about the website — the forms, the images, the navigation structure.

This is no longer hypothetical. ADA-related website lawsuits have increased 300% since 2020 (Seyfarth Shaw, 2025). According to Seyfarth Shaw’s 2025 ADA Litigation Report, more than 4,500 federal lawsuits were filed in the US in 2025 alone. Settlements routinely exceed $100,000 for organisations with significant web presence. And Australia’s Disability Discrimination Act creates parallel exposure under domestic law.

Most businesses still treat accessibility as an optional enhancement — something they’ll address “eventually.” That position is increasingly expensive to hold.

What Accessibility Actually Means

Accessibility — abbreviated a11y in developer shorthand — means building digital experiences that work for people with disabilities: those using screen readers, keyboard navigation, magnification software, switch controls, or other assistive technologies.

The governing technical standard is the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C). The current enforceable version is WCAG 2.1, published in 2018, which organises requirements into four principles (W3C WCAG 2.1, 2018):

  • Perceivable — information can be sensed. Text alternatives exist for images. Videos have captions. Colour is not the only way to convey meaning.
  • Operable — users can navigate and interact. All functions work via keyboard. Nothing requires a mouse. No content flashes at rates that trigger seizures.
  • Understandable — content and interface behaviour are predictable. Error messages are clear. Forms explain what information is required.
  • Robust — content works with current and future assistive technologies. HTML is properly structured so screen readers can interpret it correctly.

Most legal frameworks, including ADA Title III, require conformance at WCAG 2.1 Level AA — the middle tier between minimum (A) and enhanced (AAA). Australia’s DDA does not specify a technical standard, but WCAG 2.1 Level AA is the accepted benchmark for demonstrating compliance.

In the United States, the Department of Justice explicitly requires WCAG 2.1 Level AA compliance for places of public accommodation under ADA Title III (DOJ ADA Regulations, 2024). Courts have consistently held that websites constitute places of public accommodation — including businesses with no physical location. The Eleventh Circuit’s ruling in Winn-Dixie (2023) confirmed this for sites that provide information integral to business operations, such as store locations, prescription refills, and promotional content.

Notable settlements give a sense of the financial exposure:

  • DoorDash: $2.5 million settlement in 2024, with ongoing accessibility audit requirements (DoorDash Settlement, 2024)
  • Netflix: $9.5 million settlement, requiring closed captioning across the entire library (Netflix ADA Settlement, 2022)
  • Early website cases settled for $5,000-$25,000; current settlements for significant web properties routinely exceed $100,000 (Seyfarth Shaw, 2025)

In the European Union, the European Accessibility Act became enforceable in June 2025, extending WCAG 2.1 Level AA requirements to e-commerce, banking services, e-books, and smart home devices sold into EU markets — not just public sector websites (European Accessibility Act, 2025).

In Australia, the Disability Discrimination Act 1992 prohibits discrimination in the provision of goods and services, which courts and the Australian Human Rights Commission have interpreted to include digital services. The DDA does not mandate a specific technical standard, but WCAG 2.1 Level AA is the accepted benchmark for demonstrating compliance.

Why Automated Testing Is Not Enough

There is a widespread misconception that running an automated accessibility scanner constitutes compliance. It does not. Industry analysis consistently shows that automated tools detect only 30-40% of accessibility issues (WebAIM, 2023).

The reason is structural: automated tools can detect missing alt text, insufficient colour contrast ratios, and absent form labels. They cannot assess whether alt text is meaningful, whether a complex chart is genuinely understandable as described, or whether keyboard navigation through a modal dialog is logical and trap-free.

Common tools and their roles:

ToolTypeWhat It Catches
Google LighthouseAutomated~35% of issues; good initial screen (Lighthouse Accessibility Scoring, 2025)
axe DevToolsAutomated + CI/CDMost comprehensive automated coverage (Deque axe, 2025)
WAVE (WebAIM)AutomatedStrong on contrast errors and missing alt text (WebAIM WAVE, 2025)
NVDA / VoiceOver / JAWSManual / Screen readerRequired to catch the 60-70% automated tools miss
Keyboard-only navigationManualIdentifies focus traps, inaccessible components

The only way to catch the full range of accessibility failures is to combine automated scanning with manual testing using actual assistive technologies — keyboard-only navigation, screen reader testing with NVDA (Windows), VoiceOver (macOS/iOS), and JAWS (Windows).

The Five Most Common Failures

Analysis of common accessibility failures identifies recurring patterns that represent the bulk of legal exposure (Seyfarth Shaw, 2025; WebAIM, 2025):

1. Missing or inadequate alternative text. Every meaningful image requires descriptive alt text. “img001.jpg” is not descriptive. A decorative image should use alt="" so screen readers skip it. A chart or infographic requires extended description that conveys the actual information, not just labels it.

2. Insufficient colour contrast. WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px regular or 14px bold) (W3C WCAG 2.1, 2018). Light grey text on a white background — common in minimalist design — routinely fails this threshold. The WebAIM Contrast Checker provides instant verification.

3. Form fields without labels. Placeholder text disappears on focus and is not reliably announced by screen readers. Every input requires a programmatically associated <label> element. This is not just a screen reader issue — it affects users with cognitive disabilities and anyone completing forms on mobile in poor conditions.

4. Broken heading structure. Screen reader users navigate documents by heading hierarchy. Skipping from H1 directly to H4, or using heading elements for visual styling rather than document structure, breaks this navigation model. H1 identifies page content; H2 identifies major sections; H3 identifies subsections.

5. Missing keyboard focus indicators. Many designers remove the browser’s default focus outline as a visual shortcut. This leaves keyboard users with no visible indication of where they are on the page. WCAG 2.1 requires visible focus indicators. Custom focus styles must be at least as visible as browser defaults.

WCAG 2.1 Level AA: A Practical Checklist

The following represents the most commercially significant WCAG 2.1 Level AA requirements for typical business websites:

RequirementWCAG CriterionHow to Verify
All images have meaningful alt text1.1.1Automated + manual review
Colour contrast ratio 4.5:1 (normal text)1.4.3WebAIM Contrast Checker
Colour contrast ratio 3:1 (large text)1.4.3WebAIM Contrast Checker
Content readable at 200% zoom without horizontal scroll1.4.4Browser zoom test
All functionality available via keyboard2.1.1Tab through entire site
Keyboard focus always visible2.4.7Tab through entire site
Page has descriptive <title> elements2.4.2View page source
Headings follow logical H1 → H2 → H3 hierarchy1.3.1DevTools > Accessibility tree
All form inputs have associated <label> elements1.3.1Inspect form elements
Error messages identify the problem specifically3.3.1Test form validation
Videos have captions1.2.2Check media content
Language of page is specified in HTML3.1.1Check <html lang="en">
Consistent navigation across pages3.2.3Compare page structures

WCAG 3.0: What Is Coming

WCAG 3.0 is in development but has no confirmed publication date as of February 2026 (W3C WCAG 3.0 Draft, 2025). Its structural changes are significant:

  • Replaces the A/AA/AAA conformance levels with a 0-100 scoring system and Bronze/Silver/Gold thresholds
  • Reorganises requirements by outcome rather than by technology
  • Expands coverage to cognitive accessibility, virtual reality, and voice interfaces
  • Introduces four content categories: Web, Electronic Content, Software, and Authoring Tools

The practical implication: legal frameworks will continue to reference WCAG 2.1 for several years after WCAG 3.0 is finalised — a transition that standards bodies and regulators typically manage over multi-year horizons. Meeting WCAG 2.1 Level AA now is the correct priority. Monitoring WCAG 3.0 development is prudent for organisations building long-term digital infrastructure.

Proactive Compliance Costs Less

The most compelling business case for accessibility is not legal risk avoidance — it is economics. Industry estimates consistently indicate that embedding accessibility into design systems and development workflows from the start produces substantially lower remediation costs compared to reactive approaches that address accessibility after a complaint or lawsuit.

Retrofitting an existing website for accessibility is expensive. Developers must reconstruct HTML structure, replace visual-only information conveyance, rebuild form components, and retest across multiple assistive technologies. Doing this after a legal complaint adds legal fees, settlement costs, court-mandated audit requirements, and reputational damage.

The shift-left alternative — incorporating accessibility requirements into component design, building reusable accessible components, and testing during development rather than after — catches issues when they cost minutes to fix rather than weeks.

Australia: The DDA Context

Australian businesses frequently assume accessibility obligations are a US concern. They are not. The Disability Discrimination Act 1992 applies to digital services, and the Australian Human Rights Commission has been clear that excluding people with disabilities from accessing websites constitutes unlawful discrimination.

The DDA does not specify WCAG as mandatory, but the Commission’s guidelines and the broader legal context make WCAG 2.1 Level AA the accepted standard for demonstrating compliance. Australian businesses serving any audience — including those with no US operations — carry domestic legal exposure that increases with their web presence and the commercial significance of their digital channels.

Third-Party Vendors Carry Risk Too

A point that surprises many organisations: if your booking system, payment portal, or customer support chat widget is inaccessible, you carry the legal exposure — not the vendor. DOJ guidance and established case law — including precedents such as Gil v. Winn-Dixie (2023) — have established that organisations are responsible for the accessibility of third-party digital properties embedded in their customer experience.

Any vendor contract for a digital service should include accessibility requirements and audit rights. If a vendor cannot demonstrate WCAG 2.1 Level AA conformance, that risk needs to be factored into the procurement decision.

The Business Case Beyond Risk

The commercial case for accessibility extends beyond legal risk. According to the World Health Organisation, 1.3 billion people — approximately 16% of the global population — experience significant disability (WHO, 2023). The accessible design principles that serve screen reader users — clear heading structure, descriptive link text, logical form labelling — also serve users on slow connections, older devices, and non-standard browsers. Accessible sites tend to perform better in SEO because search engines, like screen readers, depend on semantic HTML structure.

Organisations serving ageing populations — healthcare, financial services, government services — have particularly strong commercial reasons to prioritise accessibility as a quality signal rather than a compliance exercise.

Where to Start

An accessibility program does not require rebuilding everything at once. A practical starting sequence:

  1. Run an automated scan with axe DevTools or Google Lighthouse to identify the automated-detectable issues — alt text gaps, contrast failures, missing labels. These are quick wins.
  2. Conduct keyboard-only navigation testing through your most important user flows: homepage to key service pages, contact form completion, any booking or purchase flow.
  3. Test with a screen reader. NVDA is free on Windows; VoiceOver is built into macOS and iOS. The experience of navigating your site with audio-only output reveals issues that no automated tool surfaces.
  4. Commission a formal WCAG 2.1 Level AA audit from a qualified accessibility specialist. Document findings and establish a remediation roadmap with priorities based on business impact.
  5. Publish an accessibility statement that identifies known limitations and provides a contact method for users who experience barriers.

The goal is not perfection in week one. It is demonstrable, good-faith progress — documented, measured, and ongoing.

Ready to audit your site’s accessibility before someone else does? Let’s talk ->


Ready to Build Something Exceptional?

Let's start a conversation about your next project.

Start a Project

Related Articles