How to Run a One-Day Accessibility Pass Before Launch

A practical one-day accessibility pass for makers: scan, keyboard and screen reader tests, contrast and forms, an honest statement and a 14-day fix plan.

A one-day accessibility pass won't make your product perfect, but it will catch the problems that stop real people from signing up, finishing setup or paying you. You pick the few flows that matter, run an automated scan, then spend most of the day on what scanners can't do: using your product with only a keyboard, listening to it with a screen reader, zooming it, and reading your forms the way a stressed new user would.

This guide is for solo makers with a web app or SaaS and no accessibility background, and it ends with a 14-day plan, traps and a FAQ. It's a practical first pass, not an audit: it finds the loud problems, it won't prove you meet any standard, and nothing here is legal advice.

Why should a small product care about accessibility before launch?

Because some of your future users navigate with a keyboard, a screen reader or heavy zoom, and if your signup doesn't work for them, they leave without telling you. These failures don't show up in your analytics.

The wider web sets a low bar. WebAIM's 2026 WebAIM Million report, which scanned the home pages of the top million sites in February 2026, found detectable WCAG failures on 95.9% of them. The most common were low contrast text (83.9% of home pages), missing image alt text (53.1%) and missing form labels (51%). All three are cheap to fix.

Clear headings, real link text and alt text also make pages easier for search engines to read. Treat that as a bonus, not the reason.

Which laws might apply to a small product?

It depends on where your customers are, who they are and your size, so treat this as orientation and check your case with someone qualified.

European Union. The European Accessibility Act covers certain products and certain services provided to consumers, including e-commerce, consumer banking, e-books and electronic communications. Its rules apply from 28 June 2025 through each country's national law. Microenterprises providing services, meaning fewer than 10 people and annual turnover or balance sheet total of no more than 2 million euros, are exempt from the service requirements, as Ireland's regulator explains in its EAA guidelines for microenterprises. A purely business-to-business tool may fall outside that list, but don't assume.
United States. The Justice Department's guidance on web accessibility and the ADA says businesses open to the public must make the goods and services they offer online accessible. It says the department has no regulation setting detailed technical standards for businesses and points to WCAG and the Section 508 Standards as helpful guidance.

What standard should you test against?

Aim for WCAG 2.2 at level AA. It's the current version of the Web Content Accessibility Guidelines, published by W3C on 5 October 2023, and W3C's page on what's new in WCAG 2.2 lists the nine success criteria added since 2.1.

Each criterion has a plain-language W3C "Understanding" page, and this guide links the ones you'll hit most. W3C's Easy Checks make a good warm-up, though W3C says they're quick rather than definitive and a page can pass them and still have serious barriers. The same goes for this pass.

Which flows should you test in one day?

Test the three to five flows a new user must get through to reach their first result and pay you, end to end, and ignore everything else today.

Landing page to signup.
Login and password reset, including the email.
First run: setup steps, empty screens, onboarding dialogs.
The main task people come back for.
Upgrade to checkout.

Flows three and four are the path to your activation event. If you haven't named one yet, this guide to tracking the product metrics that matter before your first 100 users helps, and it tells you exactly which screens to test.

A realistic day: an hour of scans, two of keyboard testing, two with a screen reader, an hour on contrast and zoom, an hour on forms and structure, and an hour sorting. Log each problem the moment you see it, with the flow and the step.

What does an automated scan catch, and what does it miss?

A scan catches mechanical problems like missing alt attributes, unlabeled fields and low contrast, but it can't tell you whether a person can finish your flow. Run it first so the rest of the day goes to the hard parts.

Lighthouse in Chrome DevTools. Its accessibility score is a weighted average of pass or fail audits, and manual audits don't affect it. A 100 means the automated audits passed, not that the page is accessible.
axe DevTools, the browser extension built on Deque's open source axe-core engine. Deque says axe-core finds on average 57% of WCAG issues automatically and marks others for manual review. That's the vendor's own figure, and it still leaves a big share for you.
WAVE from WebAIM, which draws icons over the page so heading order and missing labels are easy to see.

Scan every screen while logged in, including dialogs and error states. As the ADA guidance puts it, a clean report doesn't necessarily mean everything is accessible.

How do you test your product with only a keyboard?

Put your mouse out of reach and complete each flow using Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. Wherever you get stuck, so will everyone who can't use a pointer.

On every screen, check that:

Everything works. Every control can be reached and used, per 2.1.1 Keyboard. Components built from plain divs are the usual failures.
You can see where you are. 2.4.7 Focus Visible asks for a visible focus indicator. Search your CSS for outline: none with nothing replacing it.
Focus isn't hidden. Sticky headers, chat bubbles and cookie banners often cover the focused element. 2.4.11 Focus Not Obscured (Minimum), new in 2.2, says it must never be entirely hidden by content you added.
The order makes sense and matches the page, per 2.4.3 Focus Order.
Nothing traps you. You can always tab away from a component, per 2.1.2 No Keyboard Trap.
Dialogs behave. Focus moves into the dialog and stays there while it's open, Escape closes it, and focus returns to the button that opened it.
There's a skip link or another way to bypass repeated navigation.

