Accessibility Testing Checklist for Web Apps

Accessibility issues are easy to miss when a UI works well with a mouse and looks correct in a visual review. The problem is that many real users do not experience your web app that way. They navigate by keyboard, rely on screen readers, increase zoom, change contrast, or use assistive technologies that expose weak semantics and poor focus management very quickly.

A strong accessibility testing checklist helps QA teams and frontend teams catch those issues before release. It also turns accessibility from a vague quality goal into a set of concrete checks that can be repeated in feature branches, pull requests, and regression suites.

This checklist is written for teams that want something practical, not theoretical. It focuses on what to verify, why it matters, and where automated testing helps, or does not help. It is not a replacement for manual review or formal audits, but it is a reliable baseline for day-to-day web app testing.

What this checklist covers

This accessibility QA checklist is organized around the areas that usually create the most user-facing issues:

• Keyboard navigation and focus behavior
• Semantics and structure
• Forms and validation
• Color, contrast, and visual states
• Images, icons, and non-text content
• Dynamic components such as dialogs, menus, and toasts
• Tables, lists, and data-heavy interfaces
• Media, motion, and time-based content
• Page-level behavior, routing, and error states
• Automation strategy for CI and regression testing

A good accessibility testing checklist does not try to prove that a site is “fully accessible” in one pass. It helps you verify that the highest-risk failures are not shipping repeatedly.

Start with the standard you are testing against

Before checking anything else, define the accessibility target. For most web products this means WCAG 2.1 AA or WCAG 2.2 AA, depending on your product requirements, market, or legal constraints. If your organization has a formal compliance target, use that instead of a vague “best effort” approach.

Why this matters:

• It gives the team a shared baseline
• It prevents subjective debates about whether a fix is “accessible enough”
• It makes automated tool results easier to interpret

You do not need to memorize every success criterion to use this checklist well. What matters is mapping your testing tasks back to the WCAG principles:

• Perceivable
• Operable
• Understandable
• Robust

If a UI element is visually polished but not perceivable by assistive tech, it fails the product even if it passes screenshots and happy-path functional tests.

Accessibility testing checklist for web apps

1. Keyboard navigation works everywhere

Keyboard support is one of the fastest ways to expose real accessibility defects.

Check that:

• Every interactive control can be reached with Tab, Shift+Tab, Arrow keys, Enter, and Space where expected
• Focus order is logical and matches the visual order where appropriate
• No element traps focus unintentionally
• Keyboard users can open and close menus, dialogs, date pickers, comboboxes, and tooltips
• All hover-only functionality has a keyboard-accessible equivalent
• Custom components behave like native controls in terms of keyboard interaction

Practical checks:

• Can you complete the core user journey without touching the mouse?
• When a modal opens, does focus move into it?
• When the modal closes, does focus return to the trigger?
• Can you tab into and out of side panels, popovers, and floating menus?

Common failures:

• Using click handlers on divs without keyboard support
• Removing the default focus outline without a replacement
• Focus landing on hidden elements
• Tab order breaking after dynamic content loads

2. Focus is visible and predictable

If users cannot see where focus is, keyboard navigation becomes guesswork.

Check that:

• The focused element has a clear visual indicator
• The indicator is visible against the background and surrounding UI
• Focus does not jump unexpectedly after actions like submit, save, filtering, or navigation
• Skip links, if present, are visible on focus and actually skip to content

Tradeoff to consider, a custom focus style can look better than the browser default, but it must remain obvious in all themes and states. Test dark mode, high contrast, and disabled states separately.

3. Semantic HTML is used correctly

Screen readers and other assistive technologies depend heavily on native semantics. A clickable div is not the same thing as a button.

Check that:

• Buttons use <button> instead of clickable <div> or <span> elements
• Links navigate, buttons perform actions, and these roles are not mixed
• Headings are hierarchical and not used only for styling
• Lists are marked up as lists
• Landmarks like <main>, <nav>, <header>, and <footer> are used where useful
• Form inputs have associated labels

