Website Accessibility: Standards, Legal Scope, and Testing
Plan accessible websites through user tasks, jurisdiction, WCAG scope, semantic code, keyboard and screen-reader work, manual testing, governance, and qualified legal review.
Website accessibility means people with different vision, hearing, movement, speech, and cognitive needs can perceive, understand, navigate, and use a site. WCAG gives testable technical guidance. Legal duties vary by entity, service, contract, funding, and jurisdiction. A WCAG result does not by itself prove legal compliance.
Start With Scope, Users, and Jurisdiction
Which legal entity owns or operates the site, app, portal, or document?
Which countries, states, sectors, contracts, and funding rules apply?
Which users, disabilities, languages, devices, and assistive tools matter?
Which public, staff, student, patient, customer, or partner tasks are in scope?
Which third-party forms, shops, maps, chat, video, files, and sign-in paths are used?
Who can give qualified legal advice for the actual entity and market?
This guide is general design and testing information, not legal advice. The ADA, Section 508, European rules, procurement terms, and local laws do not apply in the same way to every site. Record the legal scope separately from the technical standard and product scope.
Use a Jurisdiction Map, Not One Compliance Claim
ADA Title II covers state and local government services. The current U.S. rule has a web and mobile app standard and set compliance dates.
Private businesses may face different ADA Title III questions. The legal scope and remedy depend on the entity, service, court, and facts.
Section 508 applies to U.S. federal agencies and covered federal technology work.
The EU Web Accessibility Directive covers public-sector websites and mobile apps in its scope.
The European Accessibility Act covers certain products and services in its scope.
Contracts, grants, procurement rules, sector rules, and local laws may add duties.
Ask qualified counsel to identify the rule, entity, product, market, date, and exception that apply. Do not publish a broad claim that a site is ADA compliant, legally compliant, or risk free from a tool score or WCAG check.
Use WCAG as a Testable Technical Baseline
WCAG 2.2 organizes guidance under four principles: content and controls should be perceivable, operable, understandable, and robust. Teams often choose a target level such as AA because a law, policy, contract, or product standard points to it. State the exact WCAG version, level, pages, flows, platforms, and exceptions being tested.
Map Critical User Tasks
Find core information and understand page structure.
Navigate menus, search, filters, dialogs, and accordions.
Read or hear images, charts, tables, alerts, and status changes.
Complete forms, correct errors, sign in, pay, book, or apply.
Play media with captions, transcripts, controls, and alternatives.
Open, read, save, and complete linked documents.
Build With Semantic Structure
Use one clear page title and a logical heading order.
Use native links, buttons, form controls, lists, tables, and landmarks first.
Give controls an accessible name, role, value, state, and instruction.
Connect labels, help, errors, and status messages to the right field.
Use ARIA only when native HTML cannot express the needed pattern.
Keep reading order and focus order aligned with the task.
Support Keyboard and Focus
Reach and use each control without a mouse.
Show a visible focus indicator with enough contrast.
Do not trap focus or move it without a clear reason.
Return focus to a useful place when a dialog or menu closes.
Provide a way to skip repeated content.
Test custom widgets with the expected key pattern.
Handle Images, Color, Media, and Motion
Write useful alt text for informative images and empty alt text for decoration.
Give charts and diagrams an equivalent explanation or data view.
Meet the chosen contrast requirements and do not use color alone for meaning.
Provide captions, transcripts, audio description, or another valid alternative as required.
Let people pause, stop, hide, or avoid harmful motion where the criterion applies.
Keep zoom, reflow, orientation, and text spacing usable.
Test Forms and Errors
Give each field a clear label and purpose.
Explain required format before an error occurs.
Identify the field and problem in text after an error.
Preserve entered data when the user can safely correct it.
Review high-impact legal, financial, and data submissions before final action.
Test time limits, authentication, CAPTCHA, and recovery routes.
Automation Is One Layer
Automated tools can find some code-level issues. They cannot prove that alt text is useful, focus order makes sense, instructions are clear, or a task works with assistive technology. Use code checks, browser checks, keyboard tests, screen-reader tests, zoom and reflow checks, content review, and user testing with disabled people.
Use Tools for the Faults They Can Find
axe, WAVE, and Lighthouse can flag some code and contrast faults.
Browser accessibility trees can show names, roles, states, and page structure.
Contrast tools can test chosen color pairs.
Keyboard tests can expose focus, order, trap, and control faults.
NVDA, JAWS, VoiceOver, or TalkBack can test supported screen-reader paths.
User tests can reveal task, language, context, and support barriers tools miss.
Tool coverage and rules change. Record the tool, version, settings, browser, page, date, and tester. A clean automated report means only that the selected checks found no listed fault.
Prefer Native Code Patterns
Use a real button for an action, not a clickable div.
Use a real link for a change of page or location.
Pair each form field with a visible label.
Use empty alt text for a decorative image.
Use a useful text alternative for an image that carries meaning.
Add ARIA only when native HTML cannot express the pattern.
Include Mobile, Documents, and Vendors
Test responsive web tasks at supported sizes and input modes.
Review native apps under the standard and rules that apply to them.
Check PDFs, office files, email, video, and downloadable forms.
Test embedded shops, chat, maps, booking, payment, and identity tools.
Write accessibility requirements, evidence, fixes, and exit rights into vendor work.
Provide an accessible support and feedback route when a barrier remains.
Create an Accessibility Governance Loop
Name product, design, content, engineering, QA, legal, and support owners.
Add accessible patterns and examples to the design system.
Test new work before release and core flows on a set schedule.
Record defects by user impact, task, standard, owner, and due date.
Publish only accurate accessibility statements and known limits.
Track feedback, repairs, repeat faults, training, and vendor performance.
Run a Plain First Test
Pick one key task, such as finding a price, booking a visit, or sending a form. Start at the home page. Use the site with a keyboard only. Do not use a mouse. Make sure each step can be seen, reached, used, and left.
Can you see where focus is now?
Does focus move in an order that makes sense?
Can you open and close each menu or box?
Can you read the name of each link and button?
Can you fill each field and fix an error?
Can you reach help without losing your work?
Can you finish the task without a time trap?
Can you go back without being sent to the start?
Then run the same task with a screen reader. Listen to the page title, headings, links, fields, errors, and status notes. A page may look clear but sound hard to use. Write down the user harm, not just the code fault.
Check Zoom and Small Screens
Zoom the page and make sure text stays clear.
Check that lines do not run off the screen.
Make sure the page can reflow without a side scroll where the rule applies.
Keep buttons and links large enough to use.
Do not hide key facts when the screen is small.
Make sure a fixed bar does not cover the task.
Test both touch and a linked keyboard.
Check the task in each supported view.
Fix by User Harm
Fix a task that no one can finish first.
Fix lost data and unsafe errors next.
Fix paths used by many people before rare paths.
Fix shared parts before the same fault spreads.
Give each fault an owner and due date.
Test the fix with the same task and tool.
Keep proof of what was checked.
Do not call the whole site compliant from one fixed page.
Track the Next Standard Without Claiming It Is Current
W3C work on WCAG 3 may shape future guidance. It is not a replacement for the current standard used by a law, policy, or contract today. Track drafts for planning, but test and report against the exact standard that now applies.
Use the WCAG compliance guide for the technical baseline and the ADA website guide for a separate U.S. legal-scope starting point.
The Short Answer
Accessible websites require more than an automated score or a compliance label. Define users, tasks, jurisdiction, WCAG scope, product boundaries, and legal review. Build semantic paths, then test with multiple methods and real users. Keep accessibility in design, content, code, procurement, support, and maintenance.
Need an accessibility baseline?
TTGC can map product scope, user tasks, WCAG targets, design and code checks, manual tests, vendor gaps, governance, and upkeep. We do not certify legal compliance or guarantee risk, ranking, revenue, or return.
Sources
- W3C — Web Content Accessibility Guidelines 2.2. https://www.w3.org/TR/WCAG22/
- W3C — Evaluating Web Accessibility Overview. https://www.w3.org/WAI/test-evaluate/
- U.S. Department of Justice — Guidance on Web Accessibility and the ADA. https://www.ada.gov/resources/web-guidance/
- U.S. Department of Justice — Fact Sheet: New Rule on Web Content and Mobile Apps for State and Local Governments. https://www.ada.gov/resources/2024-03-08-web-rule/
- U.S. General Services Administration — Section508.gov. https://www.section508.gov/
- European Commission — Web accessibility. https://digital-strategy.ec.europa.eu/en/policies/web-accessibility
- European Commission — European Accessibility Act. https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en
- W3C — WCAG 3 Introduction. https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/
