Web Accessibility: WCAG Basics & Legal Requirements

Web accessibility means designing and coding a website so people with disabilities can perceive, operate and understand it — and in 2026 it is a legal requirement in most markets you sell to. The European Accessibility Act has been enforceable since 28 June 2025, US federal website accessibility lawsuits reached 3,117 filings in 2025, and Turkey's Presidential Circular 2025/10 set binding deadlines for banks, hospitals and e-commerce operators. The reference standard is WCAG 2.2.

Most teams still treat this as a checkbox they will get to eventually. That gap is measurable: automated scans of the world's most popular sites find accessibility failures on roughly 96% of home pages, and the number is rising rather than falling. This guide covers what web accessibility law actually requires in 2026, which technical criteria get measured, how to audit your own site in half an hour, and how to sequence the fixes without rebuilding everything.

The legal sections below are general information, not legal advice. Confirm your own scope with counsel in each market where you sell.

Table of Contents

• What web accessibility actually covers
• The 2026 legal map: EU, US and Turkey
• WCAG 2.2 in plain language
• The six failures that break most sites
• Why accessibility overlays are a liability
• How to audit your site in 30 minutes
• The business case: search, conversion and reach
• Where to start: a practical sequence
• Frequently Asked Questions

What web accessibility actually covers

Web accessibility is the set of design and engineering practices that make digital content usable by people with visual, auditory, motor and cognitive disabilities. In practice it means a screen reader can announce your page correctly, a visitor who never touches a mouse can complete a purchase, and your text stays legible for someone with low vision or a phone screen in direct sunlight.

The audience is far larger than most budget conversations assume. According to the World Health Organization, 1.3 billion people — about 16% of the global population — live with a significant disability. Add age-related vision and dexterity loss, temporary impairments and situational constraints, and you are describing a substantial share of everyone who visits your site.

The commercial weight follows. W3C's business case for accessibility puts the extended market — people with disabilities plus their friends and families — at roughly 2.3 billion people controlling $6.9 trillion in annual disposable income. Web accessibility is not only a compliance line item; it changes how many people can actually transact with you.

One distinction saves a lot of confusion: accessible is not the same as responsive. Your site can look perfect on a phone and still fail every audit if buttons cannot receive keyboard focus, form fields have no programmatic labels, or errors are communicated by colour alone. Responsive design is about layout. Web accessibility is about whether the underlying markup conveys meaning to assistive technology.

It helps to picture specific users rather than a category. A blind visitor navigates by jumping between headings and stops dead at an unlabelled input. A low-vision visitor zooms text to 200% and loses content that gets clipped inside fixed-height containers. A visitor with a motor impairment cannot drag a price slider or hit a 16-pixel icon. A Deaf visitor cannot follow your product video without captions. Each of those maps to a separate criterion, and no single toggle solves them all.

The 2026 legal map: EU, US and Turkey

Three web accessibility regimes matter for most companies, and they now overlap.

European Union. The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025. The European Commission's official page lists the covered services: e-commerce, banking, e-books, electronic communications, audiovisual media access, and passenger transport information and ticketing. The rule follows the customer, not the company address — if you sell to consumers in an EU member state, you are in scope regardless of where you are headquartered. Microenterprises with fewer than 10 employees and under €2 million turnover are exempt from the service obligations, though that exemption covers services rather than products. Member states set their own penalties, so exposure varies widely by country. 2026 is the first full year national authorities supervise against the directive.

United States. There is no single federal web regulation for private business, but litigation does the enforcing. Seyfarth Shaw's tracking reports 3,117 federal website accessibility lawsuits in 2025, a 27% increase over 2024 and roughly 36% of all ADA Title III federal filings. Separately, the Department of Justice's Title II rule requires state and local government websites to meet WCAG 2.1 AA; in April 2026 DOJ issued an interim final rule extending those compliance dates to 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts.

Turkey. Presidential Circular 2025/10, published in the Official Gazette on 21 June 2025 (issue 32933), makes web and mobile accessibility binding for a broad list of organisations. The Ministry of Family and Social Services references WCAG 2.2 and has published a formal audit instrument.

Turkey's approach is unusually concrete, and worth noting even if you operate elsewhere. Rather than pointing at WCAG in the abstract, the ministry published a Level A audit checklist that turns 4 principles and 31 success criteria into a numbered question set, with mandatory items flagged. Organisations verified as compliant receive an official accessibility logo valid for two years. If you run a Turkish entity or sell into the Turkish market, that document is the exact instrument you will be measured against.

The practical takeaway across all three: targeting WCAG 2.2 Level AA satisfies every one of these regimes at once. Building three separate compliance programmes wastes budget. Document the standard once, apply it to every template, and map it back to each regulator when you need evidence.

WCAG 2.2 in plain language

The Web Content Accessibility Guidelines are the web accessibility standard all of the above regulations point to. WCAG 2.2 is the current W3C Recommendation, published in October 2023, with 86 success criteria across three conformance levels: A (baseline), AA (the usual legal target) and AAA (aspirational).

