Website Accessibility Checklist for 2026: A Practical WCAG 2.2 Guide

Why website accessibility matters now

An accessible website can be used by everyone, including people who are blind or have low vision, people who navigate with a keyboard, and people with hearing, motor, or cognitive disabilities. It is also a better website for everyone else: clearer text, obvious buttons, and forms that are easier to complete.

Most of the web is not there yet. The same handful of problems, such as low-contrast text, missing alt text, and unlabeled form fields, show up on site after site. That is good news, because a short list of fixes removes a lot of real barriers.

Accessibility is also a legal matter in more places. The European Accessibility Act has applied since 28 June 2025 to many digital products and services sold in the EU, and accessibility lawsuits remain common in the United States. Treat this guide as practical advice, not legal advice.

What is the fastest way to make a website accessible? The short answer

To make your website accessible, aim for WCAG 2.2 level AA. Start by fixing the most common issues: low contrast, missing alt text, unlabeled form fields, empty links and buttons, and a missing page language. Then test by hand with a keyboard and a screen reader, build accessible components into your design system, and re-check every release.

The good news is that these six issues are also the cheapest to fix. A focused pass on them removes a large share of real barriers before you touch anything advanced.

What is WCAG 2.2?

The Web Content Accessibility Guidelines, published by the W3C, are the standard most laws and policies point to. WCAG 2.2 is the current version. It is organized around four principles, and every checklist item below maps to one of them. Level AA is the target most organizations use.

The website accessibility checklist

Use these four groups as a working checklist. Each item is something you can verify yourself in a few minutes.

Visual design

• Contrast: normal text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Check buttons, placeholder text, and text over images too.
• Color is not the only signal: errors, links, and statuses should also use text, icons, or underlines.
• Readable text: the page should still work when zoomed to 200 percent, with no text cut off.
• Visible focus: keyboard users must always see which element is focused. Never remove focus outlines without a clear replacement.

Images and media

• Every meaningful image has alt text that describes its purpose, not just its appearance.
• Decorative images are marked as decorative so screen readers skip them.
• Videos have captions, and audio content has a transcript.
• Nothing flashes more than three times per second, and auto-playing motion can be paused.

Navigation and structure

• The page language is set in the HTML.
• Each page has one H1 and a logical heading order.
• Links describe where they go. Avoid a page full of "click here" and "read more".
• Icon-only buttons have an accessible name, such as "Open menu".
• Everything works with a keyboard alone, in a logical order, with no keyboard traps.
• Clickable targets are large enough to tap comfortably on a phone.

Forms

• Every input has a visible label that is connected to it in code.
• Required fields are marked in text, not only with color or an asterisk.
• Error messages say what went wrong and how to fix it, next to the field.
• Users are not asked to re-enter information they already gave in the same process.

What should you fix first?

You will not fix everything in a week, so order the work by how many people it blocks and how fast the fix is. This table is the order we use on audits.

A worked example: auditing a services site

Imagine a services company with a home page, six service pages, a blog and a contact form. In a typical audit, we would scan the five main templates first and note every flagged issue. Then we would tab through the home page, the contact page and one service page, and try the contact form with a screen reader.

The usual findings are predictable. The gray body text on a white background is too light. The hero image has no alt text. The menu icon has no name. The form uses placeholder text instead of labels. The focus outline was removed in the style sheet. Each one has a small fix, and together they change how the site feels to use. The result is a short, ordered list for the team, with the fastest wins at the top.

How to test your website for accessibility

Testing works best as a loop of five steps: scan, test by hand, fix the basics, build it into your design system, and monitor.

1. Run an automated scan

Tools such as WAVE, axe, or Lighthouse flag common issues quickly. Scan your main templates: home page, a service page, a blog post, a form, and checkout if you have one. Remember that automated tools only catch a part of real accessibility problems.

2. Test by hand

Put your mouse away and navigate the whole page with Tab, Shift+Tab, Enter, and the arrow keys. Zoom to 200 percent. Then try a screen reader, such as VoiceOver on Mac and iPhone or NVDA on Windows, on your key flows. The keyboard test below takes about two minutes per page.

3. Fix the basics first

Contrast, alt text, labels, focus states, and link text cover a large share of real barriers, and most fixes are quick. Fix these before you spend time on edge cases.

4. Build accessibility into your design system

Fixing pages one by one does not last. Make buttons, forms, menus, and modals accessible at the component level, so every new page inherits the fix. Our guide to building a design system explains how. Palette choices matter here too, and how to choose brand colors shows how to test contrast before a color becomes a token.

5. Monitor every release

