Skip to main content
WCAGrules
Quick navigation

Checklists · 35 checks

35 Checks for Website Accessibility, in Plain English

Everything we check first on a new audit, in the order we check it, written so you can run it yourself.

35 Checks for Website Accessibility, in Plain English

Checks
35
Time
About 90 minutes for three pages
Last reviewed
August 28, 2026

For the owner or marketer who wants to know where their site stands before they buy anything.

This is the working list rather than a marketing summary. It is the sequence we run at the start of an audit, trimmed down to the checks you can do yourself with the browser you already have open.

Pick your three pages before you start. Your home page, one product or service page, and whatever your checkout, booking or contact flow is. Run all 35 on those three. It tells you far more than skimming forty pages, because the failures that cost you money sit between a visitor and the thing they came to do.

The seven groups below run in the order we run them. Keyboard first. Those failures strand people completely and take two minutes to find. Then images, color, forms and structure, then zoom, and the media checks last, because they are the slowest and the least likely to be the thing blocking somebody today.

Keyboard access

Start here. A keyboard failure does not slow somebody down, it stops them, and it is the fastest thing on this page to test because you already have everything you need. Put the mouse out of reach. Work through all six with the keyboard alone.

  • Reach every control with Tab alone

    Tab from the top of the page and watch where focus lands at each press. Every link, button, field and menu should take its turn. Anything you can click and cannot reach with Tab is unavailable to a keyboard user. That includes switch users, because a switch sends keystrokes underneath.

    WCAG 2.1.1

  • See where focus is at all times

    Watch for a visible outline or highlight at every stop, and note the exact control where it disappears. Losing the indicator leaves somebody pressing Enter without knowing what they are about to activate. The usual cause is one CSS rule. It removes the outline and puts nothing back.

    WCAG 2.4.7

  • Escape from everything you can enter

    Open each modal, dropdown and date picker, then try to get back out with Escape or Tab. Being able to enter something you cannot leave is the worst keyboard failure there is, because there is no mouse to reach for. A component that needs some other key still conforms as long as it tells the user which key, so look for that instruction before you write it up.

    WCAG 2.1.2

  • Follow a focus order that matches the page

    Tab through and check that focus moves roughly the way your eye reads. Note anywhere it jumps to an unrelated part of the page, because that is a reader losing their place. When the order is wrong and there is no tabindex anywhere, look at your flex or grid ordering, which moves things visually and leaves the source order behind.

    WCAG 2.4.3

  • Get past the repeated header without tabbing through it

    Load a fresh page and count the Tab presses it takes to reach your main content. Four or five means something is already carrying people past the navigation and the rule is met, whether or not a link appeared. Forty means it is not. Ignore the press-Tab-once test. Two sufficient routes satisfy this rule and six documented techniques sit under them, so landmarks or a heading starting each region do the same job and a conforming page can show you nothing at all on the first press.

    WCAG 2.4.1

  • Operate custom widgets by keyboard

    Sliders, carousels, tab panels and star ratings are where hand-built components fail, because each one replaces something the browser used to handle. Try each with Tab and the arrow keys. If it responds to neither, it was built from divs. That needs a native element, or the keyboard handling written back in.

    WCAG 2.1.1

Images and alt text

Every image on your site is either carrying meaning or it is decoration, and the two need opposite treatment. Getting it wrong either way creates a barrier. A described flourish is noise, and an undescribed chart is a hole in the page.

  • Give every meaningful image alt text

    Right-click an image, choose inspect, and read the alt attribute in the markup. What you want it to say is what the image tells a reader in this spot on this page, which is not always what is visible in it. The same product photo needs different words on a listing page and in a size guide.

    WCAG 1.1.1

  • Give decorative images an empty alt

    Dividers, flourishes and background textures need an alt attribute with nothing inside it, which tells a screen reader to walk past them. Leaving the attribute off altogether is a different thing and a worse one, because several screen readers then read the filename aloud instead.

    WCAG 1.1.1

  • Remove filenames and "image of" from your alt text

    Paste a few of your alt strings into our checker, or search your source for .jpg and .png sitting inside an alt attribute. Both come from the same place. Bulk imports and stock libraries fill the field automatically, so where you find one you will find hundreds.

    WCAG 1.1.1

  • Describe charts and infographics in full

    The rule asks for a text alternative serving the same purpose, and for a chart that means the numbers rather than the shape. Naming it as a bar chart tells a reader what they are missing. It does not give it to them. The better answer is a short alt naming the chart and the actual figures written into the page, where every reader gets them.

    WCAG 1.1.1

  • Name image links by destination, not appearance

    When an image is the whole of a link, its alt becomes that link's name, so it should say where the link goes. A linked logo in your header reads as "Home", never as "logo", because nobody scanning a list of links is looking for a picture.

    WCAG 2.4.4

