How to make a website accessible: 10 steps

Accessibility work goes faster when it is done in a sensible order: decide what you are aiming at, let a scanner find the cheap wins, fix the problems that affect the most people, and only then move to the checks that need a person. The ten steps below follow that order. Each one names the WCAG success criteria involved, the GotAlt tool that checks it, and what a person still has to check, because every tool here stops somewhere.

The 10 steps at a glance

The steps in detail

Step 1. Set the target: WCAG 2.2 Level AA

Pick a standard before you fix anything, so that "done" means something. The Web Content Accessibility Guidelines (WCAG) are the technical standard that laws around the world point to. WCAG 2.2 has 86 success criteria, 55 of them at Levels A and AA, and each version keeps the criteria of the older ones, so meeting 2.2 also meets 2.1 and 2.0 (W3C WCAG overview, WCAG 2.2). Level AA is the level laws usually name, though often an older version: the US ADA Title II web rule names WCAG 2.1 AA, and the EU's referenced standard, EN 301 549 v3.2.1, is aligned to WCAG 2.1 AA (ADA.gov, AccessibleEU; see our EN 301 549 explainer). Building to 2.2 AA covers both.

WCAG: the whole of Levels A and AA, listed in WCAG 2.2 explained and in the WCAG 2.2 checklist. Tool: the accessibility law finder lists the laws that may cover your organization and the standard each names; which WCAG version the law requires explains the differences. A person must check: whether a law covers you at all. This is general information, not legal advice; for the question itself, ask a lawyer who covers your jurisdiction. The laws hub links the US, EU, UK and Canadian summaries.

Step 2. Scan, to find the failures a machine can find

Run a scan first, because it is the fastest way to see how big the job is. The free scan fetches a page, plus up to two linked pages, and runs 16 rule-based checks on the HTML your server sends: missing alt text, missing form labels, links and buttons with no name, missing page language and title, skipped headings and more. The methodology page maps each check to its WCAG criterion.

The scan reads HTML. It does not see content a script adds later, and it does not compute rendered colors. For the page as your browser shows it, including a staging site, localhost or a page behind a login, use the accessibility bookmarklet, which checks alt text, headings, link names, form labels and the contrast of the text on screen in your own browser.

A person must check: everything else. A clean scan means only that these checks found nothing. Why scanners miss issues explains where the line sits, and how to test website accessibility covers the manual half.

Step 3. Fix images and alt text

Every image that carries information needs a text alternative that serves the same purpose, and purely decorative images need to be marked so assistive technology skips them (WCAG 1.1.1 Non-text Content, Level A). In practice that is three cases: describe what an informative image shows, give a decorative image an empty alt="", and name the action for an image inside a link or button.

<!-- Failing: no alt attribute -->
<img src="boot.jpg">

<!-- Fixed: informative -->
<img src="boot.jpg"
  alt="Red leather ankle boot">

<!-- Fixed: decorative -->
<img src="swirl.png" alt="">

WCAG: 1.1.1, with a full walkthrough in WCAG 1.1.1 Non-text Content. Tools: the free scan flags images with no alt attribute and alt text that is a filename or placeholder. The alt text checker goes further: it downloads the image and checks whether the description is true of the picture, for the first six described images on a page. The alt text generator drafts descriptions for images that have none, and the deep audit opens up to six images per page. A person must check: that each description is accurate and useful in context. A drafted description is a first draft to edit, not a finished answer. Start with the complete guide to alt text, then alt text examples, alt text for product images and how accurate AI alt text is.

Step 4. Fix color contrast

Text needs a contrast ratio of at least 4.5:1 against its background, or 3:1 for large text, which W3C defines as 18 point or larger, or 14 point or larger and bold (WCAG 1.4.3 Contrast (Minimum), Level AA). Interface parts such as input borders and icons that carry meaning need 3:1 against their surroundings (WCAG 1.4.11 Non-text Contrast, Level AA), and color must not be the only way information is shown (WCAG 1.4.1 Use of Color, Level A).

WCAG: 1.4.3, 1.4.11, 1.4.1; see WCAG 1.4.3 Contrast (Minimum). Tools: the color contrast checker measures any pair of colors and suggests the nearest passing color. For text over a photo, gradient or screenshot, the image contrast checker measures the worst spot inside a box you draw, in your browser. The bookmarklet measures the text actually painted on a live page. The free scan cannot check contrast, because it reads HTML and never paints the page. A person must check: hover, focus and error states, text over images, and dark-mode palettes. The full method is in the color contrast guide.

Step 5. Fix headings and page basics

Headings are how screen reader users skim a page. Use one h1, do not skip levels, and make each heading describe its section. That is good practice rather than a literal WCAG rule. Structure that is visible on screen must also be in the markup (WCAG 1.3.1 Info and Relationships, Level A), and headings and labels must describe topic or purpose (WCAG 2.4.6, Level AA). Two page-level basics belong here too: a title that describes the page (WCAG 2.4.2, Level A) and a declared language (WCAG 3.1.1, Level A), set as <html lang="en">.

WCAG: 1.3.1, 2.4.6, 2.4.2, 3.1.1. Tools: the heading checker draws the outline of any HTML you paste and flags a missing or repeated h1, skipped levels and empty headings; the free scan flags a missing page language or title. A person must check: the words. A tool can tell that an h2 exists, not whether "Overview" describes what follows.

Step 6. Fix forms and labels

Every field needs a label that is programmatically tied to it, and visible instructions where input is needed (WCAG 3.3.2 Labels or Instructions, Level A). A placeholder alone is not a label: it vanishes when someone types.

