The Web Accessibility Checklist

Key takeaways

• Build accessibility in from the start. Retrofitting it after launch costs far more than designing it in from the first wireframe.
• Cover the high-impact basics first: color contrast, keyboard navigation, alt text, and proper heading structure.
• Test with a keyboard and a screen reader, not only automated tools, since automated checks catch only part of the problem.
• Treat this web accessibility checklist as a working document your whole team runs against every page, not a one-time audit.

Why accessibility is a build decision, not a launch task

The most expensive way to handle accessibility is to ignore it until a launch review or a complaint forces the issue. By then the fixes touch structure, color, and components that were built without it in mind, so what could have been a design choice becomes a costly rebuild. Accessibility is cheapest and best when it shapes decisions from the first wireframe.

That is the spirit of this web accessibility checklist. It is not a final gate to pass before shipping, it is a set of habits applied throughout the work. When contrast, keyboard order, and semantic markup are considered as each screen is designed and built, meeting standards stops being a scramble. A site built this way passes an audit almost as a side effect, because the accessibility was never separate from the design in the first place.

Color contrast and visual clarity

Start with contrast, since low-contrast text is the most common accessibility failure on the web. Normal text needs a ratio of at least 4.5 to 1 against its background under WCAG AA, and large text needs 3 to 1. Interface elements and meaningful icons need 3 to 1 as well. Check the lightest, smallest text first, because that is where designs slip below the line.

Beyond raw contrast, never rely on color alone to convey meaning. Pair color with text, icons, or shapes so colorblind users are not excluded, and make sure links are distinguishable from body text by more than hue. This part of the web accessibility checklist is quick to verify with a contrast tool and catches problems that otherwise pass every sighted reviewer with good lighting and a decent screen.

Keyboard navigation and focus

Many people navigate without a mouse, using a keyboard, switch device, or assistive technology that emulates one. Every interactive element on the page must be reachable and operable with the keyboard alone. Tab through your whole page and confirm you can reach every link, button, and form field, and that you can activate each one without touching the mouse.

Two failures show up constantly. First, a missing or invisible focus indicator, so a keyboard user cannot tell where they are on the page. Keep a clear visible focus ring rather than removing it for aesthetics. Second, keyboard traps, where focus enters a component like a modal and cannot get out. On the web accessibility checklist, keyboard access is non-negotiable, because a site you cannot operate without a mouse excludes a large group of users outright.

Alternative text and media

Images need text alternatives so screen reader users get the information a sighted user gets from the picture. Write alt text that conveys the purpose of the image in context, not a literal description of every pixel. A product photo, a chart, and a decorative flourish each need different treatment, and getting this right takes judgment rather than a formula.

The rules worth building into the web accessibility checklist are straightforward:

• Informative images get concise alt text describing their meaning in context
• Decorative images get empty alt text so screen readers skip them
• Charts and infographics need the data conveyed in text nearby, not locked in the image
• Videos need captions, and audio-heavy content needs a transcript

Media accessibility is frequently skipped because it takes effort, but an uncaptioned video excludes deaf users entirely, and a chart with no text alternative hides its data from anyone using a screen reader.

Semantic structure and headings

Screen reader users navigate by structure, jumping between headings and landmarks the way a sighted user scans a page visually. That only works if the underlying markup is semantic. Use real heading elements in a logical order, one main heading per page followed by properly nested subheadings, rather than styling a plain div to look like a heading.

Use the right element for the job throughout. Buttons should be buttons, lists should be lists, and navigation should sit in a nav landmark, so assistive technology announces each correctly. This part of the web accessibility checklist costs nothing extra when building fresh, since it is a matter of choosing the correct tag rather than adding work. It only becomes painful when a site built entirely from generic containers has to be rewired after the fact to make sense to a screen reader.

Accessible forms

Forms are where accessibility failures cause the most direct harm, because a user who cannot complete a form cannot buy, sign up, or contact you. Every input needs a real label that is programmatically associated with it, not a placeholder standing in for one, since placeholders vanish on typing and are poorly announced by screen readers.

Error handling deserves particular care. When validation fails, identify which field has the problem in text, describe how to fix it, and move focus to it so the user is not hunting blindly. Do not signal errors with color alone. Group related fields with clear structure, and keep required fields marked in text as well as visually. On the web accessibility checklist, forms earn extra scrutiny because they sit directly on the path to conversion, so a form failure is both an accessibility failure and a lost customer.

Testing beyond automated tools

Automated scanners are useful and limited. They catch missing alt attributes, some contrast failures, and structural problems, but they cannot judge whether alt text is meaningful, whether focus order makes sense, or whether a screen reader experience is coherent. Studies consistently show automated tools catch only a portion of real accessibility issues, so relying on them alone gives false confidence.

Supplement them with manual testing. Tab through the page with only a keyboard. Turn on a screen reader and try to complete the main tasks. Zoom the page to 200 percent and check that nothing breaks or overlaps. These manual passes on the web accessibility checklist find the problems that matter most to real users, the ones automated tools quietly miss. A green score from a scanner is a starting point, not proof that a disabled person can truly use your site.

Making accessibility a habit, not an audit

The sites that stay accessible are the ones where accessibility is part of everyday work rather than an annual event. Bake the checks into design reviews, component libraries, and code review so that passing them is the default. An accessible component built once and reused everywhere spreads good behavior across the whole site with no extra effort per page.

If you want an audit of your current site or help building accessibility into your design system from the start, our team does both as part of design and development work. Explore our web design guides for related tactics on inclusive interfaces. Run this web accessibility checklist as a living document, revisit it as your site grows, and accessibility stops being a burden and becomes the quiet standard everything you build meets.

More web design & development guides