Two pointer checks fit here too. Dragging needs a single-pointer alternative, per 2.5.7 Dragging Movements, and 2.5.8 Target Size (Minimum) asks for targets of at least 24 by 24 CSS pixels, or enough space around smaller ones.

Turn on the screen reader your computer already has, or a free one, and go through signup and your main task listening instead of looking. You're listening for buttons with no name, fields with no label and errors nobody hears.

On a Mac, use VoiceOver. Apple's guide to turning VoiceOver on or off gives the shortcut, Command-F5, and explains that the VoiceOver modifier is Control and Option together, or Caps Lock. The VoiceOver rotor, opened with VO-U, lists a page's headings, links and form controls.

On Windows, NVDA is free. The NVDA key is Insert by default, and on web pages single keys jump around: H for the next heading, D for landmarks, F for form fields, K for links. NVDA+F7 lists the page's links and headings.

Listen for these:

Every button says what it does. An icon button announced only as "button" is a blocker.
Every field announces its label, and required fields say so.
Submitting a form with a mistake tells you something went wrong, and where.
Dialogs announce themselves, and the page title changes between screens.

How do you check contrast, zoom and motion?

Check that text and controls stand out, that the product works when enlarged, and that nothing moves on its own without a way to stop it. These hit people with low vision, older users and anyone on a phone in bright light.

Work through these on every screen in your flows:

Text contrast. 1.4.3 Contrast (Minimum) asks for at least 4.5:1 for normal text and 3:1 for large text, which W3C treats as 18 point, or 14 point bold. Grey helper text, placeholders and text over images fail most. WebAIM's contrast checker gives the ratio for any two colors.
Controls and focus rings. 1.4.11 Non-text Contrast asks for 3:1 against neighbouring colors for the parts that identify controls and their states, like input borders and focus indicators.
Color alone. The ADA guidance gives the example of using only red text to show required fields. Add a word or an icon.
Zoom. Text should resize to 200 percent without losing content or function, per 1.4.4 Resize Text. Then set your window to 1280 pixels wide and zoom to 400%: 1.4.10 Reflow asks that content works at that size, equal to 320 CSS pixels, without scrolling in two directions.
Motion. Anything that moves or scrolls automatically for more than five seconds alongside other content needs a way to pause, stop or hide it, per 2.2.2 Pause, Stop, Hide. Also respect the prefers-reduced-motion setting for people who've asked their device for less motion.

What should you check on forms, images and page structure?

Every field needs a visible label, every error needs words, every meaningful image needs a text alternative, and every page needs a clear title and headings.

Visible labels for every input, per 3.3.2 Labels or Instructions. Placeholder text that vanishes when you type isn't a label.
Errors in words. Name the field and describe the problem in text, per 3.3.1 Error Identification. "Password must be at least 12 characters" beats a red border.
Login without puzzles. 3.3.8 Accessible Authentication (Minimum), new in 2.2, says no login step should require a cognitive test, like remembering a password or solving a puzzle, without an alternative or help. Supporting password managers and copy and paste counts as help, so never block paste on password or code fields.
The full reset path. If the email never arrives nothing else matters, so read why your password reset email might be sitting in spam.

Images, icons and video

Alt text that does a job. Under 1.1.1 Non-text Content, meaningful images need a text alternative that serves the same purpose, and controls need a name that says what they do. Decorative images get an empty alt="".
Icon buttons need an accessible name like "Delete project", through visible text or aria-label.
Captions on your demo. Prerecorded video with speech needs captions. If you followed a guide to filming a 90-second product demo that converts cold visitors, you already have a script, which makes accurate captions quick.

Structure

Each screen has a unique page title, and headings follow the content in order without skipped levels.
Landmarks like nav and main exist, and the html element has a lang attribute.
Links say where they go: "Read the setup guide", not "click here".

How do you decide what to fix first?

Sort every finding by whether someone can still finish the flow. Fix all blockers before launch, schedule the annoying ones, and fold polish into normal work.

Blocker: someone can't complete a core flow. A keyboard trap, an unlabeled signup field, an icon-only submit button with no name, a dialog you can't close, a CAPTCHA with no alternative, a step that only works by dragging.
Annoying: they can finish, but it hurts. Low contrast helper text, missing focus styles, errors shown only in red.
Polish: real but minor. Skipped heading levels, vague footer links.

A spreadsheet works: flow, step, what happened, who it affects, criterion, severity, effort, status. The "who it affects" column keeps you honest.

How do you write an honest accessibility statement?

Say what standard you're working toward, what you tested, what you know doesn't work yet and how people can reach you, in plain language. Never claim full compliance unless a proper audit backs it up.

