Section 508 Website Compliance Checklist: How to Test for Accessibility

Section 508 website compliance checklist: what to test first

This Section 508 website compliance checklist shows the tests to run, the acceptance criteria, and a step by step workflow you can use right away. Use it for quick checks, full accessibility audits, or acceptance testing of deliverables for federal contracts.

Who must meet Section 508 and what standard it uses

Section 508 applies to federal agencies and to contractors when the contract requires accessible electronic and information technology. The Section 508 Standards reference WCAG 2.0 Level A and AA success criteria. Agencies commonly follow more recent WCAG versions such as 2.1 or 2.2 for broader coverage, but the baseline named in the Section 508 Standards maps to WCAG 2.0 A and AA.

How this checklist is organised

Tests are grouped by the accessibility principles used in WCAG: Perceivable, Operable, Understandable, and Robust. For each item you will find a simple pass/fail test and a short note on common fail causes or quick fixes.

Perceivable checks (visual and auditory content)

1. Alternative text for images

• Test: Inspect images. Every informative image must have an alt attribute conveying the same purpose as the image.
• Fail signs: Decorative images without empty alt=“” or important images with missing or irrelevant alt text.
• Quick fix: Add concise, descriptive alt text. Use empty alt for purely decorative images.

2. Colour contrast

• Test: Measure text contrast with a tool. Normal text must meet 4.5:1. Large text must meet 3:1.
• Fail signs: Low contrast links, placeholder text used as labels, icons with no accessible name.
• Quick fix: Adjust foreground or background colours. Use WCAG contrast ratios as a minimum.

3. Captions and transcripts for audio and video

• Test: Verify captions are present for prerecorded video and live captions where required. Provide transcripts for audio-only content.
• Fail signs: Videos without captions, automated captions left unedited when inaccurate.
• Quick fix: Add accurate captions and a full transcript.

4. Time-based media and seizures

• Test: Ensure content does not flash more than three times per second and provide controls for auto-playing media.
• Fail signs: Rapid flashing animations and forced auto-play audio or video with no pause control.
• Quick fix: Remove or redesign flashing content and add play/pause controls.

Operable checks (keyboard and navigation)

5. Keyboard access

• Test: Operate every page using keyboard only (Tab, Shift+Tab, Enter, Space, Arrow keys). All interactive controls must be reachable and usable.
• Fail signs: Hidden focusable controls, custom controls that require mouse, focus traps inside dialogs.
• Quick fix: Ensure elements are in the tab order, add keyboard handlers, and manage focus when opening and closing dialogs.

6. Focus visible and logical order

• Test: Tab through the page and confirm the focus indicator is visible and the order matches reading order.
• Fail signs: No visible focus ring, focus jumps unpredictably, or DOM order differs from visual order.
• Quick fix: Keep DOM order consistent with visual layout and use CSS to preserve the focus outline or provide an alternative that meets contrast requirements.

7. Skip links and consistent navigation

• Test: Use a skip-to-content link and verify consistent navigation across pages.
• Fail signs: No skip link for keyboard users and inconsistent menus between pages.
• Quick fix: Add an early, keyboard-focusable skip link and standardise navigation structure.

Understandable checks (content and forms)

8. Clear labels and instructions

• Test: Every form control must have a programmatic label. Instructions and required fields must be obvious.
• Fail signs: Placeholder text used as a label, controls lacking a label or aria-label, confusing error messages.
• Quick fix: Add label elements or aria-label attributes. Provide inline instructions where needed.

9. Error identification and suggestions

• Test: Intentionally submit forms with errors. Confirm errors are announced, identified, and suggestions are provided.
• Fail signs: Generic error messages with no field focus or guidance on how to fix the error.
• Quick fix: Tie errors to fields with aria-describedby, move focus to the first error, and provide clear remediation text.

10. Readable language and predictable behaviour

• Test: Ensure page language is declared, link text makes sense out of context, and dynamic changes are predictable.
• Fail signs: Missing lang attribute, links labelled “click here” or widgets that change without announcement.
• Quick fix: Add lang attribute, use descriptive link text, and use ARIA live regions for dynamic updates.

