Accessibility Isn't Optional: Test Your App Before Launch

You can ship a working app in a weekend now. You can also ship one that some of your visitors can't use and never hear about it, because people who hit an accessibility wall rarely file a bug report. They just leave.

The good news: the most common problems are easy to find yourself. This is the test we'd want every founder to run before launch. It takes an afternoon, needs no special software, and works to WCAG 2.2 Level AA, the current Web Content Accessibility Guidelines. The W3C encourages using the latest version, and content that meets 2.2 also meets 2.1 and 2.0.

What does "Level AA" mean?

WCAG sorts its success criteria into three levels: A, AA and AAA. A page meets Level AA when it satisfies every Level A and Level AA criterion.

Why bother? Because almost everyone has work to do. WebAIM's 2026 scan of the top million home pages found detectable WCAG failures on 95.9% of them, and low-contrast text alone on 83.9%.

1. Put the mouse away

Click into your browser's address bar, then use only the keyboard. WebAIM's keyboard guide lists the standard keys: Tab moves forward, Shift+Tab moves back, Enter follows links and presses buttons, Space ticks checkboxes, the arrow keys move between options, and Esc closes dialogs.

Now do the things that make you money: sign up, log in, pay, contact support. WCAG requires that everything works from a keyboard and that focus can always move away from any component. Common culprits: a "button" that's really a styled <div>, a menu that only opens on hover, a date picker you can get into but not out of.

2. Watch the focus ring

As you tab, you should always see which element has focus. That's Focus Visible, and it usually breaks because of one line of CSS: outline: none with nothing to replace it, which WebAIM's guide warns against. Bring back a strong ring with :focus-visible.

WCAG 2.2 adds Focus Not Obscured (Minimum): a focused element can't be completely hidden behind content you put on the page. W3C names the usual suspects: sticky headers and footers, cookie banners and chat widgets. Tab down a long page with your cookie banner open and watch whether focus slips underneath it. One fix W3C documents is CSS scroll-padding, which scrolls focused items clear of sticky bars.

3. Open every modal

The W3C's modal dialog pattern spells out what should happen: focus moves into the dialog when it opens, Tab cycles through its controls without wandering off, Esc closes it, and focus normally returns to the element that opened it.

So keeping focus inside an open modal is correct. The failures are the two extremes: focus stays on the page behind, so a keyboard user tabs through links they can't see, or the dialog ignores Esc and has no reachable close button, so the only way out is a mouse. The native <dialog> element helps: MDN notes that opening it with showModal() makes the rest of the page inert and lets Esc close it.

4. Check form labels and errors

Every field needs a real, visible label. The W3C forms tutorial is blunt: placeholder text is not a replacement for labels, and it disappears once someone starts typing. Quick test: click the label text. If the cursor jumps into the field, it's wired up.

Then submit each form with mistakes in it. Error Identification requires errors to be described in text; a red border alone isn't enough. Good errors name the field, say how to fix it ("Enter an email address like name@example.com"), and are tied to the field with aria-describedby so screen readers read them out.

5. Check contrast and zoom

Normal text needs a contrast ratio of at least 4.5:1; large text (18 point, or 14 point bold) needs 3:1. Control edges, icons and focus rings need 3:1 under Non-text Contrast. Run your colours, including muted text and placeholders, through a tool like WebAIM's contrast checker.

Then zoom. At 200%, text should resize without losing content or features. At 400%, check Reflow: content should fit a width of 320 CSS pixels without sideways scrolling, which W3C says matches a 1,280-pixel window at 400% zoom. Data tables, maps and diagrams are exempt. Watch for fixed-width layouts and sticky headers that eat half the screen.

6. Describe your images

Every meaningful image needs a text alternative that does the same job: "Blue canvas backpack, front view" beats "IMG_4032.jpg". Icon-only buttons need a name too, such as aria-label="Close". Decorative images get an empty alt="" so screen readers skip them. Don't leave alt off entirely: some screen readers will announce the file name instead.

The new WCAG 2.2 rules to check

WCAG 2.2 became a W3C Recommendation on 5 October 2023 and added nine success criteria. Three Level AA ones are easy to miss when you're moving fast:

• Focus Not Obscured (Minimum). Covered in step 2: sticky bars and banners mustn't completely hide the focused element.
• Target Size (Minimum). Click and tap targets should be at least 24 by 24 CSS pixels, or spaced so a 24-pixel circle centred on each doesn't touch another target. Links inside a sentence are exempt. Check tiny close buttons and rows of icon buttons first.
• Accessible Authentication (Minimum). Don't make people solve, recall or transcribe something to log in unless there's an alternative or a helper. W3C's guidance says blocking paste or password managers fails unless an alternative is provided, and so does a one-time code that can only be typed by hand.

Why an overlay won't fix it

It's tempting to paste in a widget that promises accessibility in one line of code. In January 2025 the FTC announced an order requiring accessiBe to pay $1 million over claims that its AI-powered accessWidget could make any website meet WCAG; the FTC alleged it didn't do that for all users' sites. The final order, approved in April 2025, bars such claims about its automated products without evidence.

There's a simpler reason too. An overlay runs on top of your code; it doesn't change your source, and the fixes in this guide live in your source. And no tool can judge everything: W3C says tools cannot check all accessibility aspects automatically and human judgement is required.

The legal side, briefly

This isn't legal advice; whether a law applies to you is a question for an attorney. Here's the landscape in short.

Businesses open to the public. The Department of Justice's guidance on web accessibility and the ADA says the ADA covers goods and services businesses offer on the web, and its list of barriers reads like this guide: poor colour contrast, missing alt text, inaccessible forms, mouse-only navigation. DOJ says it has no regulation setting detailed standards for businesses, which have flexibility in how they comply, and points to WCAG as helpful guidance.

State and local governments. DOJ's 2024 Title II rule adopted WCAG 2.1 Level AA for their websites and mobile apps. An interim final rule published April 20, 2026 pushed the compliance dates back a year: April 26, 2027 for governments serving 50,000 people or more, and April 26, 2028 for smaller ones and special district governments. DOJ's fact sheet lists public schools, community colleges and public universities among those covered, and says governments must make sure their contractors follow Title II. If you sell to them, ask your attorney what that means for you.

Lawsuits. Seyfarth Shaw counted 3,117 website accessibility lawsuits in federal court in 2025, up 27% on 2024, not counting state courts. We cover the bigger picture in Your Cookie Banner Won't Save You.

Where a pre-launch audit helps

You can do all of this yourself, and you should. The hard part is repeating it on every flow, screen size and deploy. With your written permission, a LaunchGate audit walks your critical flows (sign-up, log-in, checkout and key forms) with a keyboard and checks focus, labels, error messages, contrast, target size and zoom against WCAG 2.2 AA, alongside automated checks. You get a report of what we found, with evidence and a recommended fix for each issue.

The limits, plainly: LaunchGate identifies issues based on the checks performed, and we don't certify a site as accessible. A full WCAG 2.2 AA review with assistive technology is work for an accessibility specialist, and legal questions go to an attorney. LaunchGate is not a law firm and does not provide legal advice.

Want a first look? The Free Launch Check is a preliminary public-surface review — not a full audit. It only sees your public pages, so for logged-in flows compare the audit packages or read our methodology.