Accessibility Testing: A Startup Checklist

Accessibility testing tends to get treated as a launch-day nice-to-have, something to circle back to once the roadmap has room for it. That works fine until a demand letter or an actual user who cannot complete a checkout flow makes it urgent overnight. Neither outcome is necessary. A startup with no dedicated accessibility budget can still cover the highest-risk gaps with a realistic, phased plan instead of an all-or-nothing rewrite.

What does accessibility testing actually check?

Accessibility testing checks whether a product can actually be used by people relying on assistive technology or working around a visual, motor, or cognitive difference, measured against the WCAG standard's four principles: content must be perceivable, the interface must be operable, information must be understandable, and the implementation must be robust enough for assistive technology to interpret correctly.

What automated scanning catches, and what it misses

Automated accessibility scanners are genuinely useful and genuinely limited. Industry estimates put automated tools at catching roughly 30 to 40% of real WCAG issues, the mechanically detectable ones: missing alt text, insufficient color contrast, missing form labels, and malformed heading structure. That is a real and cheap win worth taking immediately.

What a scanner cannot judge is anything that requires understanding intent: whether a keyboard user can actually reach and operate every interactive element in a sensible order, whether a screen reader announces a dynamic update in a way that makes sense, or whether an ARIA label describes what a component actually does rather than technically satisfying a rule. Treating a clean automated scan as proof of accessibility is where most well-intentioned teams get the risk picture wrong, and it is also where real legal exposure tends to live, since a scanner passing does not mean a real assistive-technology user can complete a real task.

This gap shows up in a specific, recurring pattern: a component that scores perfectly clean on an automated audit while being genuinely unusable with a keyboard alone. A custom dropdown built from styled divs instead of a native select element can carry correct-looking ARIA attributes and still trap keyboard focus, announce nothing meaningful to a screen reader when an option is selected, or skip past entirely on a tab sequence. None of that fails an automated scan, since the scanner is checking that the right attributes exist, not that the component behaves correctly for the person actually relying on them. That distinction, attributes present versus behavior correct, is the single most common reason a team believes it has covered accessibility and has not.

The startup accessibility checklist

What to automate first

Start with the cheap, high-coverage wins a scanner catches reliably:

• Alt text on every meaningful image, and empty alt attributes on purely decorative ones
• Color contrast ratios meeting WCAG AA on all text against its background
• Form inputs with an associated, visible label, not just a placeholder
• A logical, non-skipping heading structure on every page
• Interactive elements with a visible focus indicator

Wiring an automated scan into an existing CI/CD quality gate catches regressions on these five items automatically going forward, the same way a regression testing checklist catches functional regressions, for close to zero ongoing cost once it is set up.

What still needs manual and screen-reader review

Everything a scanner cannot judge needs a human, and it belongs in the same manual and exploratory testing pass a team already runs, not a separate accessibility-only initiative:

• Full keyboard navigation through every core flow, with no mouse, checking that focus order matches visual order
• Screen reader testing on the flows that matter most, checkout, sign-up, and any core workflow, using a real screen reader rather than assuming ARIA attributes are sufficient
• Dynamic content and modal behavior, confirming focus moves correctly and screen readers announce state changes
• Custom components, sliders, date pickers, dropdowns built from scratch rather than a native element, checked individually since these are where ARIA misuse is most common

Which tools actually do this well

For automated scanning, axe DevTools and WAVE both cover the same core rule set and are free to run against any page. For manual review, VoiceOver, built into macOS and iOS, and NVDA, free on Windows, cover the two platforms most users are actually on, and testing with a real screen reader beats guessing at ARIA correctness from the code alone every time. Neither tool requires a purchase or a specialist to operate, which is the point: the manual half of this checklist is a time cost, not a budget line.

A phased rollout for a team with no dedicated budget

Trying to fix everything at once is how accessibility work stalls indefinitely. A phased plan gets real coverage moving without a dedicated hire or a roadmap-clearing rewrite.

Days 1 to 30: automate the cheap wins

Wire an automated scanner into CI, fix what it flags on the highest-traffic pages first, and set a baseline score to track against going forward. This phase is mostly engineering time, not new process, and it closes the 30 to 40% gap fastest.

Days 31 to 60: manual review of the highest-risk flows

Run keyboard and screen reader testing on the flows that carry the most legal and usability risk, typically checkout, account creation, and any flow a user cannot complete any other way. This is the same risk-weighting already applied to functional testing, just scoped to accessibility specifically.

Days 61 to 90: build it into the standing process

Add an accessibility check to the same definition of done a new feature already has to meet, and add a lighter manual pass to release sign-off for anything touching a high-risk flow. By day 90, accessibility should be a checklist item inside existing process, not a separate initiative someone has to remember to run.

Where accessibility fits into an existing QA process

Accessibility testing is not a parallel discipline requiring its own team, it is one more dimension of the same regression testing and manual review process a mature QA function already runs. Folding it into an existing QA audit rather than treating it as a bolt-on project is what keeps it maintained past the initial push, since a checklist embedded in an existing process survives; a standalone initiative usually does not outlive the person who started it.