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 many different needs can use a site. That covers vision, hearing, movement, speech, and thinking. They can see it, understand it, and move through it. WCAG gives clear technical guidance you can test. Legal duties change with the entity, the service, the contract, the funding, and the place. A WCAG result on its own does not prove you meet the law.
Start With Scope, Users, and Jurisdiction
Which legal entity owns or runs the site, app, portal, or file?
Which countries, states, sectors, contracts, and funding rules apply?
Which users, disabilities, languages, devices, and helper tools matter?
Which public, staff, student, patient, customer, or partner tasks are in scope?
Which outside forms, shops, maps, chat, video, files, and sign-in paths do you use?
Who can give sound legal advice for this entity and market?
This guide shares general design and testing information. It is not legal advice. The ADA, Section 508, European rules, procurement terms, and local laws do not apply to every site the same way. Write down the legal scope on its own. Keep it apart from the technical standard and the product scope.
Use a Jurisdiction Map, Not One Compliance Claim
ADA Title II covers state and local government services. The current U.S. rule sets a web and mobile app standard. It also sets dates to meet it.
Private firms may face other ADA Title III questions. The scope and remedy hinge on the entity, the service, the court, and the facts.
Section 508 applies to U.S. federal agencies and the federal tech work they cover.
The EU Web Accessibility Directive covers public-sector websites and mobile apps in its scope.
The European Accessibility Act covers some products and services in its scope.
Contracts, grants, buying rules, sector rules, and local laws may add duties.
Ask qualified counsel which rule, entity, product, market, date, and exception apply to you. Do not publish a broad claim that a site is ADA compliant, legally compliant, or risk free. A tool score or a WCAG check cannot support that claim.
Use WCAG as a Testable Technical Baseline
WCAG 2.2 sorts its guidance under four principles. People must be able to see your content, use it, understand it, and rely on it. Teams often pick a target level such as AA, because a law, policy, contract, or product standard points them to it. State the exact WCAG version and level you test. State the pages, flows, platforms, and exceptions as well.
Map Critical User Tasks
Find key facts and get how the page is built.
Move through menus, search, filters, dialogs, and accordions.
Read or hear images, charts, tables, alerts, and status changes.
Fill in forms, fix errors, sign in, pay, book, or apply.
Play media with captions, transcripts, controls, and other options.
Open, read, save, and fill in linked files.
Build With Semantic Structure
Use one clear page title and a heading order that makes sense.
Reach for native links, buttons, form controls, lists, tables, and landmarks first.
Give each control a name, role, value, state, and clear instruction.
Tie labels, help, errors, and status notes to the right field.
Use ARIA only when plain HTML cannot do the job.
Keep reading order and focus order in step with the task.
Support Keyboard and Focus
Reach and use each control without a mouse.
Show a focus ring you can see, with enough contrast.
Do not trap focus or move it for no clear reason.
Send focus back to a useful spot when a dialog or menu closes.
Give people a way to skip content that repeats.
Test custom widgets with the keys people expect.
Handle Images, Color, Media, and Motion
Write helpful alt text for images that inform. Leave alt text empty for decoration.
Give charts and diagrams an equal explanation or a data view.
Meet the contrast rules you chose. Never use color alone to carry meaning.
Give captions, transcripts, audio description, or another valid option as needed.
Let people pause, stop, hide, or dodge harmful motion where the rule applies.
Keep zoom, reflow, screen turn, and text spacing easy to use.
Test Forms and Errors
Give each field a clear label and purpose.
Explain the format you need before an error shows up.
Name the field and the problem in text after an error.
Keep what people typed when they can safely fix it.
Let people review big legal, money, and data forms before they send them.
Test time limits, sign-in, CAPTCHA, and ways to recover.
Automation Is One Layer
Automated tools can find some faults in the code. They cannot prove that alt text is useful, or that focus order makes sense. They cannot tell you if the instructions are clear. They cannot tell you if a task works with assistive technology. Use code checks, browser checks, keyboard tests, and screen-reader tests. Add 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 the color pairs you chose.
Keyboard tests can expose faults in focus, order, traps, and controls.
NVDA, JAWS, VoiceOver, or TalkBack can test the screen-reader paths they support.
User tests can show barriers in the task, words, context, and support that tools miss.
Tool coverage and rules change over time. Record the tool, version, settings, browser, page, date, and tester. A clean automated report means one thing only. The checks you selected found no listed fault.
Prefer Native Code Patterns
Use a real button for an action, not a div you can click.
Use a real link to move to a new page or place.
Pair each form field with a label people can see.
Leave alt text empty for an image that is just decoration.
Give a useful text option for an image that carries meaning.
Add ARIA only when plain HTML cannot do the job.
Include Mobile, Documents, and Vendors
Test web tasks at the screen sizes and input modes you support.
Review native apps under the standard and rules that apply to them.
Check PDFs, office files, email, video, and forms people download.
Test built-in shops, chat, maps, booking, payment, and identity tools.
Write accessibility needs, proof, fixes, and exit rights into vendor deals.
Give people an easy support and feedback route when a barrier stays.
Create an Accessibility Governance Loop
Name owners in product, design, content, engineering, QA, legal, and support.
Add accessible patterns and examples to the design system.
Test new work before release. Test core flows on a set schedule.
Log defects by user harm, task, standard, owner, and due date.
Publish only true accessibility statements and known limits.
Track feedback, repairs, repeat faults, training, and vendor work.
Run a Plain First Test
Pick one key task. It could be finding a price, booking a visit, or sending a form. Start at the home page. Use the site with a keyboard only, and never touch the mouse. Check that you can see, reach, use, and leave each step.
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 and still sound hard to use. Write down the harm to the user, not just the code fault.
Check Zoom and Small Screens
Zoom the page and check that text stays clear.
Check that lines do not run off the screen.
Make sure the page can reflow with no side scroll where the rule applies.
Keep buttons and links big enough to use.
Do not hide key facts on a small screen.
Make sure a fixed bar does not cover the task.
Test both touch and a keyboard you plug in.
Check the task in each view you support.
Fix by User Harm
Fix a task that no one can finish first.
Fix lost data and unsafe errors next.
Fix paths many people use before rare ones.
Fix shared parts before the same fault spreads.
Give each fault an owner and a due date.
Test the fix with the same task and tool.
Keep proof of what you 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 does not replace the current standard that a law, policy, or contract uses today. Track the drafts for planning. Test and report against the exact standard that applies now.
Use the WCAG compliance guide for the technical baseline. Use the ADA website guide for a separate look at U.S. legal scope.
The Short Answer
Accessible websites need more than an automated score or a compliance label. Define your users, tasks, jurisdiction, WCAG scope, product limits, and legal review. Build clear, semantic paths first. Then test in several ways, and test with 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/
