Website accessibility checklist for designers, devs and auditors

This website accessibility checklist gives you a WCAG A/AA-aligned set of fixes you can run today, organised so a designer, developer or auditor knows exactly what to own. Run these six checks in the next half hour: add descriptive alt text to non-decorative images, fix any body text under a 4.5:1 contrast ratio, confirm every interactive element works with a keyboard alone, add captions to video content, check that forms have visible labels, and make sure focus order follows the visual layout. None of these require a rebuild.

Assign them now:

• Alt text and image audit — designer or content writer, 20 minutes per key page
• Contrast check on body text and buttons — designer, using a browser plugin
• Keyboard-only pass through main flows — developer or auditor
• Caption check on video/audio content — content owner
• Form label and error message review — developer
• Focus order and skip link check — auditor or QA

Key Takeaways

Meeting WCAG Level AA requires fixing Perceivable, Operable, Understandable and Robust issues together, tested with both automated tools and manual keyboard and screen reader checks.

Table of Contents

• How to use this website accessibility checklist
• Perceivable: images, media, contrast and text alternatives
• Operable: keyboard access, navigation, timing and input
• Understandable: clear content, predictable behaviour and accessible forms
• Robust: semantic HTML, ARIA and assistive-technology compatibility
• Making tables, charts and interactive widgets accessible
• PDFs and downloadable documents: what needs tagging
• Testing methodology: tools plus hands-on checks
• Prioritising fixes: what to tackle first
• Handling error prevention and recovery beyond form errors
• Guidance on handling dynamic content and updates
• Addressing colour blindness and vision beyond contrast
• Guidelines on accessible navigation and consistent structure
• Considerations for mobile accessibility and responsive design
• What accessibility audits actually reveal
• How CantyDigital helps you get compliant, faster
• Sources

How to use this website accessibility checklist

Run this checklist at three points: before launch as a hard gate, during routine QA on every sprint, and as a full audit every six to twelve months or after a major redesign. Treat pre-launch as non-negotiable — fixing a form’s missing labels after go-live costs far more than catching it in review.

Ownership splits naturally by skillset. Designers own contrast, colour independence, spacing and focus-state visuals. Front-end developers own semantic markup, ARIA attributes, keyboard operability and form logic. Auditors (internal or external) own the manual testing pass, screen reader verification and sign-off against WCAG success criteria.

The remediation process itself is simple: triage every issue by impact and effort, apply quick fixes immediately (contrast, alt text, labels), raise developer tickets for anything structural (navigation, component rebuilds), then verify each fix with the same test method that found the fault. Skipping verification is where most teams lose the thread — a “fixed” ticket that was never retested is not fixed.

Pro Tip: Add an automated accessibility scan (axe or Lighthouse) as a required check in your CI/CD pipeline. It won’t catch everything, but it stops obvious regressions — like a missing alt attribute — from ever reaching a pull request review.

Perceivable: images, media, contrast and text alternatives

Perceivable means users can actually detect your content, whether they’re using a screen reader, browsing with the sound off, or living with low vision. This is where most sites lose the most points, and where fixes are usually cheapest.

Run through this list on every page template:

• Every non-decorative image has descriptive alt text; purely decorative images use an empty alt="".
• Link text describes the destination or action (“Download the 2026 pricing guide,” not “click here”).
• No image-of-text where real text would do the job — search engines and screen readers can’t read pixels.
• Every video has captions; every audio-only file has a text transcript.
• Colour is never the only way information is conveyed (a red border on an invalid field also needs an icon or text).

Contrast is the single biggest quick win on this list. WCAG’s baseline requires a 4.5:1 ratio for normal text and 3:1 for large text (defined as 18pt or 14pt bold and above) at Level AA — the practical target for almost every commercial site. Level AAA pushes to 7:1, which is usually overkill outside government or health services with legal obligations to reach it.

Around a third of common accessibility failures found on live sites trace back to poor colour contrast, missing alt text, absent captions or forms that can’t be read by assistive tech — the same handful of issues flagged repeatedly by the ADA’s own web guidance.

Testing contrast takes seconds with a browser extension or the colour picker in most design tools. When you log a failing element in a ticket, include a screenshot, the specific CSS selector or component name, and the computed ratio against the target (e.g. “3.8:1 against required 4.5:1”). That gives the developer everything needed to fix it without a follow-up question.

Every practical item here maps back to a formal WCAG success criterion — non-text content, contrast (minimum), text resizing, and captions all have their own numbered criterion under the Perceivable principle, so cite the criterion number in your tracker for auditability.