Color and contrast

This is the most-failed rule on the web. It is also the one a machine settles outright, which makes it the cheapest group here to clear. Measure the pairs rather than judging by eye. Your screen is not the screen anybody else is using.

  • Clear 4.5 to 1 on body text

    Take each text and background pair to the contrast checker and read the ratio. This is the threshold ordinary paragraph text has to meet, and the places it usually fails are the quiet ones. Placeholder text, captions, muted timestamps and anything described in a design file as secondary.

    WCAG 1.4.3

  • Clear 3 to 1 on large text

    Large text gets a lower bar, and the definition is stricter than most people apply. It is set in points, at 18 point or 14 point bold, which converts to 24px and 18.66px. The point size is the requirement and the pixel figure is only the conversion, so do not turn a rounded-down number into your threshold. The size that counts is the size you shipped, so a reader zooming your body copy up to that size never turns it into large text.

    WCAG 1.4.3

  • Clear 3 to 1 on buttons, borders and icons

    Interface parts answer to their own rule, separate from the one for text, and it is missed far more often. Measure each against whatever sits directly behind it. A pale gray input border on white is the classic failure. It makes a form look like decoration.

    WCAG 1.4.11

  • Carry meaning by something other than color

    Turn the page grayscale in your browser's rendering settings and look again. Required fields, error states, chart series and link text all have to stay distinguishable once the color is gone, because that is the page a color blind visitor is already reading.

    WCAG 1.4.1

  • Underline links inside paragraphs

    A link in running text needs something other than color marking it out, and an underline is the answer everybody already recognizes. Check it in grayscale. If the links vanish, a visitor has to hover across the paragraph hunting for them.

    WCAG 1.4.1

Forms and error messages

Forms are where money and inquiries are lost, because a form is the one place on your site where the visitor has to give something before they get anything. A field with no label is announced as "edit text, blank". That tells somebody a box exists and nothing about what belongs in it.

  • Give every field a visible label, then check it is wired up

    Two things are being tested here and they answer to different rules. A field with no label at all is what fails 3.3.2, so look for a visible prompt on each one. Then click the label text itself and watch focus jump into its field, because a label that is not connected to its input fails 1.3.1 as well. The words stay on the page either way, so this is not about whether they can be read at all. It is about whether the field announces them when somebody lands on it, and an unconnected label does not.

    WCAG 3.3.2

  • Keep labels visible once typing starts

    Type a character into every field and see what disappears. A placeholder vanishes the moment somebody starts typing, which leaves anybody who is interrupted, distracted or working slowly staring at a box with no idea what it wanted. Put the label above the field. Let the placeholder be an example.

    WCAG 3.3.2

  • Name the field in every error message

    Submit the form empty and read what comes back. Each message should name the field and say what is wrong with it, so "Enter your ZIP code as five digits" rather than "invalid input". The test is whether somebody could act on the message without looking at the screen.

    WCAG 3.3.1

  • Announce errors rather than only rendering them

    Submit the form wrong with a screen reader running and listen for silence. Text on the page satisfies the error rule on its own, so a visible message is not a failure of that one. What it fails is the status message rule, because the words only reach somebody when focus moves to them or a live region carries them across.

    WCAG 4.1.3

  • Group related fields under a legend

    Radio groups and checkbox sets need a fieldset with a legend, so the question is announced along with the option. Without it a screen reader user hears "Standard, radio button" and never hears the delivery question that gave it meaning.

    WCAG 1.3.1

  • Set autocomplete on the fields asking about the user

    Name, email, address and phone fields each need the right autocomplete token, which lets a browser or a password manager fill them for somebody who finds typing slow or painful. The rule reaches only information about the person filling the form in, so a gift recipient's address or a referee's email sits outside it and needs no token.

    WCAG 1.3.5

Page structure