W3C's guide to developing an accessibility statement sets the minimum as a commitment, the standard you apply, such as WCAG 2.2, and contact details. It also recommends listing known limitations in plain words, like "videos do not have captions" rather than a criterion number.

A small product's version might read: "We're working toward WCAG 2.2 level AA. In October 2026 we tested signup, login, setup and the dashboard with a keyboard, VoiceOver and NVDA, and fixed what we found. Known issue: the map view doesn't work with screen readers yet, so every item can also be chosen from a list. If something doesn't work for you, email accessibility@yourproduct.com." Link it from your footer.

And skip the overlay widget, the script that adds an accessibility toolbar and promises automatic compliance. In 2025 the US Federal Trade Commission finalized an order requiring overlay vendor accessiBe to pay $1 million, after alleging its claims that the tool could make any website WCAG compliant were false, misleading or unsubstantiated. The Overlay Fact Sheet, signed by many accessibility practitioners, argues full compliance can't be achieved with an overlay and calls for fixing issues at the source. Your one-day pass is that source fix.

How do you stop accessibility from breaking again?

Add a cheap automated check to your code workflow and a short manual check to your release habit, because most regressions arrive with new components.

Lint while you write. For React, eslint-plugin-jsx-a11y flags issues like images without alt text. Its docs note it only catches errors in static code, so pair it with a check of the rendered page.
Scan core flows in CI. Playwright's guide to accessibility testing shows how to run axe in your end-to-end tests with @axe-core/playwright. Cover your three to five flows and fail the build on new violations. The same page warns that many problems only show up in manual testing.
A five-line PR checklist. Works by keyboard? Focus visible and not hidden? Inputs labelled? Icon buttons named? Errors in text?
A ten minute keyboard walk before any release that touches a core flow, and fast replies to accessibility emails.

What does this look like for a tiny product? (invented example)

Everything in this example, including the product, the people and the numbers, is invented to show the steps.

Plotwren is a small web app that community garden coordinators use to run plot waitlists and a shared watering rota. Its maker, Jonas, built it alone. Many gardeners are retired, and one coordinator emailed that she couldn't read the rota on her tablet, even zoomed in.

Jonas tested four flows: signup, joining a waitlist, the rota and upgrading. axe and WAVE flagged 14 issues, mostly grey helper text below 4.5:1, two unnamed icon buttons and a missing lang attribute. The manual hours found worse. The "Join waitlist" dialog ignored Escape and focus stayed behind it. A sticky cookie banner hid the "Next" button on signup when tabbing. The plot map only worked by dragging. VoiceOver read the password visibility toggle as just "button", form errors showed in red with no text, and at 400% zoom the rota scrolled sideways.

His sheet ended with 5 blockers, 9 annoying issues and 6 polish items. He fixed the blockers over two evenings, added a "Choose from list" option beside the map, put axe checks in CI and published a statement naming the map as a known limitation. Then he emailed the coordinator. She wrote back that she'd set up the autumn rota herself, on the tablet.

What does a 14-day accessibility plan look like?

Day one finds the problems. The next two weeks fix them and keep them fixed.

Day 1: the pass

Pick your flows, scan them, test by keyboard and screen reader, check contrast, zoom and forms, and sort the findings.

Days 2 to 5: blockers

Fix every blocker, signup and login first, and re-test each fix by hand, not just with the scanner.

Days 6 to 9: the annoying list

Fix contrast in your color variables, add one global focus style that meets 3:1, and rewrite error messages to name the field and the fix.

Days 10 to 12: guardrails

Add the linter, the CI scans and the PR checklist.

Days 13 to 14: say it honestly

Publish your statement with known limitations and a contact address, linked from the footer.
Schedule the polish items and book a repeat pass three months out.

What traps waste the most time?

Chasing a Lighthouse 100. It only covers automated audits. Spend that hour on the keyboard.
Testing only the landing page. Most blockers live behind login, in dialogs, setup steps and error states.
ARIA everywhere. A native button or label usually beats a div with roles bolted on. WebAIM's 2026 report found pages using ARIA averaged more detected errors than pages without it, while noting those pages were also more complex.
Claiming "fully compliant". Say what you tested and what's still open.

Frequently asked questions

Is an automated scan enough on its own?

No. Scanners catch mechanical problems, but whether a flow works by keyboard and whether errors make sense need a person.

Do I need a professional audit before launch?

For most small products, a careful self-test is a sensible start. If you sell to large companies or the public sector, or think a law applies to you, a professional audit and testing with disabled users are worth paying for.

Does the European Accessibility Act apply to my SaaS?

Maybe. It covers specific consumer services, such as e-commerce, and exempts microenterprises providing services. Scope depends on what you sell, to whom and your size, so get advice for your case.

If you've just made your product easier for more people to use and want feedback from builders who'll actually click through it, you can share it on MakerHunt, where makers launch, swap honest notes and find their first users.