This is one of the best places to catch problems early in frontend code review. Often the simplest fix is to choose the correct element, not to add more JavaScript.

4. ARIA is used carefully, not as a shortcut

ARIA can help when native semantics are not enough, but it can also create new problems if used incorrectly.

Check that:

• ARIA roles match the actual widget behavior
• aria-label, aria-labelledby, and aria-describedby are meaningful and not redundant
• aria-expanded, aria-controls, aria-selected, and similar attributes update correctly
• No invalid or deprecated ARIA attributes are present
• Hidden content is truly hidden from accessibility APIs when intended

A useful rule of thumb, use native HTML first, then add ARIA only where the component genuinely needs it.

Overusing ARIA is a common failure mode in design systems. It is better to build a real button than to make a div pretend to be one.

5. Forms are understandable without visual guesswork

Forms are one of the highest-value areas for accessibility testing because they are where users enter data, encounter validation, and often abandon tasks.

Check that:

• Every input has an explicit label
• Required fields are communicated programmatically, not only visually
• Placeholder text is not the only label
• Error messages are connected to the right field
• Validation messages are specific enough to fix the issue
• Grouped controls such as radio buttons and checkboxes have proper fieldset and legend markup when appropriate
• Help text is available to assistive tech

Also verify the submission flow:

• Focus moves to the first invalid field or a meaningful error summary
• Errors are announced or visible in a way that keyboard and screen reader users can detect
• Inline validation does not interrupt typing with noisy or premature feedback

If you are testing forms in a web app, also check edge cases such as autofill, masked inputs, dynamic required fields, and multi-step forms.

6. Color contrast meets the target standard

Color contrast problems are common because design tokens, theme variants, and disabled states often introduce unreviewed combinations.

Check that:

• Body text meets contrast requirements against its background
• Text on buttons, chips, badges, and tags is readable
• Placeholder text is distinguishable from actual input text, but not so faint that it becomes unusable
• Links are recognizable without relying on color alone
• Interactive state changes, such as hover and focus, are visible in more than one way

For contrast testing, use both automated checks and spot checks. Automated tools are good at identifying obvious failures, but designers and developers still need to validate contextual cases such as gradients, overlays, transparent backgrounds, and text on images.

7. Non-text content has meaningful alternatives

Images, icons, and decorative assets often accumulate accessibility debt quietly.

Check that:

• Informative images have useful alt text
• Decorative images are ignored by assistive tech when appropriate
• Icons used alone as interactive controls have accessible names
• Charts and complex visualizations have a text alternative or data table equivalent where needed
• Avatars, status badges, and thumbnails do not expose meaningless filenames or generic labels

Do not write alt text that repeats surrounding text. The goal is to convey useful information, not restate the UI.

8. Dynamic components manage focus correctly

Dialogs, drawers, popovers, and menus are frequent sources of bugs because they change the page structure at runtime.

Check that:

• Opening a dialog moves focus into it
• Focus is trapped inside modal dialogs until they are dismissed
• Pressing Escape closes the component when appropriate
• Tabbing does not leak to the page behind an active modal
• Background content is inert or otherwise unavailable when a modal is open
• Closing the component restores focus to a sensible place

For accessible menus and comboboxes, verify the keyboard model carefully. The interaction pattern should match user expectations, not just the visual design.

9. Toasts, alerts, and live updates are announced appropriately

Async UIs can create accessibility issues when updates happen visually but not programmatically.

Check that:

• Important status messages are exposed to assistive technology
• Error alerts are distinguishable from neutral info messages
• Live regions are not overused, which can overwhelm screen reader users
• Repeated updates do not spam announcements
• Critical changes, such as “saved successfully” or “session expired,” are discoverable without needing to search the page

This is especially important for SPAs, background saves, autosuggest, and dashboards with polling updates.

