Accessibility Checklist Builder — Record WCAG Review Evidence

A website accessibility checklist organizes practical checks for keyboard operation, page structure, readable content, contrast, forms, images, navigation, tables and media. Choose the relevant testing modules, add project-specific items, and record each result as passed, failed, needing review or not tested with supporting evidence. The workspace calculates review progress and exports the observations as JSON. A completed checklist documents what was examined; it does not automatically prove WCAG conformance or replace testing with assistive technology and real users.

Website Accessibility Checklist At a Glance

Planning an Accessibility Review around Real Tasks

Accessibility work is easier to manage when the checklist reflects what people actually need to accomplish on the website. A publishing page may require clear heading structure, meaningful link names and image descriptions. A checkout flow also needs keyboard-operable controls, error recovery, understandable labels and reliable status messages. Selecting modules based on the interface under review makes the resulting tasks relevant without implying that omitted areas are unnecessary. If a project includes video, data tables or custom navigation, include those modules even when the number of checks grows.

Begin by documenting the page or component, the environment, the person performing the check and the applicable standard or organizational requirements. The built-in tasks are practical prompts, not a complete catalog of every success criterion. A reviewer must decide which requirements apply to each feature. For example, captions have a different role on an audio-only recording than on a video with speech, while decorative images require a different text alternative decision from an informational chart. The checklist helps preserve those judgments instead of replacing them with an unexplained percentage.

Keyboard Navigation and Focus Management

Keyboard testing should follow a realistic sequence rather than a quick count of focusable elements. Starting at the top of the page, move with Tab and Shift+Tab through controls, activate buttons using the expected keys, and verify that custom widgets support their documented interaction model. Check whether visible focus moves in a meaningful order, whether a user can leave every popup and whether closing a dialog restores focus appropriately. A page may be superficially usable with a mouse while hiding essential actions from anyone who navigates by keyboard or an alternative input device.

Focus visibility is as important as focus reachability. At different zoom levels, the outline or other indicator should remain apparent against the surrounding interface. Fixed headers can cover focused controls, and modal overlays can create confusing order when inactive content is still reachable. Record the browser, viewport and steps taken when marking a check as passed or failed. A note such as “Tab from Submit moved to the hidden menu button” provides far more actionable evidence than a bare fail status. It gives the developer a reproducible path to repair.

Heading Structure, Landmarks and Navigation Labels

Document structure lets people understand content without scanning every visible line. A clear page title, a meaningful hierarchy of headings, and recognizable main and navigation landmarks support both visual reading and assistive-technology shortcuts. The checklist prompts a reviewer to inspect structure, not merely count H1 elements. A heading can be semantically valid and still be misleading when its wording does not describe the following section. Likewise, several navigation regions may be appropriate if their accessible labels distinguish primary navigation from utility or footer links.

Links should communicate a destination or action in context. Repeated “more” labels are difficult to interpret in a list of links, while descriptive names help users choose the correct route. A skip link can reduce repeated keyboard navigation through a large header. These checks require reading the actual interface, because automated tools cannot fully judge whether a label makes sense to its audience. Record examples of ambiguous names and the expected replacement wording so findings become development tasks rather than vague criticism.

Contrast, Resize, Reflow and Non-Color Cues

Visual accessibility involves more than selecting a dark text color. Ordinary text typically needs a contrast ratio of at least 4.5:1 for WCAG AA, while qualifying large text can use 3:1. Non-text elements that communicate state may also need sufficient contrast. Test the actual foreground and background combinations, including error states, disabled controls where relevant, icons and hover or focus indications. Gradient backgrounds and transparent overlays can complicate measurement because the visible color depends on position. A single screenshot or sampled value may not cover every relevant state.

