Website accessibility checklist: 12 checks a small business can do today

What this checklist can—and cannot—tell you

This website accessibility checklist is a first pass. It can help you find barriers on important pages, write a useful fix list and start a better conversation with your web team. You do not need specialist software for most of it.

It cannot prove that your website conforms to the Web Content Accessibility Guidelines (WCAG), complies with the Americans with Disabilities Act (ADA) or works well for every disabled person. It is not a certification, complete audit or legal advice.

A score is not accessibility. Automated tools find patterns, but they cannot reliably judge whether content communicates its purpose or an interaction is usable.

As of August 27, 2026, WCAG 2.2 is the current W3C Recommendation. W3C recommends 2.2 for current work while noting that even its highest conformance level does not address every user need. CMT Web treats accessibility as ongoing work, as explained in our Accessibility Statement.

For businesses open to the public, ADA.gov’s guidance says Title III applies to goods, services and activities offered online. It also says the Department of Justice has not set detailed technical standards for those businesses in a web-specific Title III regulation. Requirements vary, so ask qualified counsel about your situation.

Start with the homepage, contact page and a key booking, service, product or checkout page. Check desktop and mobile layouts where you can.

The 12 checks

1. Give every page a useful, unique title

The page title appears in the browser tab and is often the first thing a screen reader announces after a page loads. It helps people identify a page and tell several open tabs apart.

How to test: Open three pages. Hover over each browser tab to reveal the full title. Put page-specific information first: “Private dining | Restaurant Name” is more useful than “Restaurant Name | Welcome.”

A problem looks like: Every tab says “Home,” “Untitled” or only the company name. Different booking steps share one title.

Who likely fixes it: A content editor can usually update titles in the content management system (CMS). A developer should fix a template that repeats or omits them.

2. Make headings describe the page structure

Headings are not just large text. Proper heading markup creates an outline that screen-reader users can navigate and helps everyone scan a page.

How to test: Read only the headings. Do they summarize the page? Use the Structure panel in the free WAVE extension to compare visible headings with the marked-up outline. Look for a clear main heading and logically nested sections.

A problem looks like: Bold text acts as a title but is not a heading. Levels were chosen for size rather than meaning. The outline is empty or repetitive.

Who likely fixes it: The content owner names and orders the sections. A designer sets the visual styles; a developer or CMS editor applies the correct heading elements.

3. Make every action work from a keyboard

Some people cannot use a mouse. Others use keyboards, switches, voice control or assistive technology that depends on keyboard-compatible controls.

How to test: Put the mouse aside. Use Tab and Shift + Tab to move, arrow keys within menus, Enter for links and Space or Enter for buttons. Try menus, dialogs, forms and media controls.

A problem looks like: A menu opens only on hover. A custom button cannot be reached. Focus gets trapped in a dialog, or the tab order jumps unpredictably.

Who likely fixes it: Usually a developer. A designer may also need to simplify an interaction that has no clear keyboard behavior.

4. Keep keyboard focus clearly visible

Keyboard access is not useful if a person cannot tell where they are. WCAG 2.2 includes requirements for visible focus and for focus not to be hidden behind sticky headers or other content.

How to test: Repeat the keyboard test slowly. Identify the active control at every stop. Check menus, dialogs and long pages, where sticky elements may cover focus.

A problem looks like: The outline disappears, is too faint or appears on the wrong item. A sticky header or consent banner hides the control.

Who likely fixes it: A designer specifies a visible indicator that works across light, dark and image backgrounds. A developer implements it without removing the browser’s default outline unless an equally clear replacement exists.

5. Check color contrast—and information conveyed by color

Low contrast affects people with low vision or color-vision differences and anyone using a screen in glare. Under WCAG 2.2 Level AA, normal text generally needs at least 4.5:1; large text and meaningful interface graphics generally need 3:1.

How to test: Enter foreground and background colors in the free WebAIM Contrast Checker. Test text, buttons, labels, links and error states. View the page in grayscale and check that meaning remains.

A problem looks like: Pale gray text sits on white. Text overlays a busy photo. Red alone identifies a required field.

