Last reviewed: 9 November 2026. This article is general information for QA and product teams. It is not legal advice. Confirm your own obligations with a qualified lawyer.
If you sell online to customers in more than one country, accessibility is no longer a nice-to-have. The European Accessibility Act (EAA) has applied since 28 June 2025 and covers e-commerce services offered to consumers in the EU. UK businesses have a separate duty under the Equality Act 2010. US retailers face ADA Title III claims, and some also sell to federal buyers who ask about Section 508. One technical standard sits underneath most of this work: the Web Content Accessibility Guidelines (WCAG), now at version 2.2.
The rules are not the same in each market, and WCAG is not a law. That gap is where many teams get stuck. They know they need to test, but not what to test or what a pass actually proves.
This article gives you a practical European Accessibility Act checklist built around WCAG 2.2, with the legal context for the EU, UK and US kept separate from the testing advice. You will find a 20-point checklist for a typical online store, an eight-step testing workflow, guidance on tools and answers to common questions.
What Is the European Accessibility Act (EAA)?
The European Accessibility Act is Directive (EU) 2019/882, an EU law that sets common accessibility requirements for certain products and services, including e-commerce services, consumer banking, e-books and electronic communications. It applies to covered products placed on the market, and covered services provided to consumers, after 28 June 2025.
Because it is a directive, each EU member state wrote it into national law. Germany's version is the BFSG, for example. That means details such as the supervising authority and the penalties differ from country to country, so check the national law for each market you sell into.
Which online businesses are covered?
E-commerce services are on the Directive's list. In plain terms, this means websites and mobile apps that let a consumer buy products or services at a distance. The law is aimed at services offered to consumers in the EU, and law firms and compliance guides commonly read this to include sellers based outside the EU, such as in the UK or US. A business that sells only to other businesses may fall outside the e-commerce definition, but that is a legal question worth confirming rather than assuming.
Who may be exempt?
There are two exemptions to know about, and neither should be assumed:
- Microenterprises providing services - A microenterprise has fewer than 10 people and an annual turnover or balance sheet total of no more than €2 million. The exemption applies to services, not to products, and a business that grows past the thresholds loses it.
- Fundamental alteration or disproportionate burden - An organisation may argue that meeting a requirement would change the nature of its service or place an excessive burden on it. This has to be assessed and documented, and authorities can ask to see the reasoning.
What is the role of EN 301 549?
EN 301 549 is the European standard for accessible information and communication technology, published by CEN, CENELEC and ETSI. Version 3.2.1 includes WCAG 2.1 Level AA for web content. It is the version cited in the EU Official Journal in support of the Web Accessibility Directive, which covers public-sector websites. Under the EAA, a service that conforms to a harmonised standard cited in the Official Journal is presumed to meet the matching requirements. At the time of this review, no edition of EN 301 549 had been cited in support of the EAA, so that presumption was not yet available.
Version 4.1.1 was published in September 2026. It moves the standard to WCAG 2.2 and adds a mapping to the EAA. Its citation in the Official Journal was still pending, with industry sources expecting it between late November and December 2026. Check the Official Journal before you rely on any date.
How does WCAG relate to the EAA?
The Directive does not name a WCAG version. WCAG is the technical backbone of EN 301 549, which is why WCAG-based testing is the usual starting point. It is a starting point only. EN 301 549 covers more than WCAG, and the EAA has its own requirements, such as accessible information about the service and support.
What Is WCAG 2.2 and Why Does It Matter?
WCAG 2.2 is a W3C Recommendation, published on 5 October 2023, that explains how to make web content accessible to people with disabilities. It builds on WCAG 2.1 and, apart from one obsolete criterion, keeps everything 2.1 required.
WCAG is organised around four principles, often called POUR:
- Perceivable: users can see, hear or otherwise take in the content.
- Operable: users can navigate and use every control, including by keyboard.
- Understandable: content and behaviour are clear and predictable.
- Robust: the code works with browsers and assistive technology such as screen readers.
Each success criterion has a conformance level. Level A covers the most basic barriers. Level AA adds the requirements most laws and standards point to. Level AAA is the highest level, and W3C does not recommend requiring it across a whole site because some content cannot meet it. When people say "WCAG 2.2 AA", they mean every Level A and Level AA criterion in version 2.2.
What is new in WCAG 2.2?
Nine criteria were added and one, 4.1.1 Parsing, was removed as obsolete. The six that sit at Level A or AA are the ones most teams need to test:
- 2.4.11 Focus Not Obscured (Minimum), AA
- 2.5.7 Dragging Movements, AA
- 2.5.8 Target Size (Minimum), AA
- 3.3.8 Accessible Authentication (Minimum), AA
- 3.2.6 Consistent Help, A
- 3.3.7 Redundant Entry, A
The other three are Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance and 3.3.9 Accessible Authentication (Enhanced). If your team is still testing against a WCAG 2.1 checklist, these six are what it is missing, and several of them land directly on checkout and login.
EAA vs WCAG 2.2 vs ADA vs UK Accessibility Requirements
The most common mistake in this area is treating laws and standards as the same thing. A law tells you who must act. A standard tells you how to test. This table keeps them apart.
A comparison chart separating laws (EAA, ADA, Section 508, UK Equality Act, UK public sector regulations) from technical standards (WCAG 2.2, EN 301 549)
| Instrument | Type | Region | Who it applies to | Names a technical standard? |
| European Accessibility Act (Directive (EU) 2019/882) | Law (EU directive, applied through national laws) | EU | Providers of covered services, including e-commerce, to EU consumers | Not in the Directive itself. It uses harmonised standards, with EN 301 549 the expected route |
| EN 301 549 | Technical standard | Europe | Voluntary on its own. Used to support EU laws | Incorporates WCAG (2.1 AA in v3.2.1; 2.2 in v4.1.1) |
| WCAG 2.2 | Technical standard (W3C) | Global | Not a law. Referenced by laws and standards | It is the standard |
| ADA Title III | Law (civil rights) | US | Businesses open to the public ("public accommodations") | No. DOJ guidance points to WCAG but sets no mandatory version for private businesses |
| ADA Title II rule | Regulation | US | State and local governments | WCAG 2.1 AA, with compliance dates extended by a year in April 2026 |
| Section 508 | Law (Rehabilitation Act) | US | Federal agencies and, in practice, vendors selling ICT to them | WCAG 2.0 A and AA, under the 2017 refresh |
| Equality Act 2010 | Law | UK | Service providers, public and private, including online | No. It requires reasonable adjustments. WCAG is a common benchmark |
| Public Sector Bodies Accessibility Regulations 2018 | Regulation | UK | Public sector websites and mobile apps | WCAG, with GOV.UK guidance now pointing to 2.2 AA, plus an accessibility statement |
Three points from the table matter most for sellers.
UK private businesses are not covered by the public-sector regulations - A UK online shop is a service provider under the Equality Act, which requires reasonable adjustments for disabled customers. That duty is anticipatory, meaning you should plan ahead rather than wait for a complaint. The Act does not name WCAG, but WCAG 2.2 AA is a sensible way to show you took reasonable steps. The stricter public-sector rules apply to public bodies, not to retailers.
UK sellers can still be in scope of the EAA - The EAA does not apply to a business just because it is British. It applies when you provide a covered service to consumers in the EU.
ADA does not require WCAG 2.2 by name - For private businesses, Title III has no regulation that names a WCAG version. Many US teams still use WCAG 2.1 or 2.2 AA because DOJ guidance refers to WCAG and it is widely used as the practical benchmark.
Who Needs to Test Their Website for Accessibility?
Anyone whose customers can use a screen reader, a keyboard, a switch device or a magnifier needs to know whether the service works for them. In practice the groups under most pressure are:
- E-commerce businesses. Product discovery, cart, checkout and account pages are where an inaccessible design directly costs sales.
- SaaS companies. Sign-up, onboarding, dashboards and billing screens are all in scope when they are sold to consumers, and buyers increasingly ask for evidence. Thorough web application testing should include accessibility paths, not just functional ones.
- Online marketplaces. The marketplace owns the shell, search and checkout, even if sellers supply the listings.
- Financial platforms. Consumer banking services are on the EAA's list, and forms and authentication are heavy.
- Booking websites. Date pickers, seat maps and filters are common failure points.
- Digital service providers. This includes online course and training platforms, where teams often rely on e-learning testing services to cover video, quizzes and learner dashboards.
- Businesses selling across borders. If you sell in the EU, UK and US, you need one test plan that covers the strictest overlap and a record of what you tested.
European Accessibility Act and WCAG 2.2 Testing Checklist
This checklist covers the barriers that most often block real customers in an online store. For each checkpoint you will see what to test, how to test it, what a failure looks like and why it matters. It is built on WCAG 2.2 Level AA and aimed at the EAA, but it does not prove legal compliance on its own. Treat it as the practical core of an audit, then add the checks your legal advisers and national authorities expect.
A checklist graphic showing keyboard, screen reader, colour contrast, focus visibility and form validation checks with pass and fail markers
Navigation, focus and visual presentation
1. Keyboard navigation (WCAG 2.1.1, 2.1.2).
What to test - Every link, button, menu, filter and dialog.
How - Unplug the mouse and use Tab, Shift+Tab, Enter, Space and arrow keys.
Failure looks like - A mega-menu that opens only on hover, or a modal you cannot leave.
Why it matters - Keyboard users include people with motor disabilities and screen reader users, and they cannot buy what they cannot reach.
2. Screen reader compatibility (WCAG 1.3.1, 4.1.2, 4.1.3).
What to test - That each control has a name, role and state, and that updates are announced.
How - Run through a purchase with NVDA, JAWS or VoiceOver.
Failure looks like - A button read aloud as "button" with no name, or "added to basket" appearing silently.
Why it matters - Blind users get no feedback and abandon the order.
3. Colour contrast (WCAG 1.4.3, 1.4.11).
What to test - Text against its background, plus icons, input borders and focus indicators.
How - Use a contrast checker on real design tokens and states, including hover, disabled and error.
Failure looks like - Light grey placeholder text or a pale "Add to basket" button that falls below 4.5:1 for text or 3:1 for interface components.
Why it matters - Low-vision users and anyone in bright light cannot read prices or labels.
4. Text resizing and zoom (WCAG 1.4.4, 1.4.10).
What to test - Layout at 200% text size and at 400% zoom on a 1280-pixel-wide window. How: use browser zoom and text-only zoom.
Failure looks like - Overlapping text, hidden buttons or sideways scrolling in the basket.
Why it matters - Many customers use zoom as their main aid, and a broken layout blocks checkout.
5. Visible keyboard focus (WCAG 2.4.7).
What to test - A clear indicator on every interactive element.
How - Tab through key pages and watch for the focus outline.
Failure looks like - Outline: none with no replacement style.
Why it matters - Sighted keyboard users lose their place and make mistakes.
6. Focus not obscured (WCAG 2.4.11, new in 2.2).
What to test - That the focused element is not fully hidden behind sticky content.
How - Tab through pages with sticky headers, cookie banners and chat widgets.
Failure looks like - The focused "Pay now" button sitting under a sticky footer.
Why it matters - Users can act on controls they cannot see.
Forms, media and authentication
7. Accessible forms (WCAG 1.3.1, 1.3.5, 3.3.2, 3.3.7).
What to test - Labels, instructions, autocomplete attributes, and not asking for the same data twice.
How - Inspect the code, then complete forms by keyboard and screen reader.
Failure looks like - Placeholder text used as the only label, or a billing address that must be retyped for delivery.
Why it matters - Unclear forms cause abandoned checkouts and support calls.
8. Error identification and suggestions (WCAG 3.3.1, 3.3.3, 3.3.4).
What to test - That errors are described in text, linked to their field and announced.
How: submit forms with empty and wrong values.
Failure looks like: a red border alone, or "Invalid input" with no hint.
Why it matters: users who cannot see colour or who have cognitive disabilities cannot recover, and mistakes in financial transactions cost real money.
9. Alternative text (WCAG 1.1.1).
What to test - That product images, icons and image buttons have useful text alternatives, and decorative images are hidden from assistive technology.
How - Review the code and listen with a screen reader.
Failure looks like - "IMG_4032.jpg", or the same product name repeated on every gallery image.
Why it matters - Blind shoppers rely on it to choose between products, and only a person can judge if the text is helpful.
10. Captions and transcripts (WCAG 1.2.x).
What to test - Captions on product videos, and transcripts or audio description where needed.
How - Play each video with sound off and check that captions are accurate and synchronised.
Failure looks like - Auto-generated captions with obvious errors, or a demo video with no text alternative.
Why it matters - Deaf and hard-of-hearing customers miss key product information.
11. Accessible authentication (WCAG 3.3.8, new in 2.2).
What to test - That login and verification steps do not rely on memory, puzzles or transcription without an alternative.
How - Try signing in with a password manager, paste into fields, and complete any one-time code or CAPTCHA step.
Failure looks like - Blocked paste, or a CAPTCHA that requires picking images with no alternative.
Why it matters - People with cognitive disabilities may be locked out of their own account.
Pointer, layout and consistency
12. Touch target size (WCAG 2.5.8, new in 2.2).
What to test - That targets are at least 24 by 24 CSS pixels, or have enough spacing.
How - Inspect element sizes on a phone, especially quantity steppers, close icons and filter chips.
Failure looks like - Tiny "remove" icons packed together in the basket.
Why it matters - People with tremors or large fingers hit the wrong item.
13. Dragging movements and alternatives (WCAG 2.5.7, new in 2.2).
What to test - That anything done by dragging can also be done with a single click or tap.
How - Find sliders, drag-to-reorder lists and map pins, then try each without dragging.
Failure looks like - A price filter that works only by dragging two handles.
Why it matters - Many users cannot hold and drag with a mouse, finger or switch.
14. Consistent navigation and help (WCAG 3.2.3, 3.2.4, 3.2.6).
What to test - That menus, labels and help links (chat, phone, contact page) appear in the same place across pages.
How - Compare page templates side by side.
Failure looks like - A support link that moves on the checkout page.
Why it matters - Predictable layouts matter most to people with cognitive or visual disabilities.
The shopping journey
A four-stage accessible online shopping journey showing product discovery, basket, checkout and payment, each with an accessibility check
15. Accessible product pages.
What to test - Headings, variant selectors, image galleries, stock messages and reviews.
How - Run a complete product selection by keyboard and screen reader.
Failure looks like - A colour swatch picker with no names, or a carousel that cannot be paused or reached by keyboard.
Why it matters - If a shopper cannot choose a size or colour, they cannot buy.
16. Shopping basket accessibility.
What to test - Quantity controls, remove buttons, promo code fields, and status messages.
How - Add, change and remove items using only a keyboard and a screen reader. Failure looks like - The total updating silently after a quantity change.
Why it matters - Users lose track of what they are paying.
17. Checkout accessibility.
What to test - The step order, progress indicator, form fields, error handling and a clear review step.
How - Complete a guest checkout and a signed-in checkout with a keyboard and screen reader.
Failure looks like - Focus jumping to the top of the page after each step.
Why it matters - Checkout is where an accessibility fault becomes a lost order.
18. Payment form accessibility.
What to test - Card fields, wallet buttons, third-party payment frames and any bank verification step.
How - Test the live payment flow in a sandbox, including timeouts and extra verification pages.
Failure looks like - An embedded card frame with no accessible name, or a verification window that times out too quickly.
Why it matters - These parts are often supplied by third parties, so they are easy to overlook, and you remain responsible for the experience you offer.
Mobile and assistive technology
19. Mobile accessibility (WCAG 1.3.4, 2.5.1, 2.5.4).
What to test - Mobile web and any native app for orientation, gestures and motion controls.
How - Test on real iOS and Android devices with VoiceOver and TalkBack.
Failure looks like - Content locked to portrait, or a gesture with no simple alternative.
Why it matters - Many customers shop mainly on a phone. For apps, WCAG is applied by analogy, and EN 301 549 includes a section on software.
20. Assistive technology compatibility.
What to test - A sample of your key journeys across common screen reader and browser pairs, plus screen magnification and voice control.
How - For example NVDA with Firefox or Chrome, JAWS with Chrome, VoiceOver with Safari and TalkBack with Chrome.
Failure looks like - A flow that works in one pair but breaks in another.
Why it matters - Assistive technologies handle code differently, and compatibility is what users actually experience.
How to Perform Accessibility Testing: Step-by-Step
An eight-step accessibility testing workflow running from requirements review to final regression testing
Step 1: Identify applicable requirements - List the markets you sell into and the rules for each: EAA and national law for the EU, the Equality Act for the UK, ADA for the US. Decide your test target, for example WCAG 2.2 AA, and record why. Ask legal advisers about exemptions rather than assuming you qualify.
Step 2: Review website structure - Map the page types that make up your store: home, search, product listing, product detail, basket, checkout, account and help. Test one representative page for each template, plus every step of the main journeys. Include third-party widgets such as payment frames, chat and cookie banners.
Step 3: Run automated accessibility scans - Scan each template with a tool such as axe DevTools or WAVE to catch missing labels, contrast failures and code errors quickly. Scans are fast and repeatable, which is why they work well when added to your automation testing services or pipeline. They are a starting point, not a verdict.
Step 4: Conduct manual keyboard testing - Work through each journey without a mouse and note every trap, hidden control and missing focus indicator. This is the area where careful manual testing services find problems that scanners cannot see.
Step 5: Test with screen readers - Complete a purchase with NVDA and one other screen reader, listening for names, roles, states and announcements. Focus on the checkout and payment steps.
Step 6: Test mobile accessibility - Repeat the main journeys on real phones with VoiceOver and TalkBack, and check target sizes, orientation and gestures. If you have a native app, include mobile app testing in the same plan.
Step 7: Document and prioritise defects - For each issue record the page, steps to reproduce, the WCAG criterion, the assistive technology used and a severity. Rank defects by their effect on completing a purchase. A checkout blocker is more urgent than a decorative image missing its alt text.
Step 8: Retest fixes and perform regression testing - Confirm each fix with the same method that found it. Then re-run key checks after every release, since new features often reintroduce old problems. Keep the test records, because they show what you checked and when.
Best Accessibility Testing Tools
| Tool | Best used for | Limits to remember |
| axe DevTools | Fast automated checks in the browser and in build pipelines | Detects only issues that can be identified from code, so it cannot judge whether alt text is meaningful or the reading order makes sense |
| WAVE | Visual overlay showing errors, alerts and structure on a page | Page-by-page, so less suited to large-scale regression checks |
| Lighthouse | Quick accessibility check inside Chrome DevTools | A limited rule set. A high score does not mean the site conforms to WCAG |
| NVDA | Free screen reader for Windows, widely used for testing | Windows only, and needs practice to use well |
| VoiceOver | Built-in screen reader on macOS and iOS, important for Safari and iPhone | Behaves differently from Windows screen readers |
| JAWS | Commercial Windows screen reader used by many professional users | Paid licence and a learning curve |
No automated tool can establish WCAG conformance by itself - Many criteria need human judgement, such as whether a link's purpose is clear, whether focus order is logical or whether error text actually helps. Use tools to find the easy problems fast, then spend your human time on the rest.
Common Accessibility Testing Mistakes Businesses Should Avoid
Relying on a scan and calling it done. A clean automated report can sit on top of a checkout that a screen reader user cannot finish. The result is false confidence and defects that surface as customer complaints.
Testing only the home page - The problems that cost sales are in filters, variant pickers, basket controls and payment steps. Test journeys, not just pages.
Ignoring third-party components - Payment frames, chat widgets, cookie banners and review plugins are part of your service. If they fail, the customer experience fails.
Testing only on desktop - Many shoppers are on mobile. Target size, orientation and gesture problems show up only on real devices.
Using a script-based overlay as a substitute for fixing the code - A widget may add controls, but it does not fix underlying markup and may interfere with the assistive technology people already use. Test the site with the overlay in place, and do not treat it as proof of anything.
Skipping documentation - If a regulator or customer asks what you tested, notes in someone's head do not help. Keep dated test records, defect logs and an accessibility statement where your market expects one.
Treating accessibility as a one-off project - New promotions, banners and checkout changes can break features that passed last quarter. Build checks into releases.
How Accessibility Testing Helps International Businesses
Testing to one well-chosen standard, WCAG 2.2 AA, gives a multi-market business a single baseline to measure against, then lets legal advisers add what each country asks for. This is more efficient than keeping separate plans for the EU, UK and US.
It also reduces rework. Barriers found before a market launch are cheaper to fix than those found after complaints or a regulator's request. The same checks help everyone: clear forms, visible focus and readable contrast improve conversion for all customers, not just those who use assistive technology.
Finally, it gives you evidence. Test records, defect logs and retest results show that you took reasonable steps, which can help under the UK's reasonable-adjustments duty, and support an accessibility statement in markets where one is expected. Accessibility checks fit best inside wider software quality assurance services and release routines, so they are repeated rather than run once.
How Testriq Helps Businesses With Accessibility Testing
Testriq provides accessibility testing services for web and mobile products, including WCAG 2.2 compliance testing, e-commerce accessibility testing, enterprise accessibility audits and VPAT documentation services. The approach combines automated tools such as WAVE and axe with manual evaluation, including screen reader testing with JAWS and NVDA, and can be integrated into CI/CD pipelines for ongoing regression checks.
For a seller working across the EU, UK and US, that typically means testing your key purchase journeys against WCAG 2.2 AA, reporting each barrier against the criterion it fails, and retesting after fixes.
An accessibility audit shows where your product has barriers and what to fix first. It is not a legal certification, and Testriq is not a certification body, so use the findings alongside advice from your own legal team. If you would like to discuss your accessibility testing requirements, the team can help you scope a first assessment.
Frequently Asked Questions
1. What is the European Accessibility Act?
The European Accessibility Act (Directive (EU) 2019/882) is an EU law that sets common accessibility requirements for certain products and services, including e-commerce, consumer banking, e-books and electronic communications. Its requirements have applied since 28 June 2025.
2. Does the European Accessibility Act apply to UK businesses?
It can. The EAA is not a UK law, so a business that sells only to UK customers is not covered by it. A UK business that provides a covered service, such as an online shop, to consumers in the EU may be in scope. UK sellers also have separate duties under the Equality Act 2010. Take legal advice for your own situation.
3. Is WCAG 2.2 AA mandatory?
WCAG itself is a standard, not a law. Whether WCAG 2.2 AA is mandatory depends on the rule that applies. UK public sector bodies are held to WCAG under their regulations, with GOV.UK guidance pointing to 2.2 AA. The EAA does not name a WCAG version, and ADA Title III for private businesses does not either. WCAG 2.2 AA is still a widely used and sensible target.
4. What is the difference between EAA and WCAG 2.2?
The EAA is EU law that says certain services must be accessible. WCAG 2.2 is a technical standard from the W3C that describes how to make web content accessible. The link between them runs through EN 301 549, which incorporates WCAG. Meeting WCAG does not by itself guarantee EAA compliance.
5. Does ADA require WCAG 2.2 compliance?
No law or regulation requires private businesses to meet WCAG 2.2 by name under ADA Title III. DOJ guidance points to WCAG as a useful technical standard. For state and local governments, the 2024 Title II rule requires WCAG 2.1 AA, with compliance dates extended by one year in April 2026.
6. How can I test whether my e-commerce website is accessible?
Combine automated scans, manual keyboard testing and screen reader testing across your main purchase journey: product page, basket, checkout and payment. Test on mobile, record defects against WCAG criteria and retest after fixes. Use the 20-point checklist above as a starting plan.
7. Which accessibility testing tools should businesses use?
A common set is axe DevTools or WAVE for automated checks, Lighthouse for quick reviews, and NVDA, VoiceOver and JAWS for screen reader testing. Choose tools that match the platforms your customers use and pair them with manual testing.
8. Can automated testing detect all accessibility issues?
No. Automated tools find a subset of issues, mainly those detectable from code. They cannot reliably judge whether alt text is meaningful, whether focus order makes sense or whether an error message helps. Manual and assistive technology testing are needed for the rest.
9. Does WCAG 2.2 apply to mobile applications?
WCAG was written for web content, so it applies directly to mobile websites. For native apps, it is commonly applied by analogy, and EN 301 549 includes requirements for software that map WCAG-style criteria to apps. The EAA covers e-commerce services delivered through websites and mobile apps.
10. How often should businesses conduct accessibility testing?
Test before launch, after any major redesign or checkout change, and on a regular schedule. Add automated checks to every release and run manual journey testing at least periodically. Keep records so you can show what was tested and when.
Conclusion
A European Accessibility Act checklist is only useful if it separates what the law asks from how you test. The EAA, the UK Equality Act and ADA Title III set different duties, while WCAG 2.2 gives you a shared way to find and fix barriers. Start with your most important journeys, test with both tools and real assistive technology, keep records, and ask legal advisers to confirm what applies to you.
Sources and Further Reading
- Directive (EU) 2019/882, European Accessibility Act, EUR-Lex
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C
- What's new in WCAG 2.2, W3C
- EN 301 549, ETSI
- Commission Implementing Decision (EU) 2018/2048, EUR-Lex
- Equality Act 2010, section 20, legislation.gov.uk
- Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, legislation.gov.uk
- Accessibility requirements for public sector websites and apps, GOV.UK
- Guidance on Web Accessibility and the ADA, ADA.gov
- Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities, Federal Register, 24 April 2024
- Section 508 Refresh, Section508.gov