<!-- Failing: placeholder only -->
<input type="email"
  placeholder="Email">

<!-- Fixed: a connected label -->
<label for="email">Email</label>
<input type="email" id="email">

WCAG: 1.3.1, 3.3.2, 4.1.2, and 3.3.1 for errors. Tools: the free scan flags form fields with no label, and the bookmarklet also flags fields labeled only by their placeholder. A person must check: submit each form empty and with a mistake. When input is automatically found to be wrong, the field in error must be identified and the error described in text (WCAG 3.3.1 Error Identification, Level A), which only a person can judge.

Step 7. Fix links and buttons

A link or button needs a name a screen reader can announce. An icon with no text and no aria-label is announced as just "link" or "button". The purpose of a link should be clear from its text or its programmatically determined context, such as the same sentence, list item or table cell (WCAG 2.4.4 Link Purpose (In Context), Level A), and every interface component needs a name and role that software can read (WCAG 4.1.2 Name, Role, Value, Level A).

<!-- Failing: icon-only button -->
<button><svg>...</svg></button>

<!-- Fixed: it has a name -->
<button aria-label="Open menu">
  <svg aria-hidden="true">...</svg>
</button>

WCAG: 2.4.4, 4.1.2. Tools: the link text checker flags empty links, generic text such as "click here", bare URLs and identical text pointing to different places in pasted HTML; the free scan and the bookmarklet flag links and buttons with no accessible name. A person must check: whether the text still makes sense out of context, and whether an aria-label matches what the control does.

Step 8. Make it work with a keyboard

Everything that works with a mouse has to work with a keyboard alone (WCAG 2.1.1 Keyboard, Level A). Focus must never get stuck in a component (WCAG 2.1.2 No Keyboard Trap, Level A), the focus indicator must be visible (WCAG 2.4.7 Focus Visible, Level AA), and repeated blocks such as a menu need a way to be skipped (WCAG 2.4.1 Bypass Blocks, Level A), usually a "Skip to content" link.

WCAG: 2.1.1, 2.1.2, 2.4.7, 2.4.1. Tools: no GotAlt tool tests this. Finding a keyboard trap means pressing Tab and watching what happens in a real browser, and the methodology page lists keyboard traps and focus order as things a static check cannot see. The scan does flag positive tabindex values, which disturb focus order. A person must check: all of it. Put the mouse aside, press Tab through the page and the manual routine shows what to look for.

Step 9. Caption media and fix documents

Prerecorded video with sound needs captions (WCAG 1.2.2 Captions (Prerecorded), Level A) and audio description for what is only shown on screen (WCAG 1.2.5 Audio Description (Prerecorded), Level AA). Documents you link to, such as PDFs, are part of what visitors have to read.

WCAG: 1.2.2, 1.2.5. Tools: the PDF accessibility checker reads a PDF in your browser, without uploading it, and checks the structure screen readers depend on: tags, language, title, headings, figure alt text, tables, bookmarks and form fields. It cannot tell whether the reading order is right. No GotAlt tool checks whether captions or audio description exist. The free scan flags only unmuted autoplaying audio or video (WCAG 1.4.2). A person must check: whether captions exist and are accurate, transcripts, audio description, and a PDF read aloud by a screen reader.

Step 10. Publish a statement, then keep monitoring

An accessibility statement tells visitors what you aim for, what is known to fall short and how to reach you. W3C says a statement should contain at least a commitment to accessibility, the standard applied, such as WCAG 2.2, and contact information, and that statements are not required everywhere, though some policies and laws require them (W3C: Developing an Accessibility Statement). The statement generator turns a short form into a plain-text draft in your browser, and the accessibility statement guide explains what to include. Choose "partially conformant" unless real testing supports more. A statement is a claim about your own testing, not a certification.

Sites drift. A new template, plugin update or uploaded image can reintroduce a failure you fixed last month. Re-run the free scan after each release, and if you want pages watched automatically, paid plans re-check the pages you nominate every week and flag new breakage. Whichever route you take, keep a dated log of what was tested and what was found.

Also on the Level AA list: zoom, reflow, spacing and target size

Four more Level AA criteria sit outside the ten steps because they are about how a page behaves when it is resized or touched, and no GotAlt tool checks them. The one exception is a viewport tag that blocks zoom, which the free scan flags under 1.4.4.

• WCAG 1.4.4 Resize Text (explained): except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
• WCAG 1.4.10 Reflow (explained): content can be presented without loss of information or functionality, and without scrolling in two dimensions, at a width of 320 CSS pixels, except for parts that need two-dimensional layout such as maps, diagrams and data tables.
• WCAG 1.4.12 Text Spacing (explained): nothing may be lost when line height is 1.5 times the font size, paragraph spacing 2 times, letter spacing 0.12 times and word spacing 0.16 times.
• WCAG 2.5.8 Target Size (Minimum) (explained), new in WCAG 2.2: pointer targets are 24 by 24 CSS pixels, with exceptions for spacing, equivalent controls, inline links, browser-controlled controls and essential cases.

A person must check: all four. The manual routine shows how to test zoom and reflow, and what is new in WCAG 2.2 covers target size and the other added criteria.

Where to start if you only have an hour

Run the scan and fix what repeats across every page, because template fixes pay off site-wide: the page language, the logo and navigation icons, the search and cart controls, the form labels in the footer sign-up, and the link and button colors. Then fix alt text on your top pages. Finish with ten minutes at the keyboard. Platform guides cover where those settings live: Shopify, WordPress, Wix, Squarespace and Webflow.

To see which failures are most likely to be on your site, read the six most common accessibility errors.