Pro Tip: If a brand colour genuinely fails contrast, don’t fight the whole palette. Keep the brand colour for large decorative elements and swap it for a darker or lighter shade specifically on body text and small UI labels — most brand guidelines survive this compromise without looking off.

Operable: keyboard access, navigation, timing and input

If a sighted mouse user can do something a keyboard-only user can’t, that’s a hard fail, not a nice-to-have gap. Operable is about making every interaction reachable without a pointing device.

Test every interactive element with Tab, Shift+Tab, Enter and Space alone: can you reach it, can you see where you are, and can you actually trigger it? Dropdown menus, modal dialogs, and custom sliders are the usual culprits — they look fine to a mouse user and trap a keyboard user completely.

A visible focus indicator is mandatory, not optional styling. If your CSS resets have stripped the default focus outline (a common accident with outline: none; in a global stylesheet), you’ve broken keyboard navigation site-wide without anyone noticing in a visual review. Test by tabbing through a page and confirming you can always see, at a glance, which element is focused.

Tab order needs to follow the visual and logical reading order of the page — left to right, top to bottom, matching how the content is laid out on screen. Skip links (a hidden “skip to main content” link that appears on focus) save keyboard users from tabbing through an entire navigation menu on every single page. Consistent navigation placement across templates matters just as much: if the main menu moves position between the homepage and a product page, that’s an extra cognitive load every assistive tech user has to absorb.

Timing and input rules matter more than most teams realise. Avoid session timeouts under 20 minutes without a warning and an option to extend. Any interaction requiring a drag gesture (reordering a list, adjusting a slider) needs a keyboard or button-based alternative — dragging is one of the harder tasks for anyone with a motor impairment.

Pro Tip: Build a five-minute keyboard test script your QA team runs on every release: unplug the mouse, tab through the primary user journey (homepage to checkout, or homepage to contact form), and confirm every step is reachable and clearly focused. Running the same script every time makes regressions obvious fast.

Understandable: clear content, predictable behaviour and accessible forms

Understandable content doesn’t ask the reader to work harder than necessary. That means plain language over jargon, a declared page language (the lang attribute in your HTML), and headings that actually describe the section beneath them rather than a generic “More Info.”

Forms are where understandability gets tested hardest, because a confusing form doesn’t just frustrate users, it blocks transactions.

• Labels stay visible at all times — placeholder text that vanishes on focus is not a label.
• Instructions state format requirements upfront (“phone number, no spaces”) rather than only after a failed submission.
• Error messages identify the specific field and explain how to fix it (“email address is missing the @ symbol,” not “invalid input”).
• Errors appear inline, next to the field, not just in a summary banner at the top of the page.
• Required fields are marked with text, not colour alone.

Predictability also covers UI consistency: buttons that look the same should behave the same across every page, and a component that submits a form on one page shouldn’t silently do something different on another. Document any deliberately unusual behaviour so it can be tested against, rather than discovered by accident during a review.

Heading structure deserves its own scrutiny. Use one H1 per page, and let H2s and H3s nest logically underneath it, reflecting actual content hierarchy rather than font size preference. A common mistake: applying heading-sized styling to a paragraph purely for visual weight, without marking it up as an actual heading. That breaks screen reader navigation, since users often jump page sections by heading level alone. Our guide on designing accessible websites covers heading structure and content hierarchy in more depth.

Robust: semantic HTML, ARIA and assistive-technology compatibility

Robust means your code works reliably across browsers, devices and assistive technologies, today and as they update. The fastest way to get there is deceptively simple: use the native HTML element built for the job.

A <button> element comes with keyboard support, focus handling and screen reader announcements built in for free. A <div> styled to look like a button gives you none of that unless you rebuild it manually with JavaScript and ARIA attributes, and most rebuilds miss an edge case. MDN’s own accessibility guidance is blunt about this: using the correct HTML element for the correct purpose is one of the single biggest accessibility wins available, and CSS or JavaScript misuse can undo it just as easily.

ARIA has its place, but it’s a supplement, not a starting point. Use aria-label when a visible label isn’t practical (an icon-only close button), aria-hidden="true" to hide purely decorative elements from screen readers, and roles like role="alert" for dynamic messages. The most common pitfall is layering ARIA roles onto elements that already have the correct native semantics, which can create conflicting or duplicate announcements.