10. Page titles, headings, and navigation are consistent

Page-level structure matters because many users navigate by landmarks and headings rather than reading every word.

Check that:

• Each page has a unique and descriptive title
• The main heading matches the page purpose
• Heading levels are not skipped for styling reasons
• Navigation items are consistent across pages where possible
• Breadcrumbs, if used, are meaningful and keyboard accessible

A strong headings structure also helps automated scanners and manual reviewers understand the intended content hierarchy.

11. Tables, grids, and data views are accessible

Data-heavy interfaces can become unusable if structure is not preserved.

Check that:

• Tables use actual table markup when the content is tabular
• Header cells are associated correctly with data cells
• Sorting state is exposed clearly
• Pagination and filtering controls are keyboard accessible
• Virtualized lists do not break screen reader access to off-screen content without fallback behavior
• Editable grids preserve focus and announce row and column context where needed

If you use custom data grids, validate interaction patterns thoroughly. These components often require more than static semantic markup to be usable.

12. Zoom and reflow do not break the interface

Accessibility is not only about screen readers. Users also zoom text or the entire page, and some browser settings force different layouts.

Check that:

• The page remains usable at 200 percent zoom, and ideally higher for key workflows
• Text does not overlap or disappear
• Horizontal scrolling is limited to genuinely necessary content, such as wide data tables
• Mobile layouts and zoomed desktop layouts do not hide controls behind sticky elements
• Fixed headers and footers do not block content or focus targets

This is particularly important for responsive designs that rely on viewport units, large overlays, or dense component layouts.

13. Motion, animation, and timing respect user needs

Animations can improve clarity, but they can also make interfaces hard to use or trigger motion sensitivity.

Check that:

• Animations are not essential for understanding content
• Motion can be reduced when the user has requested it
• Auto-advancing carousels are avoidable or controllable
• Time-limited interactions provide enough time to complete actions
• Session timeouts warn users before logging them out

A page that depends on transitions to reveal essential controls can fail both accessibility and usability.

14. Error states are descriptive and recoverable

Error handling is part of accessibility, not an afterthought.

Check that:

• Errors explain what happened and how to fix it
• Error summaries are visible and linked to fields
• Server errors are not reduced to vague messages like “Something went wrong” without context
• Authentication and authorization failures have accessible messaging
• Empty states explain the absence of data and suggest the next step

If an API failure occurs, test whether the fallback UI still has correct semantics and focus behavior. Many teams only test the happy path, then discover the error state is unreadable or unreachable.

15. Authentication and session flows are accessible

Login, signup, password reset, MFA, and account recovery often include the hardest flows for users.

Check that:

• Inputs are labeled clearly
• CAPTCHA alternatives exist when required
• One-time codes can be entered without broken auto-advance behavior
• Password strength messages are accessible
• Session expiration is announced and recoverable
• Redirects do not unexpectedly steal focus or lose state

If you support SSO, test the boundary between your app and the identity provider carefully, especially after returning from redirects.

Manual testing checklist for screen readers

Automated accessibility tools catch many structural issues, but they cannot fully replace manual screen reader testing. You do not need to test every page with every screen reader, but you should test the highest-risk journeys regularly.

A practical screen reader accessibility testing checklist includes:

• Can the user understand where they are on the page?
• Are headings announced in a useful order?
• Are labels read correctly on inputs and buttons?
• Do custom components expose the right role and state?
• Are error messages announced when they appear?
• Can the user complete the main workflow without a mouse?

Useful combinations for teams often include:

• NVDA with Firefox or Chrome on Windows
• VoiceOver with Safari on macOS and iOS
• TalkBack on Android for mobile web workflows

You do not need to simulate every assistive technology scenario manually in every sprint. Focus on the journeys that are most critical, such as sign-in, checkout, account settings, or form-heavy operations.

What automation should check in CI