New pages, campaigns, and CMS content can reintroduce problems. Add an accessibility check to your launch checklist and re-scan regularly. If you are planning a bigger update, fold these checks into your website redesign checklist.

What does a screen reader test involve?

You do not need to be an expert to catch the worst problems. Turn on VoiceOver or NVDA, close your eyes or turn the screen off, and try to complete one real task, such as finding a service and sending the contact form.

1. Listen to how the page is announced. Is the page title clear?
2. Move by headings. Do they give a usable outline of the page?
3. Move through links. Does each one make sense on its own?
4. Fill in the form. Is every field named, and are errors read out?
5. Open the menu and any dialog. Can you get in and out without getting lost?

If you get stuck at any point, a real user would too. Write down where and fix that first.

What does good alt text look like?

Good alt text says what an image is for, not just what it looks like. Ask one question: if the image vanished, what would the reader miss?

• Informative image: a chart of monthly signups gets alt text that states the trend, such as "Signups grew each month from January to June".
• Image link: a logo that links to the home page gets "Mound Studio home", not "logo".
• Icon button: a magnifier icon that opens search gets "Search".
• Decorative image: a background swirl gets empty alt text, so screen readers skip it.

How do you build an accessible form?

Forms are where sites lose customers, so they deserve extra care. Follow these steps for every field.

1. Put a visible label above the input and connect it to the field in code.
2. Mark required fields with the word "required", not just a color.
3. Use the right input type, so phones show the right keyboard.
4. Write errors that name the field and the fix, such as "Enter an email address like name@company.com".
5. Move focus to the first error after a failed submit.
6. Test the whole form with the keyboard, then with a screen reader.

How do you fix a hidden focus outline?

Many designs remove the outline because it looks messy. Do not delete it. Restyle it instead: use a thick outline in a color that has strong contrast with both the element and the page, and leave a small gap so it does not blend in. Then tab through every page and check that each link, button, and field shows it clearly.

How do you write accessible content?

Accessibility is not only code and color. The words matter too. Plain language helps people with cognitive disabilities, people reading in a second language, and everyone in a hurry.

• Use short sentences and common words.
• Put the main point first in each section.
• Use headings that describe what follows, so people can scan and screen reader users can jump.
• Write link text that makes sense out of context, such as "read the migration guide".
• Spell out abbreviations the first time you use them.
• Avoid instructions that depend on sight alone, such as "click the green button on the right".

Editors should have these rules in their publishing checklist, since new content is where problems often return.

What about phones and touch screens?

Many people use a phone with one hand, in poor light, or with a screen reader turned on. Make sure targets are large enough to tap without hitting the wrong one, keep enough space between links, and do not lock the page to one orientation. Test with your device settings changed: larger text, reduced motion, and a screen reader. If the layout breaks when the text size increases, real users will see the same break.

Common accessibility mistakes to avoid

• Relying on an overlay widget instead of fixing the underlying code.
• Adding ARIA attributes everywhere instead of using proper HTML elements first.
• Testing only with automated tools.
• Removing focus outlines because they look messy.
• Using placeholder text as the only label for a field.
• Writing alt text that repeats the file name or stuffs keywords.
• Treating accessibility as a one-time project instead of part of the process.

How do you keep accessibility working across a team?

The fixes only last when everyone knows their part. Designers check contrast and focus states before handoff. Developers use the right HTML elements and test with a keyboard. Editors write alt text and clear links. Someone owns the checklist and runs the scan before each release. Our Figma developer handoff checklist is a good place to add accessibility notes, and a wider review such as a UX audit is a natural time to check these points too.

Consider publishing a short accessibility statement and a way for visitors to report problems. It shows that you take the topic seriously, and it gives you real feedback from real users. Reply to reports quickly and fix what you can.

Accessibility launch checklist

• Every text and background pair passes AA contrast.
• Page language is set and each page has one H1.
• All meaningful images have alt text, and decorative ones are marked.
• Every form field has a visible label and a clear error message.
• All icon buttons and image links have names.
• The full page works with a keyboard, and focus is always visible.
• The page works at 200 percent zoom.
• Videos have captions.
• A screen reader run of the main task has been done.

Where should you start?

If you have a live site, run a scan on your five main templates this week and fix the top six issues from the table above. If you are designing something new, put contrast, focus states, and form labels into the first version of your components. If you outsource design or development, ask for these checks in the brief, not in a bug list at the end.

The takeaway

Accessible sites are clearer, easier to use, and often perform better in search, and it is far cheaper to build accessibility in from the first wireframe than to retrofit it. It is part of every web design and UI/UX design project we run, so talk to us if you want your site audited.