How to Test a Website for Section 508 Compliance

Step-by-step guide to test Section 508 compliance: plan scope, run automated scans, perform manual keyboard and screen reader checks, test forms and media, document issues, and verify fixes. Prioritise critical user journeys and set up ongoing monitoring.

Testing a website for Section 508 compliance means checking that people with disabilities can access its information and services. This guide gives a practical, step-by-step plan you can run today. It covers scope, automated tools, manual checks with screen readers and keyboard only, and how to report results.

Quick summary of Section 508 and standards to use

Section 508 is a US accessibility requirement for electronic information and technology used by federal agencies. The technical criteria used to test Section 508 are mapped to WCAG standards. Use WCAG 2.0 or WCAG 2.1 conformance levels as the test reference your organisation follows, typically Level AA.

Prepare before you test

Decide scope

Choose whether you will test a single page, a template set, or the full site.
Prioritise high-traffic pages and critical user journeys such as login, search, forms, payment, and content pages.

Pick representative pages

Test at least these page types: homepage, landing page, article or content page, search results, forms, and a media page. If you have templates, test each template once. If you must sample, test the main task flows users take.

Create a test plan and artifacts

List pages and user journeys to test.
Note browser and device pairs to include.
Create a simple results template with columns for issue, WCAG criterion, severity, locator, and remediation.

Automated testing: fast coverage, limited reach

Automated tools are the fastest way to find many problems. Use them first to get a baseline.

Recommended tools

Axe Browser Extension (Deque)
WAVE Browser Extension
Lighthouse (Chrome DevTools)
Colour Contrast Analyser

How to run automated scans

Open the page in the chosen browser (desktop and mobile views where relevant).
Run one automated scanner and export the results.
Run a second scanner when possible to catch different rule sets.
Tag which issues are definite failures and which are potential issues for manual review.

Manual testing: what automated tools miss

Manual checks are essential. They find problems with keyboard focus, reading order, semantic structure, and real screen reader behaviour.

Tab through the page. Every interactive element must be reachable in a logical order.
Confirm focus is visible and focus order matches reading order.
Ensure keyboard users can open, use, and close menus, dialogs, and form controls.

Test with at least one screen reader per platform:

Windows: NVDA or JAWS
Mac and iOS: VoiceOver
Android: TalkBack

Check that headings, links, buttons, form fields, and landmarks are announced correctly. Verify alternative text for images reads sensibly. Test interactive widgets like custom dropdowns and carousels to ensure they expose correct roles and states via WAI-ARIA attributes.

Forms and labels

Every input must have a programmatic label. Label and control must be associated in the markup.
Provide clear error messages and link them to fields using aria-describedby or similar methods.
Test form submission with keyboard and screen reader only.

Images, media and captions

All meaningful images need alt text. Decorative images must be empty alt=“” or hidden from assistive tech.
Provide captions and transcripts for audio and video when content conveys information.

Headings and semantic structure

Headings should follow a logical order, starting with H2 on the page. Use semantic HTML elements such as nav, main, header, and footer where appropriate.

Visual and perceptual checks

Colour contrast

Use a contrast checker to confirm text and interactive elements meet contrast ratios for the chosen WCAG level. Check normal text, large text, icons, and focus outlines.

Zoom and responsive behaviour

Confirm the page works at 200 percent zoom and on small screens. Check that content does not overlap and controls remain operable.

Mobile testing

Test on iOS and Android browsers. Check touch targets are large enough, gestures are supplemented with alternatives, and focus management works when a virtual keyboard appears.

Common mistakes to avoid

Relying only on automated tools. They miss many keyboard and screen reader issues.
Testing only the homepage. Accessibility issues often appear inside templates and forms.
Ignoring dynamic content and custom widgets. ARIA roles and state changes must be correct.
Not verifying fixes. Patches can create new problems if not retested.

Sample reporting template

Field	What to include
Page	URL and page template
Issue	Short description of the problem
WCAG/508 reference	Relevant WCAG success criterion or Section 508 clause
Evidence	Steps to reproduce, screenshots or screen reader transcripts
Severity	Critical, major, minor
Suggested fix	Code example or remediation guidance

How to prioritise fixes

Fix items that block critical user journeys first. Then address issues that prevent keyboard use and screen reader navigation. Tackle cosmetic contrast and minor semantic issues last.

Verify fixes and set up ongoing monitoring

Retest remediated pages with the same tools and manual checks.
Integrate automated scans into CI for new code pushes.
Schedule periodic audits, after major releases and at least annually.

Quick testing checklist (copyable)

Run two automated scanners on the page
Tab through the page and confirm focus order
Test key pages with a screen reader
Check form labels and error handling
Validate colour contrast for text and controls
Confirm media has captions or transcripts
Test on at least one mobile browser and at 200 percent zoom

Tools and resources

Axe Browser Extension
WAVE Browser Extension
Chrome DevTools Lighthouse
Colour Contrast Analyser
NVDA, JAWS, VoiceOver, TalkBack

A consistent process saves time. Start with automated scans, then test manually for keyboard and screen reader behaviour. Record issues with clear evidence. Prioritise critical user journeys, verify fixes, and monitor regularly. That approach keeps a site aligned with Section 508 expectations and improves access for real users.

How to Test a Website for Section 508 Compliance