Automated tools flag missing ARIA attributes and invalid roles, but they cannot tell you whether the experience actually makes sense read aloud. A basic screen reader check (NVDA on Windows, VoiceOver on Mac) tabbing through your main journey will surface issues no scanner catches, like a heading that reads “Section 2” with no context.

Pro Tip: Before reaching for a custom ARIA widget pattern, ask whether a native element with some CSS could do the same job. Nine times out of ten it can, and it’ll behave correctly in every screen reader without extra code to maintain.

Making tables, charts and interactive widgets accessible

Complex components are where accessibility work usually gets skipped, because they’re harder to fix after the fact than a missing alt tag.

Data tables need proper <th> header cells with scope="col" or scope="row" attributes, so a screen reader can announce which header applies to which cell. Never use a table purely for visual layout — that confuses assistive tech users who expect a table to contain tabular data. For large or complex tables, offer a simplified or linearised view as an alternative.

Charts and visualisations need a text-based description of the trend or key data point, not just a colour-coded image. Where the underlying data matters, offer a downloadable CSV or an accompanying data table so the same information is available without relying on visual interpretation.

Interactive widgets (custom dropdowns, date pickers, tab panels) need the correct ARIA roles and states, and they need to announce changes as they happen (a tab panel should announce which tab is now selected). If a custom widget can’t be built accessibly within a sprint, a simpler native alternative is a better short-term fix than shipping a broken custom one.

• Confirm header cells and scope attributes on every data table before sign-off.
• Provide a CSV or data table alongside any chart carrying meaningful figures.
• Test every custom widget’s keyboard pattern against the WAI-ARIA Authoring Practices before handover.
• Document any known limitations when handing a component from design to development.

PDFs and downloadable documents: what needs tagging

A beautifully accessible website can still fail a user completely at the point they download a PDF. Documents need the same level of attention as the page linking to them.

• Confirm the PDF has a tagged structure with a logical reading order, not just visually arranged text boxes.
• Add real headings within the tag structure, matching the visual hierarchy of the document.
• Include alt text for any images or charts within the PDF.
• Confirm text is selectable and searchable, not a scanned image pretending to be text.

Where a PDF can’t be remediated quickly, publish an HTML version or a plain-text alternative alongside it rather than leaving a broken document as the only option. Test tagged PDFs using Adobe Acrobat’s built-in accessibility checker or a screen reader pass, and log any failure with the specific page number and issue (missing heading tag, unlabelled image, broken reading order) so it’s fixable without reopening the whole document.

Testing methodology: tools plus hands-on checks

Automated tools are the fast first pass, not the finish line. WAVE overlays visual flags directly on your page, which makes it useful for a quick eyeball scan during design review. axe (from Deque) integrates into browser DevTools and CI pipelines, catching programmatic issues like missing labels or invalid ARIA before code ships. Lighthouse, built into Chrome DevTools, gives a broader performance-plus-accessibility score useful for tracking trends over time.

None of them can tell you whether the experience actually makes sense. WebAIM is explicit that automated tools find programmatic errors but cannot replace manual keyboard and screen reader testing — a scanner can confirm a button has a label, but not whether tabbing to it in context feels logical to a real user.

Run this manual script on every major page template:

1. Unplug the mouse and tab through the entire primary user journey.
2. At each stop, confirm the focus indicator is visible and the tab order matches the visual layout.
3. Submit a form with intentional errors and confirm the messages are clear and appear inline.
4. Turn on a screen reader (NVDA on Windows, VoiceOver on Mac) and navigate the same journey by headings and landmarks.
5. Confirm any dynamic content (modals, alerts, live updates) is announced without needing a page refresh.

Record every result with the page URL, the exact element or component name, the tool or method used to find it, and a pass/fail status. That level of detail is what turns a vague “accessibility issues found” note into tickets a developer can actually close.

Pro Tip: Test on a staging environment with real assistive tech installed, not just a browser extension simulating one. Extensions occasionally throw false positives that waste a developer’s afternoon chasing a bug that isn’t real in production.

Prioritising fixes: what to tackle first

Not every issue deserves the same urgency. Sort fixes into three tiers: quick wins (contrast, alt text, form labels) fixable within a day or two; medium tasks (focus order, heading structure, error message rewrites) needing a sprint; and structural fixes (navigation redesign, custom widget rebuilds) that need proper design and development time across multiple sprints.