An accessibility testing checklist becomes much more effective when parts of it run continuously. Automated tests are best at detecting repeated structural regressions, especially in shared components and high-traffic flows.

Good automation targets include:

• Missing labels
• Incorrect heading structure
• Invalid ARIA
• Missing button names
• Obvious color contrast failures
• Focusable elements hidden from view
• Landmark and role issues
• Basic keyboard reachability for custom components

Example Playwright check for a login form label and keyboard behavior:

import { test, expect } from '@playwright/test';

test('login form is keyboard accessible', async ({ page }) => {
  await page.goto('/login');

await page.keyboard.press(‘Tab’); await expect(page.locator(‘input[name=”email”]’)).toBeFocused();

await expect(page.getByLabel(‘Email’)).toBeVisible(); await expect(page.getByLabel(‘Password’)).toBeVisible(); });

This kind of test is not a full accessibility audit, but it is useful because it guards the workflow that users rely on most.

A simple CI workflow can run accessibility checks alongside unit and browser tests:

name: web-tests

on: pull_request: push: branches: [main]

jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm test - run: npx playwright test

For teams using broader browser automation, accessibility checks work well as part of regression coverage for the same pages that already have functional tests.

How to structure the checklist by risk

Not every page needs the same depth of coverage. A good accessibility QA checklist is risk-based.

Use deeper testing for:

• Authentication and account recovery
• Checkout and payment flows
• Forms with validation and conditional fields
• Complex widgets, such as editors, grids, and file uploads
• New design system components
• Pages that changed significantly in a release

Use lighter regression checks for:

• Static content pages
• Low-risk informational screens
• Small content updates that do not alter interaction patterns

A practical approach is to split your checklist into three layers:

1. Component-level checks for design system widgets
2. Page-level checks for critical routes
3. Release-level scans for broad regression detection

This gives you a way to move quickly without testing the entire app manually every time.

Common mistakes teams make

Even mature teams repeat a few accessibility mistakes:

• Assuming automated scanner results are enough
• Testing with a mouse only
• Treating focus styles as “optional visual polish”
• Using ARIA to patch poor component choices
• Ignoring error states because they are less visible in demos
• Testing only desktop browser flows
• Failing to include accessibility in definition of done

If accessibility is only reviewed after UI implementation is complete, fixes usually cost more and take longer. It is cheaper to catch semantic issues during component development than after the design system has spread them across the app.

A lightweight definition of done for accessibility

If your team wants a practical standard, this can be a reasonable baseline for release readiness:

• Core keyboard paths work without a mouse
• Forms have labels, errors, and focus handling
• Custom components expose correct semantics
• Color contrast passes the target standard
• Screen reader review covers critical flows
• Automated checks run in CI for the most important pages
• Known issues are documented with a plan to fix or mitigate them

This is not a final compliance guarantee, but it is a good operating standard for product teams that need repeatability.

Where Endtest, an agentic AI Test automation platform, can fit into this workflow

For teams already running web test automation, Endtest’s accessibility testing can be one way to add accessibility checks inside broader browser test coverage. Its workflow lets you scan a page, or a specific element, for WCAG-related issues as part of an existing web test, which is useful when you want accessibility regressions to fail where your other UI checks already run.

That matters because accessibility is usually easier to maintain when it is not a separate process. If a checkout flow, settings page, or modal already has automation, attaching accessibility checks to those same paths helps the team catch regressions in context instead of in a separate audit after the fact.

Final thoughts

A useful accessibility testing checklist is specific, repeatable, and tied to real user workflows. It should cover keyboard behavior, semantics, forms, focus, contrast, dynamic UI, and regression automation, but it should also acknowledge what automation cannot do alone.

The most reliable pattern is simple: test critical journeys manually, automate the structural checks that commonly regress, and make accessibility part of normal frontend and QA ownership. When teams do that consistently, accessibility stops being a last-minute review item and becomes a standard part of building web apps that more people can actually use.