Who likely fixes it: A designer chooses accessible color combinations and non-color cues. A developer updates the site styles and every relevant interaction state.

6. Zoom in and check reflow

People with low vision may enlarge text or zoom the whole page. Content should remain readable and usable rather than overlapping, disappearing or forcing side-to-side scrolling for ordinary paragraphs.

How to test: Set browser zoom to 200% and check a narrow mobile-sized width. Read the page, open navigation and use its main form. A conformance evaluation uses the precise conditions in WCAG’s resize and reflow criteria.

A problem looks like: Text is clipped, controls overlap or navigation breaks. Paragraphs require horizontal scrolling. Important text is trapped in an image.

Who likely fixes it: A developer corrects responsive layout, sizing and overflow. A designer may need to revise dense components or images of text.

7. Give meaningful images the right alternative text

Alternative text should communicate an image’s purpose in context. A decorative flourish usually needs an empty alternative so a screen reader can skip it. A chart, product image or linked logo needs information that supports the same task as the image.

How to test: Use WAVE to reveal image alternatives. Ask: if the image vanished, would this text preserve its information or function? Check logos, icons, charts, products and linked images.

A problem looks like: The alternative is missing, a file name, keyword pile or description that misses the point. Decorative images are announced repeatedly.

Who likely fixes it: A content editor writes context-appropriate alternatives. A developer fixes missing fields, decorative-image handling or controls whose accessible name depends on an image.

8. Test form labels, instructions and errors

A form must tell people what to enter, which fields are required and how to recover when something goes wrong. Placeholder text alone is not a dependable label because it can disappear as soon as typing begins.

How to test: Complete the form by keyboard. Submit it with empty required fields and one bad format. Check for persistent labels, timely instructions and errors that name the problem and fix. Confirm valid entries remain.

A problem looks like: Placeholder text is the only label. Required fields use color alone. “Invalid input” names neither the field nor expected format. Errors appear unnoticed above.

Who likely fixes it: A content owner improves labels, examples and error copy. A developer connects labels and descriptions to controls, manages focus and exposes errors to assistive technology.

9. Replace vague link text

People often scan links visually or ask a screen reader for a list of links. Text such as “click here” and a row of identical “learn more” links make that list hard to use.

How to test: Read every link without surrounding text. Can you predict its destination or action? Name downloads and, when useful, their format. Name the same destination consistently.

A problem looks like: Unrelated links all say “Read more.” A raw URL is the label. “Download” does not identify the file.

Who likely fixes it: Usually the content editor. A developer should fix repeated card, navigation or CMS components that generate vague links.

10. Review captions, transcripts and important visuals

Captions make spoken audio and meaningful sounds available to people who are Deaf or hard of hearing. Transcripts are essential for audio-only material and useful alongside video. Important visual information that is not explained in the audio may need audio description or an equivalent text alternative.

How to test: Turn on captions and check timing, accuracy, speakers and meaningful sounds. Review auto-generated captions. Compare the transcript with the recording. Listen without the picture: does the audio omit necessary names, demonstrations or instructions?

A problem looks like: Captions are missing, delayed or change critical words. The transcript omits speakers or sounds. A silent demonstration carries unique information.

Who likely fixes it: A video or content editor corrects captions and transcripts. A developer configures the player and places alternatives where people can find and operate them.

11. Let people pause motion and respect their preferences

Carousels, animated backgrounds, auto-playing video and flashing content can distract, obscure information or create physical symptoms. People need control, and some ask their devices for reduced motion.

How to test: Wait without interacting. Can you pause moving or updating content? Turn on “reduce motion,” reload and check animations. Content flashing more than three times per second needs specialist evaluation.

A problem looks like: A carousel advances too soon. Animation ignores reduced-motion settings. A moving background has no pause control.

Who likely fixes it: A designer decides what motion is necessary and defines a reduced-motion experience. A developer adds controls and honors the prefers-reduced-motion setting. A media editor removes unsafe flashing.

12. Make the content easy to find and understand

Plain language is not about making a business sound simplistic. It is about making the next step clear. Short sections, specific headings, familiar words and direct instructions help people with cognitive and learning disabilities—and hurried customers.