Robust checks (code and assistive tech)

11. Semantic markup and ARIA use

• Test: Use HTML landmarks, headings in order, and minimal ARIA. Verify roles, states, and properties are correct.
• Fail signs: Overuse of ARIA when native HTML would work, incorrect ARIA roles or missing roles on widgets.
• Quick fix: Prefer native HTML elements, then add ARIA only when necessary and follow WAI-ARIA authoring practices.

12. Accessible documents and attachments

• Test: Open PDFs and Word files. Check they are tagged, have reading order, and contain searchable text.
• Fail signs: Scanned images without OCR, untagged PDFs, missing headings in documents.
• Quick fix: Produce tagged PDFs, run OCR on scans, and include document titles and headings.

13. Mobile and responsive behaviour

• Test: Use touch-only navigation and zoom to 200% to confirm content remains usable and readable.
• Fail signs: Controls becoming unreachable when zoomed, content clipped or overlapping at high zoom.
• Quick fix: Use relative units, responsive breakpoints, and reflow-friendly layouts.

Testing workflow: step by step

1. Run an automated scan across key pages with tools such as axe, WAVE, or Lighthouse to find obvious failures.
2. Perform a keyboard-only pass and check focus order, focus visible, and usable widgets.
3. Check colour contrast on pages with normal and large text and on interactive controls.
4. Open a representative set of pages with a screen reader (NVDA or VoiceOver) and validate landmark, heading, and form navigation.
5. Test media: captions, transcripts, and controls for video and audio. Test PDF and document accessibility.
6. Create a remediation list prioritised by user impact and ease of fix. Include screenshots or short recordings for developers.
7. After fixes, run a regression pass: automated scans, keyboard and screen reader checks, and user testing with at least one assistive technology user if possible.

Acceptance criteria checklist (copy this for sign-off)

Check	Pass condition
Alt text for informative images	All informative images have meaningful alt text or empty alt for decoration
Colour contrast	Text meets 4.5:1 or 3:1 for large text
Keyboard accessibility	All interactive elements operable via keyboard
Visible focus	Focus indicator present and meets contrast
Forms	Labels present, errors identified, and guidance provided
Media	Captions, transcripts, and controls provided
Documents	PDFs and attachments are tagged and searchable
Screen reader navigation	Landmarks and headings give a logical outline

Common mistakes that fail Section 508 tests

• Relying only on automated tools. They catch about 20 to 50 percent of issues but miss keyboard and screen reader problems.
• Using placeholder text as the only label. Placeholders disappear when users type and are not programmatic labels.
• Overusing ARIA instead of correct HTML. ARIA can make things worse if applied incorrectly.
• Not testing documents and multimedia. PDFs, slides and video are often released without accessibility work.
• Skipping user testing with people who use assistive technology. That testing finds real-world barriers automated tools miss.

Remediation tips for common failures

• Missing alt text: Review content purpose and add concise alt attributes or decorative empty alt attributes.
• Keyboard traps in modals: Ensure focus moves to the first focusable element inside the modal and returns on close.
• Poor contrast: Use a contrast simulator to pick accessible colour pairs and test in realistic lighting conditions.
• Incorrect ARIA: Replace ARIA roles with native elements where possible and reference WAI-ARIA authoring practices when needed.

What to include in an accessibility report

• Scope: pages and components tested. State whether mobile and documents were included.
• Tools and assistive tech used: name automated tools and screen reader versions.
• Findings: clear description, steps to reproduce, severity, and screenshots or recordings.
• Remediation guidance: code examples, priority, and estimated effort.
• Acceptance tests: specific checks to confirm fixes.

Final checks before sign-off

• Confirm automated scans against the latest code baseline.
• Run keyboard and screen reader passes on the production build.
• Verify documents and media were replaced or remediated.
• Include at least one real user with an assistive device in final acceptance testing when possible.

If you need a single printable checklist, copy the Acceptance criteria table and the testing workflow into your project checklist. Use the remediation tips to set priorities and do a final user test with assistive technology for the best assurance of Section 508 compliance.