Structure is how a screen reader user navigates, and most of them jump by heading before reading a word. Without it your page arrives as one long undifferentiated block. That is the difference between skimming and sitting through it.

  • Use one h1 per page

    Run the heading checker and read the outline it hands back. A single top-level heading names the page and gives somebody a place to start. Worth knowing where this sits, though, because WCAG sets no number of h1 elements anywhere, which makes this good practice rather than a rule anybody can fail you on.

  • Skip no heading levels

    An h2 followed by an h4 leaves a gap in the outline, which tells a listener a section exists that never arrives. This has the same standing as the check above. W3C asks for properly nested headings and stops short of making a skip a failure, so fix it as a defect rather than logging it as a breach.

  • Use real headings rather than big bold text

    This is the heading check that is genuinely a rule. Inspect each thing that looks like a heading and confirm it is an h1 to h6 element rather than a styled div or a bolded paragraph. Anything presented as a heading has to be marked up as one, and a styled div is invisible to the heading list your reader is navigating by.

    WCAG 1.3.1

  • Give every page a descriptive title

    Read your browser tab. The title should name the page first and the site second, because it is the first thing announced on arrival and the only thing distinguishing one of your tabs from the other eleven. Twelve pages called "Services" help nobody.

    WCAG 2.4.2

  • Set the page language

    Inspect the html element and look for a lang attribute carrying your language. One attribute decides which voice and which pronunciation rules a screen reader uses, so getting it wrong turns your English into something unintelligible read by a French synthesizer.

    WCAG 3.1.1

  • Mark your page regions with landmarks

    Header, nav, main and footer elements let somebody jump straight to the part they want, in the same way headings let them jump within it. This is also the other route past a repeated block, so a page with real landmarks has usually solved the navigation problem before anybody asks about a skip link.

    WCAG 1.3.1

Zoom and reflow

People with low vision browse enlarged every day. This pass takes ten minutes. It tends to find problems affecting a much larger share of visitors than anybody expects, because the same failures hit anyone on a small phone.

  • Keep all content at 200% zoom

    Press Ctrl and plus until your browser reports 200%, then read the page. Nothing should disappear, clip at the edge of its container, or slide underneath something else. Fixed heights on cards and buttons are the usual cause.

    WCAG 1.4.4

  • Reflow without a second scrollbar at 400%

    Zoom to 400% in a 1280px window and look along the bottom for a horizontal scrollbar. Scrolling sideways to read every line is what this rule exists to stop. One column is a common way of getting there and the rule never asks for it, so a two-column layout that fits is fine.

    WCAG 1.4.10

  • Survive increased text spacing

    Push line height, letter spacing and word spacing up in your browser's dev tools and watch what breaks. Text must not clip or overlap when somebody applies their own spacing, which people with dyslexia commonly do. Anything with a fixed height around text is where it fails.

    WCAG 1.4.12

Video, audio and motion

Two separate obligations live in this group and it helps to keep them apart. One is making what you published available another way. Captions and transcripts do that. The other is not taking control away from somebody, which is what an unstoppable carousel does.

  • Caption every video that has speech

    Turn the captions on and watch a minute of it. Automatic captions get you most of the way and they fail predictably on names, jargon and numbers, which are usually the words carrying the point. Budget a human pass over the transcript. Do not trust the machine.

    WCAG 1.2.2

  • Provide a transcript for audio-only content

    Podcasts and recorded calls need a text version published on the same page, not buried in the player. This is the rule for audio with no video and for silent video, and it is also the cheapest accessibility work you will ever do, because the transcript is searchable and everybody uses it.

    WCAG 1.2.1

  • Let people stop anything that moves or autoplays

    Carousels, tickers and animations that run longer than five seconds need a pause or stop control, which is the rule about moving information. Audio that starts on its own and runs past three seconds answers to a different rule and needs its own remedy, which can be a stop control or a volume control independent of the system one.

    WCAG 2.2.2

  • Respect the reduced-motion preference

    Turn on reduce motion in your operating system settings, reload, and watch the page again. Large parallax and slide transitions should be cut back or gone. For somebody with a vestibular disorder that movement causes nausea. It is a comfort setting only for the people it does not affect. The rule behind it sits at the enhanced level rather than at AA, so this is advice with evidence rather than an obligation.

    WCAG 2.3.3

One honest limit

This list covers what you can check yourself in an afternoon, and it stops where judgment starts. It cannot tell you whether your alt text is true, whether your checkout makes sense heard rather than seen, or whether an error message actually helps the person reading it. Those need somebody who uses a screen reader daily, and that is what the audit adds.

Keep going

Other checklists

Ticked every box and want it verified?

The full audit tests all 55 WCAG 2.2 A and AA rules with a pass or fail on each, adds an expert review, and puts a real blind screen-reader user on your key journeys. $499, report in 5 business days.

Order your audit

Go somewhere useful

Find tools, resources and your workspace.

29 destinations