How to test: Can a first-time visitor tell what the business offers, what key terms mean and what to do next? Expand acronyms. Break long paragraphs into sections or lists. Read the page in order without relying on its layout.

A problem looks like: Jargon hides the task, headings such as “Solutions” say little, or instructions rely on appearance: “use the green button on the right.”

Who likely fixes it: The business owner or content editor should lead. A designer improves hierarchy and spacing; a developer fixes a source order that stops making sense when the layout collapses.

Use only your keyboard for five minutes

If you do one check today, make it this one:

Open your homepage and click the browser’s address bar.
Put the mouse or trackpad aside.
Press Tab and name the item that has focus.
Continue through navigation, calls to action, forms and media controls.
Use Enter, Space and arrow keys to operate what you reach.
Open and close any menu or dialog. Make sure you can leave it and continue.
Use Shift + Tab to travel backward.

Write down the page, control, action and result for every problem. “Keyboard broken” is hard to fix. “On /contact, the date picker cannot be opened with Enter or Space” gives a developer somewhere to start.

What each kind of accessibility review can establish

Approach	What it is good for	What it cannot establish by itself
Easy manual check	Finding visible barriers on a specific page or task; building awareness	Coverage of all WCAG criteria, pages, states, devices or assistive technologies
Automated scan	Quickly finding detectable code patterns such as missing labels, invalid markup and some contrast failures	Whether content alternatives are appropriate, interactions are usable or the site conforms; W3C says tools require human judgment
Professional WCAG conformance evaluation	Assessing a defined site scope, processes, WCAG version and conformance level with knowledgeable human evaluation and tools	Legal compliance or every disabled person’s experience
Usability testing with disabled participants	Observing real people complete representative tasks with their own strategies and assistive technology	WCAG conformance; findings from one participant or disability cannot represent everyone
Legal review	Applying the ADA and other relevant federal, state, local, sector or contractual requirements to a specific situation	Technical or usability testing unless those services are separately included

W3C’s evaluation guidance recommends evaluating early and throughout development. It also distinguishes a preliminary check from a conformance evaluation. Testing with disabled people adds evidence that standards checks cannot provide, but it should complement—not replace—a WCAG evaluation.

Three free tools worth using carefully

WAVE browser extensions place errors, alerts and structural information in the rendered page. They are useful for reviewing a page in context, including private or dynamic pages. WAVE still requires a person to interpret the results.
Lighthouse in Chrome DevTools runs automated accessibility checks and points developers toward affected elements. Its score covers only the audits it can test; Chrome’s own guidance says keyboard and screen-reader use still need hands-on testing.
WebAIM Contrast Checker calculates the ratio for a foreground and background color pair. It is precise for the pair you enter, but you must still find and test different text, component, image and interaction states.

Run tools on several representative pages, not only the homepage. Treat every result as a lead to investigate. The Department of Justice specifically cautions that automated checkers and overlays can help, but a clean report does not necessarily mean a site is accessible. An overlay is not a substitute for accessible design, development, manual review and testing with people.

What to ask a web designer before launch

Ask for concrete work and evidence, not a promise that the site will be “ADA compliant.” Useful questions include:

Which WCAG version and level guided the design and development?
Which pages, templates and complete tasks did you test?
What did you test manually, and what did an automated tool test?
Can you demonstrate the navigation, menu, forms and dialogs using only a keyboard?
How did you check focus, contrast, zoom, reflow and reduced motion?
Who is responsible for alt text, captions and accessible content after launch?
Were disabled participants involved? If so, what tasks and assistive technologies were included?
What third-party booking, payment, map or form tools remain outside your control?
How will accessibility problems be reported, prioritized, fixed and retested?
What evidence will we receive: issue log, test scope, results and known limitations?

Accessibility should be part of web design, development and content operations—not a switch added the night before launch.

Make the next improvement useful

Do not wait for a perfect score. Fix the barrier that blocks a real person from reading, navigating, booking, buying or contacting you. Record what changed, retest it and include accessibility in the next content update.

If your site needs more than a first pass, review our work and start a conversation. The useful goal is a website more people can use, with honest evidence about what has—and has not—been tested.