Web accessibility means building your app so that people with disabilities can use it: people who navigate with a keyboard instead of a mouse, who listen to the page through a screen reader, who zoom text to twice its size, or who cannot tell two similar colours apart. For a small web app, most of the work is not exotic. It comes down to using the right HTML elements, labelling things properly and testing with a keyboard. This guide explains what WCAG asks for and which parts matter most for a first product.
Who web accessibility is for
The W3C's introduction says accessibility "encompasses all disabilities that affect access to the Web", and lists auditory, cognitive, neurological, physical, speech and visual disabilities.
The same page makes a point that is easy to forget: accessible design also helps people without a disability. It lists people using phones and other small-screen devices, older people whose abilities change with age, people with temporary disabilities such as a broken arm or lost glasses, people with situational limitations such as using a screen in bright sunlight, and people on a slow or expensive internet connection.
What WCAG is
WCAG stands for Web Content Accessibility Guidelines. The W3C describes the documents as explaining "how to make web content more accessible to people with disabilities."
There have been three versions of WCAG 2:
| Version | First published |
|---|---|
| WCAG 2.0 | 11 December 2008 |
| WCAG 2.1 | 5 June 2018 |
| WCAG 2.2 | 5 October 2023 |
The versions are designed to be backwards compatible. The W3C says "content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0", and that it encourages you to use the latest version. So if you aim for WCAG 2.2, you are covered for the older versions too. The one exception to "nothing changes" is the old criterion 4.1.1 Parsing, which is obsolete in 2.2.
The four principles
The guidelines are organised under four principles: perceivable, operable, understandable and robust. In practice:
- Perceivable: people can get at the content, whatever senses they use. Images have text alternatives, text has enough contrast.
- Operable: people can use every control, whatever input they use. Everything works with a keyboard.
- Understandable: the interface behaves predictably and explains itself. Forms say what they need and what went wrong.
- Robust: the code is built so assistive technology can read it. Controls expose their name and role.
Levels A, AA and AAA
Each success criterion is assigned a level: A, AA or AAA. The conformance section of WCAG 2.2 says: "For Level AA conformance, the web page satisfies all the Level A and Level AA success criteria". For a small app, Level AA is a sensible target: it covers the barriers people hit most often without asking for the stricter AAA extras.
The success criteria a small app hits most
A typical first app (a landing page, a sign-up form, a dashboard, a few settings screens) runs into the same criteria again and again. Here they are, grouped by what you are building.
Images and text
- 1.1.1 Non-text Content (A). "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose." In practice: every meaningful image has alt text that says what it conveys. MDN advises that alt text be kept "short, precise, and useful." Decorative images get an empty alt attribute, so screen readers skip them; without any alt, MDN notes, many screen readers announce the whole image URL instead.
- 1.4.3 Contrast (Minimum) (AA). Text needs "a contrast ratio of at least 4.5:1" against its background. Large text needs at least 3:1. Pale grey placeholder text and light text on brand colours are the usual failures.
- 1.4.11 Non-text Contrast (AA). Interface components and meaningful graphics need a contrast ratio of at least 3:1 against adjacent colours. This covers input borders, icon buttons and the focus indicator.
- 1.4.4 Resize Text (AA). Text can be resized "up to 200 percent without loss of content or functionality."
- 1.4.10 Reflow (AA). At a width equivalent to 320 CSS pixels, content should not need scrolling in two directions.
Structure
- 1.3.1 Info and Relationships (A). Structure that you show visually must also be in the code. A heading that looks like a heading must be marked up as one; a list must be a list; a table of data must be a table. MDN puts it well: one of the best aids a screen reader user can have is "an excellent text structure with headings, paragraphs, lists, etc."
- 3.1.1 Language of Page (A). "The default human language of each web page can be programmatically determined." Set the language on the html element.
- 2.4.4 Link Purpose (In Context) (A). The purpose of a link should be clear from its text, or its text together with its context. MDN's advice is not to use "Click here" for your labels, and to make sure link text makes sense when read on its own.
Keyboard and focus
- 2.1.1 Keyboard (A). "All functionality of the content is operable through a keyboard interface."
- 2.4.3 Focus Order (A). Focus moves in an order that preserves meaning and operability.
- 2.4.7 Focus Visible (AA). There is a visible focus indicator. Removing the browser's focus outline without providing a replacement fails this criterion.
- 2.4.11 Focus Not Obscured (Minimum) (AA). New in 2.2. A focused control must not be entirely hidden by content you added, such as a sticky header, footer or cookie banner.
Forms and sign-in
- 3.3.2 Labels or Instructions (A). "Labels or instructions are provided when content requires user input." Each field needs a real label connected to it. MDN notes that without that association, a screen reader may only announce something like "edit text".
- 3.3.1 Error Identification (A). When an input error is detected automatically, the field in error is identified "and the error is described to the user in text." A red border alone is not enough.
- 3.3.8 Accessible Authentication (Minimum) (AA). New in 2.2. The W3C summarises it as "Don't make people solve, recall, or transcribe something to log in." In practice, make sure nothing in your login flow forces people to remember or retype something unaided; for example, do not stop password managers from filling the form.
- 3.3.7 Redundant Entry (A). New in 2.2: "Don't ask for the same information twice in the same session." Multi-step sign-ups and checkouts are where this bites.
Touch and pointer
- 2.5.8 Target Size (Minimum) (AA). New in 2.2. Pointer targets should be at least 24 by 24 CSS pixels, with listed exceptions such as having enough spacing around a smaller target. Tiny icon buttons in table rows are the usual offender.
- 2.5.7 Dragging Movements (AA). New in 2.2. Anything you can do by dragging needs a simple pointer alternative. If your app has a drag-to-reorder list or a Kanban board, add buttons or a menu that do the same job.
Components you build yourself
- 4.1.2 Name, Role, Value (A). For every interface component, including ones generated by scripts, "the name and role can be programmatically determined". This is where custom dropdowns, tabs and toggle switches fail.
Use native HTML before anything clever
The single most effective accessibility habit is choosing the right element. MDN's example is a button. A real button element has keyboard support built in: users can Tab to it and activate it with Space, Return or Enter. A div styled to look like a button has none of that. MDN's conclusion: "Better to just use the right element for the right job in the first place."
The same applies to links, form inputs, selects and headings. Replace a native element with a div and you have to rebuild keyboard behaviour and the name and role screen readers rely on. Generated code can contain either kind of markup, so open it and check what your buttons and menus actually are. What an AI app builder actually produces explains what to expect in generated code and where to look.
How to check your app in an hour
The W3C publishes a set of "Easy Checks" that anyone can run. They cover the page title, image alternatives, headings, contrast, text resize, keyboard access and visible focus, form labels and errors, moving or flashing content, multimedia alternatives and basic structure. A practical pass for a small app:
- Unplug the mouse. Tab through every page. Can you reach and operate every control? Can you always see where focus is? Does focus ever disappear behind a sticky header?
- Zoom to 200 percent. Does anything get cut off or overlap?
- Narrow the window to phone width. Is there any horizontal scrolling for normal text?
- Check contrast on body text, placeholder text, buttons and input borders with a contrast checker.
- Submit every form empty and wrong. Is each error described in text, next to the right field?
- Turn on a screen reader for five minutes and listen to your sign-up flow. Are buttons and fields announced with sensible names?
Know the limits. The W3C says the Easy Checks are "not a complete evaluation of accessibility" and warns that "a web page could seem to pass these checks, yet still have significant accessibility barriers." They are a screening tool. Even so, they are a fast way to find obvious barriers, and they cost an afternoon.
Add these checks to your launch routine alongside the pre-launch checklist for generated code. Several of them overlap with performance work: reserving space for images and keeping layouts stable helps both, which Core Web Vitals explained covers in more detail.