WCAG 3.0 exists but remains a working draft, with a candidate recommendation not expected before late 2027. No regulator will ask you for WCAG 3.0 conformance in 2026, and meeting 2.2 AA is the best preparation for it. Ignore the noise and aim at 2.2.

The standard groups its criteria under four principles, usually abbreviated POUR:

WCAG 2.2 added nine criteria to version 2.1, most of them aimed at mobile users and people with cognitive or low-vision needs. Four show up constantly in commercial audits:

• Target Size (2.5.8, AA): interactive targets need at least 24×24 CSS pixels. Tightly packed icon rows fail this routinely.
• Focus Not Obscured (2.4.11, AA): the focused element must not be completely hidden behind sticky headers or cookie banners.
• Dragging Movements (2.5.7, AA): anything achieved by dragging must also work with a single pointer action. Price range sliders are the classic offender.
• Accessible Authentication (3.3.8, AA): no cognitive function test in login. Fields that block password-manager autofill fail here.

Two more are worth naming because they cost almost nothing to fix. Consistent Help (3.2.6) asks that support and contact links stay in the same relative place across pages. Redundant Entry (3.3.7) prohibits asking a user to re-enter information they already provided in the same process — a rule multi-step checkouts break constantly.

The six failures that break most sites

WebAIM scans the top one million home pages every year. The February 2026 WebAIM Million found detectable WCAG 2 A/AA failures on 95.9% of pages, up from 94.8% a year earlier, with an average of 56.1 errors per page — a 10.1% increase. Average elements per home page rose from 1,257 to 1,437 in the same period. Pages are getting more complex faster than they are getting more accessible.

The encouraging part is how concentrated these web accessibility failures are. Six patterns account for nearly all detected errors:

Every one of these is cheap to fix. Contrast is usually a design-token change. A missing lang attribute is one line — and if you run localised versions, verify it renders per locale, which we cover in our guide to multilingual website architecture.

On contrast specifically, know the thresholds: 4.5:1 for normal text, 3:1 for text at 18pt or 14pt bold and above, and 3:1 for meaningful non-text elements like input borders and icons. Brand colours paired with white text and light-grey secondary text are the two violations we see most often. If you cannot change the palette, increasing weight or size can clear the bar instead.

If you are planning a new build, settle these six in the design phase, where they are close to free. Our checklist for corporate website best practices pairs well with this list.

Why accessibility overlays are a liability

Overlay widgets promise web accessibility compliance from a single line of JavaScript: a floating icon, some contrast and font-size toggles, an automated remediation claim. For a busy team the pitch is hard to resist.

The US Federal Trade Commission has now tested that claim. In its final order against accessiBe, the FTC required the company to pay $1 million over representations that its AI-powered widget could make any website WCAG compliant. The complaint documented failures to make basic components — menus, headings, tables, images and recordings — accessible, and also cited undisclosed paid reviews.

The technical reason is structural. Screen reader compatibility comes from the page's HTML semantics and ARIA attributes. A script that runs after the fact cannot reliably repair a broken heading hierarchy, an unlabelled form or a custom component that never exposes its role. Worse, overlays frequently interfere with the assistive technology users already have configured, and litigation data has repeatedly shown sites running overlays still being sued.

None of this means assistive preferences are bad. Offering a dark theme or text-size control is genuinely useful. The mistake is substituting a widget for the work — audits measure your code, and so does an actual user.

How to audit your site in 30 minutes

You do not need an agency report to learn where your web accessibility stands today. These three passes surface the majority of serious problems and require no specialist knowledge.

Keyboard-only pass

Put the mouse away. Press Tab through your home page and answer three questions: is the focused element always visible, does the order follow the visual layout, and do menus, tabs and modals respond to Enter, Space and Esc? If you can enter a dialog but not escape it, you have a keyboard trap — one of the mandatory failures in every checklist.

Then complete your primary conversion flow using only the keyboard. On an e-commerce site, run it from product page to order confirmation: variant selection, quantity steppers, coupon fields and payment steps each break independently. This is usually the moment the business case stops needing an argument, because anyone watching can see the failure.

Automated scan

WebAIM's free WAVE tool and the Lighthouse audit built into Chrome will list contrast and labelling errors in seconds. Remember that automated tooling catches roughly a third of real issues — it is where you start, not where you finish. To review your site's broader technical health at the same time, run our free site analysis tool.

Screen reader listen-through

Install NVDA on Windows, or use VoiceOver, which ships with macOS and iOS. WebAIM's screen reader survey shows the overwhelming majority of users are on Windows, with NVDA and JAWS running neck and neck, while VoiceOver dominates mobile. Spend five minutes listening to your home page. If you hear "link, link, link" repeated down the page, you have found your empty-link problem.

The business case: search, conversion and reach

Web accessibility and technical SEO overlap more than most teams realise. Search crawlers, like screen readers, do not see your page — they read your markup. Correct heading hierarchy, descriptive link text, image alt attributes and video transcripts serve both audiences with the same work.

W3C's business case documents a concrete example: when This American Life added transcripts to its audio archive, it measured a 6.86% increase in search traffic and a 4.18% increase in unique visitors. Content with no text equivalent reaches neither users nor crawlers, and video is where most sites lose the most indexable material.

