A website accessibility audit checks whether people with different disabilities can perceive, understand and operate a website. A beginner can identify many important barriers, but a quick checklist or automated score is not the same as a complete WCAG conformance evaluation.
Quick answer: combine automated scanning with manual keyboard, zoom, screen-reader and content checks. Record the affected page, barrier, user impact and proposed fix, then retest with the same method.
This checklist builds on the principles in Inclusive Web Design and uses WCAG 2.2 and W3C WAI evaluation guidance as primary references.
Choose a representative sample
For a small site, test every important template: home page, article, archive, contact form, search results and any purchasing or account journey. Include the busiest pages and pages containing unusual components such as tables, video, accordions or carousels.
Record browser, device, zoom level, tool and exact steps. Accessibility defects are easier to fix when a developer can reproduce them.
Check the page title and language
Each page needs a descriptive browser title that distinguishes it from other pages. The document language should be identified correctly so assistive technology can apply suitable pronunciation rules.
Put the mouse aside. Use Tab and Shift+Tab to move, Enter or Space to activate controls, and arrow keys where a component’s expected keyboard pattern uses them.
- Can every interactive control be reached?
- Does focus move in a logical order?
- Can menus, dialogs and forms be operated and exited?
- Does focus ever become trapped or disappear?
- Is there a skip link for repeated navigation where appropriate?
Confirm that keyboard focus is visible
A user must be able to see which link, button or field currently has focus. Look for a clear outline or other indicator with sufficient contrast. Do not remove the browser outline unless an equally clear replacement is provided.
Review heading structure
Check that the page has a descriptive main heading and that sections follow a meaningful hierarchy. A heading should introduce the content beneath it; bold text styled to look like a heading does not provide the same structure to assistive technology.
Inspect images and alternative text
Informative images need text alternatives that communicate their purpose in context. Decorative images should usually have empty alternative text so they are skipped. Do not begin every description with image of, and do not repeat adjacent caption text unnecessarily.
Complex charts may need a short alt attribute plus a nearby explanation or data table. Google’s image guidance also recommends placing meaningful images near relevant text and using descriptive filenames.
Test colour and contrast
Use a contrast checker for text, controls, focus indicators and meaningful graphical elements. Also check that colour is not the only way the page communicates an error, selection or status.
Test interactive states, not only the default view. Hover, focus, disabled and error states can use different colour combinations.
Zoom and reflow the page
Zoom text and page content and test at a narrow viewport. Content should remain readable without losing information or requiring two-dimensional scrolling for ordinary text. Check navigation, cookie controls, tables, code samples and sticky elements.
The accessible name should explain the destination or action. Avoid repeated ambiguous links such as read more when the surrounding programmatic context does not distinguish them. Use links for navigation and buttons for actions.
Test forms, labels and errors
- Every field has a persistent, programmatically associated label.
- Required formats and requirements are explained before submission.
- Errors identify the field and explain how to correct the problem.
- Error messages do not rely on colour alone.
- Focus and screen-reader announcements make submission results discoverable.
- Autocomplete attributes are used where they meaningfully help users.
Check motion, audio and time limits
Users need control over unexpected audio, moving content and carousels. Respect reduced-motion preferences where animation is not essential. Explain time limits and provide a way to extend them when the relevant WCAG requirements apply.
Sample with a screen reader
A short screen-reader review can reveal missing names, repeated announcements and confusing reading order. Test the page title, landmarks, heading list, links, forms and main task. Screen-reader testing requires practice and should complement—not replace—testing with disabled users.
Run automated tools, then verify manually
Automated tools are useful for detecting certain missing labels, invalid relationships and contrast failures. They cannot decide whether alternative text is useful, the reading order makes sense or instructions are understandable. Review every finding and test important components manually.
Finding | User impact | Priority example |
|---|---|---|
Checkout cannot be completed by keyboard | Blocks a core task | Urgent |
Form error is not announced | Prevents some users correcting input | High |
Heading level is skipped | Makes navigation less predictable | Medium, depending on context |
Decorative image has repetitive alt text | Adds noise | Low to medium |
Turn the audit into fixes
- Describe the barrier and affected users, not only the rule number.
- Attach the exact page, component and reproduction steps.
- Fix shared theme or design-system components before isolated instances.
- Test the change with the original method and assistive technology.
- Add the lesson to design, content and development standards.
A component-level fix can improve many pages at once. This is one reason a maintained web design system is valuable: accessible patterns can be documented, reused and tested consistently.
Frequently Asked Questions
Here are some common questions about reviewing website accessibility.
Can an automated tool complete an accessibility audit?
No. Automated tools detect some code-level issues, but they cannot reliably judge whether content is understandable, alternative text is useful or a complete user journey works with assistive technology.
Does passing this checklist mean a website is WCAG compliant?
No. This is a practical first review, not a formal conformance assessment. A complete evaluation requires broader testing against applicable WCAG success criteria and may require specialist and disabled-user involvement.
How often should accessibility be tested?
Test important components during design and development, check new content before publication and repeat representative audits after theme, plugin or navigation changes. Accessibility works best as an ongoing process.
Which accessibility problem should be fixed first?
Prioritise barriers that prevent people completing essential tasks, such as inaccessible navigation, forms, account access or purchasing. Fix shared components before isolated page instances when possible.
Final Thoughts
Use this checklist to find obvious barriers and establish a repeatable process. For high-risk services, legal claims or formal conformance statements, involve experienced accessibility specialists and disabled users. WCAG provides testable requirements, while real user feedback shows whether the experience works in practice.
Primary references: WCAG 2.2, W3C WAI Easy Checks and the W3C evaluation tools list.