For a typical medium-sized marketing site, quick wins usually clear in under a week. Medium tasks run two to three sprints depending on team size. Structural fixes, especially anything touching navigation or a core component library, are best scheduled alongside a planned website redesign rather than bolted on separately, since retrofitting accessibility into an unchanged structure often costs more than building it in from the start.

• Fix contrast, alt text and form labels first — cheapest impact-to-effort ratio.
• Batch heading and focus-order fixes into a dedicated sprint.
• Schedule structural navigation or component work alongside your next redesign cycle.
• Re-run automated scans plus a manual pass after every remediation round to confirm the fix held.

Cost estimates vary enormously by site size and how much custom component work is involved, so treat any number outside your own project scope with caution. What’s consistent is the shape of the work: a handful of cheap quick wins, a middle tier of sprint-sized tasks, and a smaller number of expensive structural jobs that deserve dedicated budget rather than being squeezed into an unrelated sprint.

Handling error prevention and recovery beyond form errors

Error handling isn’t only about form validation messages. It covers every point where a user could take an irreversible or costly action by mistake, and how easily they can recover if they do.

For anything with real consequences, financial transactions, account deletions, submitting a legal document, build in a confirmation step before the action completes. A “review your order” screen before final submission gives every user, not just those with cognitive or motor impairments, a chance to catch a mistake.

Where an action can’t be reversed, make that explicit in plain language before the user commits (“this will permanently delete your account”) rather than after. Where it can be reversed, say so too — an “undo” option removes a huge amount of anxiety for users who take longer to complete a task or who second-guess themselves navigating with assistive tech.

Session-based errors deserve the same care. If a form submission fails because a session timed out, preserve the user’s entered data rather than clearing the form and forcing a re-entry from scratch. Losing twenty minutes of typed content because of a timeout is a usability failure for everyone, and a genuine barrier for someone relying on switch access or voice input, where re-entry is far slower.

Test this by deliberately trying to break your own flows: submit a form twice quickly, let a session expire mid-task, and try to undo an action after confirming it. If recovery feels awkward for you clicking a mouse, it will be considerably harder for someone using a keyboard or screen reader alone.

Guidance on handling dynamic content and updates

Single-page apps, live chat widgets, and auto-updating dashboards all create the same problem: content changes without a full page reload, and a screen reader has no way of knowing unless you tell it.

ARIA live regions solve this by marking a section of the page as one that should be announced when its content changes. A role="status" or aria-live="polite" region announces updates without interrupting whatever the screen reader is currently reading, appropriate for things like “3 items added to cart.” A more urgent aria-live="assertive" region interrupts immediately, reserved for genuinely time-sensitive alerts like a failed payment or a session about to expire.

Overusing live regions is its own problem. Marking too many sections as live creates a barrage of announcements that buries the important ones, so reserve them for updates a user genuinely needs to know about right away.

Loading states need the same attention. If content loads asynchronously (a search results panel, an infinite-scroll feed), announce when loading starts and finishes, so a screen reader user isn’t left wondering whether anything happened. Modal dialogs that open dynamically need focus moved into the modal automatically and returned to the triggering element when it closes, otherwise keyboard and screen reader users lose their place in the page entirely.

Test dynamic content changes the same way you test static content, tab and screen reader pass, but specifically trigger every dynamic state (loading, error, success, modal open/close) during that pass rather than only checking the page at rest.

Addressing colour blindness and vision beyond contrast

Contrast ratios solve one problem. Colour blindness, affecting roughly one in twelve men and a much smaller share of women, creates a different one entirely: information conveyed purely through colour distinction can be invisible even when the contrast ratio technically passes.

A red/green error and success pairing is the classic failure. To someone with red green colour blindness, the most common form, both can look like the same murky brown, so a form that only turns a field red on error has communicated nothing. Pair colour with a persistent icon, a text label, or a pattern, so the information survives regardless of how colour is perceived.

Low vision beyond colour blindness includes reduced acuity, tunnel vision and light sensitivity. Supporting text resize up to 200% without breaking layout or losing functionality, a specific WCAG requirement, covers a large share of these users. Avoid fixed pixel heights on text containers that clip content when a user increases their browser’s font size, and avoid relying on hover-only interactions that a magnified viewport makes difficult to trigger accurately.

Test colour independence quickly using a colour blindness simulator (built into most browser dev tools) on your key screens, particularly anywhere status or validation relies on colour. If the meaning survives with colour desaturated, you’ve covered the majority of this category.

Guidelines on accessible navigation and consistent structure

Navigation is the skeleton of the site. Get it wrong, and every other accessibility fix sits on shaky ground.

