1. Low color contrast​

What it is. Text or interactive elements that do not stand out enough from their background. WCAG asks for a contrast ratio of at least 4.5:1 for normal text, and 3:1 for large text and for user interface components like icons and input borders.

Who it affects. Anyone with low vision or color vision differences, and honestly everyone on a dim laptop screen in a bright room.

How to fix it. Check your palette with a contrast checker and darken text or lighten backgrounds until it passes. The common trap is light gray "secondary" text and faint placeholder text, both of which fail constantly. Brand colors used for buttons and links are the next most frequent offender.

2. Missing or meaningless alt text​

What it is. Images that carry information but have no text alternative, so a screen reader announces nothing useful (or reads out a filename like IMG_2157.jpeg).

Who it affects. Screen reader users, and anyone on a slow connection where images fail to load.

How to fix it. Give every meaningful image alt text that describes its purpose, not its appearance. A logo's alt should be the company name, a chart's alt should state the takeaway. Decorative images that add nothing should have an empty alt (alt="") so assistive technology skips them rather than announcing clutter.

3. Form fields without labels​

What it is. Inputs where the only visible cue is a placeholder, or a label that is not programmatically connected to its field.

Who it affects. Screen reader users, who hear an unlabeled "edit text" with no idea what to type, and anyone relying on voice control to target fields by name.