Zoom and reflow checks reveal problems that are not visible on a wide desktop monitor. Increase the page to 200% and inspect whether text remains readable, controls are reachable and content does not require unnecessary two-dimensional scrolling. Narrow mobile layouts can hide labels or clip dialogs even when a CSS breakpoint exists. The color contrast checker can calculate a ratio for selected color pairs, but the checklist must still account for real rendered states and the meaning conveyed by surrounding visual cues.

Form Labels, Errors and Help Text

Forms deserve focused testing because failures can block a transaction, application or essential account task. Every interactive field needs a persistent accessible name that describes the expected input, and instructions should explain format restrictions before submission when practical. Placeholder text alone often disappears during entry and may not provide a reliable accessible name. Checkboxes, radio groups, autocomplete controls and custom date pickers require appropriate group descriptions and keyboard behavior. A visually polished form can still become difficult when its validation logic identifies errors only through color or an unannounced banner.

Submit representative invalid values and examine how the interface responds. The message should identify the affected field, explain what went wrong and, where appropriate, provide a path to correction. Focus should not jump unpredictably, and the user should not lose completed input without warning. Record the exact invalid example and resulting behavior in the evidence notes. This makes a checklist finding testable after developers change the code and gives reviewers a consistent way to confirm that an issue is resolved.

Images, Tables and Time-Based Media

Alternative text should communicate the purpose of an informative image, not simply restate a filename or describe every visible pixel. Decorative graphics can be removed from the accessibility tree when they convey no information. Complex charts may need a textual summary of trends and data that cannot fit in a short alt attribute. The checklist prompts a reviewer to consider whether the information remains available when the image cannot be perceived. Images serving as links or buttons also need accessible names that reflect their action, not only their appearance.

Data tables should express associations between header cells and their values through suitable markup, especially when rows or columns have multiple header levels. Layout tables should not be confused with datasets. Media testing considers accurate captions, transcripts for applicable recordings and controls over distracting movement. These checks depend on the actual content and interaction, so a generic automated pass is misleading. A reviewer should choose representative items across the site, record which ones were inspected and expand testing when patterns of defects appear.

Recording Findings without Mistaking Progress for Compliance

The workspace counts tasks marked Pass, Fail, Needs review or Not tested. Its progress percentage reflects how many tasks have received an observation, not the proportion of requirements that the site satisfies. A checklist with ten failed checks can show 100% review progress while describing a seriously inaccessible experience. This distinction prevents project dashboards from rewarding completion of paperwork instead of correction of barriers. Use the status totals to organize work, then prioritize issues by impact, frequency and how completely they block an essential task.

Evidence notes should be specific enough that another person can reproduce the outcome. Include a concise description of the action, expected behavior, actual result and relevant device or assistive-technology context. When a task is marked Needs review, explain which uncertainty remains and who will resolve it. An empty note can be acceptable for an obviously not-applicable draft item, but it is weak support for an important pass. Checklist records are most useful when reviewers maintain consistent evidence standards over multiple releases.

Exporting, Reusing and Maintaining a Review Checklist

The JSON export retains the project name, selected tasks, statuses and notes. Save it as part of the release record or attach it to the team's approved tracking system; the browser page itself should not be assumed to provide persistent storage. If you leave the workspace without downloading, the entered observations may be lost. A repeat audit can start with the same relevant modules, but it should not automatically inherit earlier pass decisions. The product may have changed, and a previously working component can regress after a design or dependency update.

For recurring projects, create a baseline of common checks and extend it with feature-specific items. Keep version labels and testing environments outside the checklist when necessary to preserve traceability. The export is a human review artifact rather than a formal declaration of conformity, and partial module selection should be disclosed in the review record. Accessible products benefit from repeated inspection throughout design, development and maintenance, not only from a final sign-off shortly before publication.

Frequently Asked Questions About Website Accessibility Checklist

Conclusion

A checklist becomes valuable when findings lead to reproducible repairs and repeat testing. Record the environment and observations, resolve blocking failures, and revisit the relevant tasks after changes rather than interpreting a completed review percentage as a declaration of accessibility.