Keep primary navigation in the same location and order across every page template. A user who’s built a mental map of your site (or whose screen reader has learned the pattern of headings and landmarks) loses that map the moment navigation shifts unpredictably between page types.

Use proper landmark regions, <nav>, <main>, <header>, <footer>, so screen reader users can jump straight to the section they need instead of tabbing through the entire page linearly. Breadcrumbs should be marked up as an actual navigation list, not styled text, so their structure is announced correctly.

Dropdown and mega-menus need particular care. They’re one of the most common keyboard traps on the web: mouse users hover to reveal a submenu, but keyboard users need an equivalent way to expand it, usually Enter or Space on the parent item, with Escape closing it again. Test every navigation menu with a keyboard alone before considering it done, and confirm skip links let a keyboard user bypass the full menu structure to reach main content directly.

Considerations for mobile accessibility and responsive design

Mobile accessibility isn’t a separate checklist, it’s the same principles applied to smaller screens, touch input and no physical keyboard by default.

Touch targets need adequate size and spacing, generally at least 44 by 44 pixels, so a button doesn’t require pinpoint accuracy to tap correctly. This matters even more for users with motor impairments or anyone using a mobile device one-handed on the move.

Responsive layouts need to preserve reading order when content reflows for smaller screens. A layout that visually reorders content via CSS for mobile can leave a screen reader announcing content in the original, now-mismatched order, since screen readers typically follow document order rather than visual position. Check this specifically when your design uses CSS grid or flexbox reordering for responsive breakpoints.

Zoom and pinch gestures need to remain enabled. Disabling pinch-to-zoom (user-scalable=no in a viewport meta tag) blocks low vision users from magnifying content, and it’s a surprisingly common default left over from older mobile-first templates. Orientation matters too: content and functionality should work in both portrait and landscape, not force a single orientation unless there’s a genuine functional reason (like a game).

Our guide on responsive web design covers the broader technical patterns behind building layouts that hold up across breakpoints without breaking accessibility along the way.

What accessibility audits actually reveal

Across audit work, the same handful of failures show up again and again, and they’re rarely the flashy custom components teams worry about. It’s the boring stuff: a contact form missing labels, a hero image with no alt text, a mega-menu that traps keyboard focus.

One recurring pattern worth flagging: teams often fix the homepage thoroughly and stop there, leaving template pages (product listings, blog posts, checkout flows) with the same underlying issues untouched. A remediation pass that started as a homepage contrast fix and expanded to the shared header and footer components fixed the same issue across every page in one move, because those elements were shared, not duplicated per template.

The most useful thing a project manager can do when running an accessibility sprint isn’t chase every issue at once, it’s group fixes by shared component first.

Pro Tip: Before assigning individual page fixes, check whether the issue lives in a shared header, footer, or component. Fixing it once there often resolves the same fault across dozens of pages simultaneously.

How CantyDigital helps you get compliant, faster

Running this checklist yourself is entirely doable with the right time and testing discipline. Where CantyDigital fits in is for teams who need it done properly without pulling developers off other work: full accessibility audits mapped to WCAG A/AA, remediation sprints scoped by priority, and accessible design and development built in from the ground up rather than patched on afterwards.

Engagements run either as a fixed-scope project (a full audit plus a prioritised remediation plan) or as an ongoing retainer for sites that need regular re-testing after every content or feature update. Either way, deliverables are concrete: a written audit report mapped to specific success criteria, a prioritised ticket list your developers can action directly, and a follow-up verification pass once fixes ship. If your current site was never built with accessibility in mind, our guide on accessibility in web design is a good starting point, and it pairs naturally with a full rebuild if your structure needs more than patching. Get in touch through our website design FAQs page to talk through what a review of your site would involve and get a straight answer on scope and timeframe.

Sources

Start with the W3C WAI for the official standard, WebAIM for evaluation guidance, and MDN for implementation detail. Run WAVE, axe and Lighthouse for automated scans, then verify with NVDA or VoiceOver.

Pro Tip: Skip accessibility overlay widgets promising instant compliance. They routinely miss structural issues and can introduce new barriers for screen reader users, structural fixes are the only fixes that hold.

• WebAIM: Web Accessibility Evaluation Guide
• Ada

Recommended

• Accessibility in web design: a practical 2026 guide
• How to design accessible websites for all users
• Accessibility Compliance in Corporate Web Design | Canty Digital
• What is responsive web design: a developer’s guide