How to fix it. Every input needs a real label associated with it (a <label for> tied to the input's id, or an aria-label). Placeholders are not labels: they vanish the moment someone starts typing, and their contrast is usually too low anyway.

4. No keyboard access​

What it is. Interfaces you can only use with a mouse: custom dropdowns that do not open on Enter, modals that trap focus, scrollable regions a keyboard cannot reach, or elements with no visible focus outline.

Who it affects. People who cannot use a mouse, including many motor-impaired users and most screen reader users, plus keyboard power users.

How to fix it. Tab through your whole app without touching the mouse. Every interactive element should be reachable, operable with Enter or Space, and should show a clear focus ring. Do not remove focus outlines in CSS without replacing them with something equally visible.

5. Broken heading order​

What it is. Headings that skip levels (an h1 followed by an h3) or are used for styling rather than structure.

Who it affects. Screen reader users navigate by heading the way sighted users skim by eye. A broken outline makes a page hard to navigate and hard to understand.

How to fix it. Use one h1 per page, then nest headings in order without skipping. If you want a smaller heading, style it with CSS. Do not reach for a lower heading level just to get smaller text.

6. Links you can only tell apart by color​

What it is. Inline links that look identical to the surrounding text except for their color. WCAG requires that links in a block of text be distinguishable by something other than color alone, unless the color contrast against the surrounding text is at least 3:1.

Who it affects. People with color vision differences, who may not see the color cue at all.

How to fix it. Underline inline links, or ensure the link color has enough contrast against the body text (not just the background). Underlines are the simplest, most universally understood signal.

Where to start​

If you do nothing else, run an automated scan first. These six categories are exactly what an automated pass detects reliably and quickly, which is why it is the right first step before any manual review: the machine handles the mechanical, high-volume failures, and you spend human attention on the judgment calls it cannot make.

VeriWasp's free accessibility scanner crawls your site, runs a real WCAG check on each page, and groups the results by rule so you see "12 images missing alt text across 3 pages" as one line item to work through, not a scattered list. Knowing which of these six is actually hurting you is most of the battle.

Why signup breaks so quietly​

Most flows fail loudly: a 500 page, a red error, a stack trace. Signup tends to fail in ways that still look fine on the surface.

• A silent JavaScript error. The form submits, the account is created, but a script that renders the welcome state throws, and the user lands on a blank or half-broken dashboard. The server thinks everything succeeded.
• A failed background request. The page loads, then a fetch to load the user's profile returns a 404 or malformed JSON, and the personalized part of the app never appears. Nothing on the server logs an error, because the request that failed was a client-side one.
• A broken redirect. After signup the app is supposed to send the user somewhere useful and sends them to a dead route, or back to the signup form, or into a loop.
• Email that never arrives. Magic links and confirmation emails depend on a third party, a verified sending domain, and a spam reputation you do not fully control. When they land in spam or hit a quota, the user simply cannot finish, and you never hear about it.

None of these show up in a unit test, because the unit test mocks away exactly the integration points that fail. They only appear when something drives the real flow in a real browser against your real deployment.

Manual testing is not enough​

The usual answer is "we test signup by hand before a release." That catches the obvious breaks, but it has three problems. It is slow, so it happens rarely. It is done by someone who already has an account and knows the happy path, so they skip the edge cases. And it is not repeatable, so a regression that sneaks in next week goes unnoticed until a customer hits it.

The flows that matter most are the ones worth testing automatically, on every deploy, the same way every time.

What good coverage looks like​

A useful signup test does what a new user does, in a real browser:

1. Load the page and confirm it renders without console errors.
2. Fill in the form with fresh data (a unique email each run, so the second run does not collide with the first).
3. Submit, and confirm the account is actually created.
4. Confirm the user lands where they should, with the personalized state rendered, not a blank shell.
5. Watch the network and the console the whole time, so a failed background request or a thrown script is caught even when the page looks fine.

That last point is the one manual testing almost always misses. The page can look completely normal while a request fails in the background, and only a tool watching the console and network traffic will notice.

How VeriWasp fits​

This is exactly what a VeriWasp playtest does. You describe the flow in plain English, and Claude drives a real browser through it: loads the page, fills the form, clicks the button, and checks that the welcome state appears. Throughout, it captures every console error and failed network request and ties each one to the step that caused it, so a signup that "looks fine" but silently fails its profile load comes back as a clear finding with the 404 and the console error attached, not a green check.

Wire it into your deploy pipeline and it runs on every ship, so the day something breaks your signup, you find out before your users do. You can try it against your own app with a few free runs, no card required.

The flow every customer must complete deserves better than a manual click-through you do twice a month. Test it like it matters, because it does.

Here is what it is, how it is structured, and why it is worth caring about even before anyone forces you to.

What WCAG actually is​

WCAG is published by the W3C, the same standards body behind HTML and CSS. It is not a law and not a piece of software. It is a set of testable success criteria: concrete statements like "text has a contrast ratio of at least 4.5:1 against its background" or "every form control has a label." Laws and contracts around the world then point at WCAG as the definition of "accessible," which is why it has become the de facto global standard.

The version you want to target today is WCAG 2.1 (or 2.2, which adds a handful of criteria). WCAG 3.0 is in draft and years away from being the reference anyone requires.

The four principles: POUR​

Every WCAG criterion rolls up into one of four principles, easy to remember as POUR:

• Perceivable. Users can perceive the content through some sense. Images need text alternatives, video needs captions, and color alone can never be the only way information is conveyed.
• Operable. Users can operate the interface. Everything works with a keyboard, not just a mouse, and nothing traps focus or flashes in a way that could trigger seizures.
• Understandable. Content and controls behave predictably. Form errors are explained in text, labels are clear, and the interface does not surprise the user.
• Robust. The markup is clean enough that assistive technology (screen readers, switch devices, voice control) can interpret it reliably.

If you internalize nothing else, POUR is a good filter: when you build a new feature, ask whether someone could perceive it, operate it, understand it, and whether a screen reader could make sense of it.

The three levels: A, AA, AAA​

WCAG sorts its criteria into three conformance levels:

• Level A is the floor. Failing these makes content genuinely unusable for some people (an image button with no label, a video with no captions at all).
• Level AA is the practical target. It covers the things that make a site usable rather than merely possible to use: color contrast, resizable text, consistent navigation, visible focus, and clear error handling.
• Level AAA is the gold standard, but it is not expected for a whole site. Some AAA criteria are impractical or even conflicting for certain content, so almost no one commits to full AAA.

When a law, a contract, or a customer says "must be accessible," they almost always mean WCAG 2.1 Level AA. That is the number to aim for.

Why it matters, beyond the checkbox​

Real people, more than you think​

Around one in five people has a disability of some kind, and that number understates the reach. Accessibility also covers temporary situations (a broken arm, bright sunlight on a phone screen) and permanent ones (low vision, color blindness, motor differences). Building for accessibility is building for a much larger slice of your users than the label suggests.

The legal reality​

In the United States, the Americans with Disabilities Act has been applied to websites, and WCAG 2.1 AA is the benchmark courts and settlements reference. Web accessibility demand letters and lawsuits number in the thousands each year, and they increasingly target small companies, not just household names. Public sector and enterprise buyers go further: Section 508 in the US and EN 301 549 in the EU both require WCAG conformance, so an accessibility gap can quietly disqualify you from a deal before anyone even tells you why.

It overlaps with things you already care about​

Most accessibility work is also good engineering. Semantic HTML, meaningful alt text, proper headings, and labeled controls are exactly what search engines parse to understand your page, so accessibility and SEO pull in the same direction. Clear focus states, readable contrast, and predictable forms reduce support tickets and lift conversion for everyone, not only users with disabilities. Accessibility is rarely a tax you pay for a minority; it is usually a quality bar that helps the whole product.

What AA conformance looks like in practice​

You do not need to memorize the spec to get most of the way there. A large share of real-world failures come down to a short list:

• Text and interactive elements meet contrast ratios (4.5:1 for normal text, 3:1 for large text and UI components).
• Every image that carries meaning has alt text, and decorative images are marked so screen readers skip them.
• Every form field has a programmatic label, not just a placeholder.
• The whole interface works with a keyboard, and the focused element is always visible.
• Headings describe the page structure in order, without skipping levels.
• Links are distinguishable from surrounding text by more than color alone.

Get those right and you have cleared the majority of what an audit will flag.

How to check your own site​

You cannot fix what you cannot see, and manual review misses a lot. Automated tools catch the mechanical failures (contrast, missing alt text, unlabeled controls, heading order) quickly and consistently, which is the right first pass before any human review.

VeriWasp runs a real WCAG scan on every page it tests, and the free accessibility scanner will crawl your site and group its findings by rule, so "color contrast too low on 72 elements across 5 pages" reads as one issue to fix, not seventy-two. It is a fast, honest way to see where you actually stand against AA before you decide what to do about it.

Accessibility is not a one-time project you finish. It is a quality bar you hold as you ship. Knowing where you stand today is the first step.