The same logic now extends to AI answer engines. Assistants and AI overviews parse structure: headings define sections, tables supply comparisons, question-and-answer blocks provide extractable responses. The clean semantics you build for accessibility make your content easier for those systems to quote correctly.

Conversion effects are less discussed but easier to measure. Larger touch targets reduce mis-taps on mobile, explicit error messages cut form abandonment, and stronger contrast keeps text readable on a phone outdoors. These are usability wins that apply to your entire audience, not a minority segment.

There is a performance connection too. Simplifying bloated DOM structures, sizing images properly and eliminating layout shift improve Core Web Vitals and accessibility scores together — our guide to speeding up a website covers that side. Scheduling both in the same sprint avoids touching the same components twice.

Where to start: a practical sequence

The familiar software rule applies to web accessibility too: fixing a problem at design time costs a fraction of fixing it in production. On a new build, adding the checklist to the design brief is close to free. On an existing site, treat it as a component-by-component remediation project.

For live sites, this order works:

1. Scope to critical flows. Home page, contact form, product listing, cart and checkout. Do not try to fix every page at once.
2. Clear the six common failures. Contrast, alt text, form labels, empty links and buttons, document language. Fix them at template level, not page by page.
3. Repair keyboard and focus behaviour. Modals, dropdowns and custom components live here. This is the line item that consumes real developer time.
4. Work the checklist page by page. Verify each success criterion on your critical flows and record the findings with date, page and criterion.
5. Make it permanent. Add an accessibility check to your pre-release process, or the next design refresh will reintroduce everything you just fixed.

Budget for the fact that this is not a one-time certification. Every new campaign page and component is subject to the same criteria. For organisations that have grown a site over many years, this usually belongs inside a broader website redesign rather than as a patch.

Staff it with three roles. A designer owns colour, sizing and focus styles. A developer owns semantics, ARIA and keyboard behaviour. A content editor owns alt text, heading structure and link wording. Projects run by a single role tend to raise the automated score without changing what a real user experiences.

Finally, publish an accessibility statement: the standard you target, known gaps, and a channel for users to report barriers. EAA-covered services are expected to provide one, and an honest statement is more defensible than a claim of perfection.

Frequently Asked Questions

Is web accessibility legally required for my business?

It depends on where you sell and what you sell. Web accessibility is mandatory under the European Accessibility Act if you provide e-commerce, banking, transport ticketing, telecoms, e-books or audiovisual services to consumers in the EU, unless you qualify as a microenterprise. In the US, ADA Title III litigation rather than a single regulation drives private-sector obligations. In Turkey, Circular 2025/10 names specific sectors with fixed deadlines.

Which WCAG version and level should I target?

Target WCAG 2.2 Level AA. The EAA and the US Title II rule reference WCAG 2.1 AA, and Turkey's ministry checklist covers WCAG 2.2 Level A, so 2.2 AA satisfies all of them simultaneously. WCAG 3.0 is still a working draft and no regulator requires it in 2026.

Can an accessibility widget make my site compliant?

No. The FTC's 2025 order requiring accessiBe to pay $1 million addressed exactly that claim. Overlays can offer contrast or font-size preferences, but they cannot reliably fix broken HTML semantics, unlabelled forms or inaccessible custom components. Audits and lawsuits assess the underlying code.

How long does remediation take?

For a mid-sized corporate site built on a modern component library, fixing the critical flows is typically a few weeks of work. Legacy templates, heavy third-party embeds and custom widgets can push it to several months. The real driver is the number of repeated components, not the number of pages — in a well-built design system, one button fix propagates everywhere. Audit the component inventory before quoting a timeline.

Does accessibility improve SEO rankings?

There is no standalone accessibility ranking factor, but the overlap is substantial. Heading hierarchy, alt text, descriptive link text, transcripts and clean semantic markup serve crawlers and screen readers identically. Remediation also tends to simplify page structure, which helps crawl efficiency and reduces the volume of near-duplicate markup search engines have to process.

Do mobile apps fall under the same rules?

Yes. The EAA covers mobile applications for in-scope services, the DOJ Title II rule explicitly names mobile apps, and Turkey's circular addresses websites and mobile applications together. On iOS and Android the equivalent work is VoiceOver and TalkBack support: accessibility labels on every interactive element, dynamic type support and a sensible focus order between screens.

What should an accessibility statement contain?

State the standard you are working toward, list the areas that are not yet conformant, describe known limitations and give users a direct way to report problems. Date it and update it when you ship fixes. A specific, honest statement carries more weight with regulators and users than a blanket compliance claim, and it gives you a feedback channel that generates your next sprint's backlog.

Web accessibility spent years filed under "good practice." In 2026 it has deadlines, published audit instruments and an active complaint channel in every major market. The reassuring part is how much of it is simply competent web development: correct semantics, visible focus, adequate contrast and meaningful text.

The first step costs nothing. Tab through your checkout, run a WAVE scan, and write down what breaks. If you would rather have that list produced and prioritised for you, our web design service includes accessibility audits and remediation planning. Get in touch and we will scope the work against your actual templates.