Website Accessibility Checklist: How to Build a More Accessible Website

Website accessibility means designing and building a site so more people can perceive, understand, navigate, and interact with it, including people who use keyboards, screen readers, zoom, voice input, switch devices, or other assistive technology.

The most useful way to approach accessibility is not as a final audit after a website is finished. Build it into content, design, development, and testing from the start. WCAG 2.2 organizes accessibility around four principles: content should be perceivable, operable, understandable, and robust. This checklist turns those principles into practical checks you can use on a business website.

Important: this guide is a practical WCAG 2.2-aligned checklist, not legal advice. Accessibility laws and required conformance levels vary by country, industry, organization, and context.

TL;DR

Use this website accessibility checklist before launch and during ongoing site maintenance:

• Use semantic HTML and a logical heading structure.
• Give meaningful images useful alternative text and leave decorative images empty.
• Keep normal text contrast at 4.5:1 or higher and large text at 3:1 or higher.
• Do not rely on color alone to communicate meaning.
• Make every important interaction usable with a keyboard.
• Keep keyboard focus visible and make sure sticky elements do not hide it.
• Use descriptive links and buttons instead of vague labels such as “click here.”
• Label every form control and make errors clear, specific, and easy to fix.
• Make pointer targets at least 24 by 24 CSS pixels or provide enough spacing.
• Support text resizing to 200% and page reflow without losing content or functionality.
• Add captions to prerecorded video with speech and provide appropriate alternatives for audio.
• Respect reduced-motion preferences and avoid unnecessary flashing or motion.
• Test with automated tools, keyboard-only navigation, zoom, and at least one screen reader.
• Recheck accessibility whenever templates, forms, menus, components, or content change.

What Does Website Accessibility Mean?

An accessible website does not require every visitor to interact with it in the same way. It gives different users workable ways to reach the same information and complete the same important tasks.

One visitor may use a mouse. Another may use only a keyboard. A blind visitor may use a screen reader. Someone with low vision may zoom the page to 200% or more. A person with a motor impairment may need larger controls. Someone with a cognitive disability may depend on predictable navigation, clear instructions, and consistent labels.

WCAG 2.2 groups its requirements under four principles:

1. Perceivable: users must be able to perceive the content and interface.
2. Operable: controls and navigation must be usable with different input methods.
3. Understandable: content and interactions should be clear and predictable.
4. Robust: the site should work reliably with browsers and assistive technologies.

For a broader view of usability and conversion, see our web design best practices guide. Accessibility should be part of that same design process, not a separate layer added later.

Website Accessibility Checklist

1. Use Semantic HTML Before Adding ARIA

Start with native HTML elements that already communicate their meaning.

Use headings for headings, buttons for actions, links for navigation, lists for lists, labels for form controls, and landmarks such as header, nav, main, and footer where appropriate.

A common accessibility mistake is creating interactive controls with generic div or span elements and then trying to recreate button behavior with JavaScript and ARIA. Native HTML usually provides keyboard behavior, focusability, and semantics automatically.

ARIA can be useful when native HTML cannot express a component properly, but it should supplement good HTML rather than replace it.

2. Build a Logical Heading Structure

Headings should describe the page structure, not be chosen only because of font size.

Most pages should have a clear H1 that describes the main topic, followed by H2 sections and H3 subsections where needed. Avoid skipping levels simply for styling.

A logical heading outline helps screen-reader users jump between sections and also makes long pages easier for sighted users to scan.

Your visual design can style any heading size independently. Do not use an H4 just because you want smaller text.

3. Add Useful Alt Text to Informative Images

Meaningful images need text alternatives that communicate the information a user would miss if the image were unavailable.

Good alt text depends on context. A product photo might describe the product. A chart may need to communicate the trend or key numbers. A screenshot may need to explain the interface state that matters to the surrounding instructions.

Do not start every alt attribute with “image of.” Screen readers already identify images.

Decorative images that add no information should generally use an empty alt attribute so assistive technology can ignore them.

4. Meet Minimum Text Contrast

WCAG 2.2 contrast guidance requires at Level AA a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, with defined exceptions.

Do not judge contrast by eye. Test actual foreground and background values.

Pay particular attention to:

• light gray body copy
• placeholder text
• text over images or gradients
• disabled-looking controls that are actually interactive
• footer links
• small labels
• secondary buttons
• text that changes color on hover

Brand colors can usually be adapted into accessible combinations without abandoning the brand.

5. Never Use Color as the Only Signal

Color can reinforce meaning, but it should not carry meaning by itself.

If a form field has an error, do not communicate that only by turning the border red. Add an icon, text message, or another clear cue.

The same applies to:

• required fields
• chart categories
• selected states
• success and warning messages
• pricing comparisons
• links inside body text

This helps people with color-vision deficiencies and also improves general clarity.

6. Make the Entire Site Keyboard Accessible

A visitor should be able to reach and operate every meaningful interactive element without a mouse.

Test menus, dropdowns, accordions, modals, forms, sliders, tabs, cookie banners, video controls, search, and custom widgets using only:

• Tab
• Shift + Tab
• Enter
• Space
• arrow keys where the component pattern requires them
• Escape for dismissible overlays where appropriate

The focus order should follow a logical reading and interaction sequence.

If your site has a complex menu, our website navigation best practices guide covers navigation structure in more depth.

7. Keep Focus Indicators Visible

Keyboard users need to know which element currently has focus.

Do not remove the browser focus outline unless you replace it with something equally or more visible.

Focus indicators should remain distinguishable against different backgrounds and states. A sticky header, cookie banner, modal, or floating widget should not cover the focused element.

WCAG 2.2 added specific requirements around focus not being obscured, making this especially important for sites with sticky interface elements.

8. Provide a Skip Link

A “Skip to main content” link lets keyboard and screen-reader users bypass repeated navigation and move directly to the main page content.

The link can remain visually hidden until it receives keyboard focus, but it must work reliably.

This is especially useful on sites with large headers, mega menus, utility navigation, or many repeated links before the main content.

9. Use Descriptive Link and Button Labels

Users should understand what a link or button does from its text and relevant context.

Prefer:

• “View web design services”
• “Download the accessibility checklist”
• “Read the pricing guide”

over vague labels such as:

• “Click here”
• “Learn more”
• “Read more”

Repeated “Learn more” buttons can become difficult to understand when a screen reader presents links as a list without all the surrounding visual context.

10. Make Touch and Pointer Targets Large Enough

WCAG 2.2’s Target Size (Minimum) criterion sets a Level AA minimum of 24 by 24 CSS pixels for pointer targets, with defined exceptions and a spacing alternative for undersized targets.

In practice, important buttons and controls can often be larger than the minimum.

Check:

• menu icons
• carousel arrows
• close buttons
• pagination
• social icons
• checkboxes
• radio controls
• filter chips
• small text links placed close together

This matters on mobile but also helps users with tremors or limited fine-motor control.

For layout and touch behavior across devices, see our responsive web design best practices and mobile-first web design guide.

11. Label Every Form Field

Every form control needs an accessible name.

Visible labels are usually the clearest option. Do not rely only on placeholder text because placeholders can disappear as users type and often have poor contrast.

Make required fields clear, explain expected formats where needed, and group related controls logically.

Examples include:

• Name
• Email address
• Phone number
• Company size
• Preferred service
• Billing address

A label should remain associated with its control programmatically, not just visually positioned nearby.

12. Make Form Errors Specific and Recoverable

“Something went wrong” is rarely enough.

If a submission fails, identify the field with the problem and explain how the user can fix it.

For example:

“Enter an email address in the format name@example.com.”

is more useful than:

“Invalid input.”

Do not clear correct values when one field has an error. Keep error messages close to the relevant field, make them programmatically available to assistive technology, and provide an error summary when a long form benefits from one.

13. Do Not Create Keyboard Traps

Users must be able to move keyboard focus into and out of components.

Modals are a special case: while a modal is open, focus may need to stay within it, but users should have an obvious keyboard-operable way to close it and focus should return to a sensible place afterward.

Common trap risks include:

• chat widgets
• embedded maps
• custom select menus
• carousels
• third-party booking tools
• cookie-consent overlays

Test them instead of assuming the plugin or library handles accessibility correctly.

14. Let Users Resize Text to 200%

WCAG requires most text to remain usable when resized up to 200% without losing content or functionality.

Avoid fixed-height containers that cut off enlarged text. Do not disable browser zoom on mobile.

Buttons, navigation, cards, headings, notices, and form fields should accommodate larger text without overlapping or disappearing.

15. Support Reflow at Narrow Widths

At approximately 320 CSS pixels wide, most content should reflow into a readable layout without requiring horizontal scrolling for ordinary reading.

Exceptions exist for content that genuinely needs two-dimensional layout, such as certain data tables, maps, or diagrams.

Check pages at narrow widths and high zoom. Problems often appear in:

• pricing tables
• long URLs
• code blocks
• fixed-width cards
• popups
• cookie banners
• navigation menus
• embedded forms

16. Use Accessible Navigation Patterns

Main navigation should remain consistent across pages. Dropdowns should work with keyboard input, have clear expanded/collapsed states, and not depend only on hover.

Mobile menus need similar care. When a drawer is closed, hidden menu items should not remain keyboard-focusable.

Breadcrumbs can help users understand location on deep sites when they are marked up clearly.

If your homepage introduces the site’s primary routes, our homepage design best practices guide explains how navigation, messaging, proof, and calls to action work together.

17. Add Captions and Alternatives for Media

Prerecorded video containing speech should provide synchronized captions when required by WCAG.

Captions help Deaf and hard-of-hearing users, but they are also useful when people watch video without sound.

Depending on the media and accessibility target, you may also need:

• transcripts
• audio descriptions
• alternatives for audio-only content
• accessible media-player controls

Do not autoplay audio unexpectedly. If media starts automatically, users need appropriate control.

18. Respect Reduced-Motion Preferences

Parallax, animated backgrounds, scrolling effects, auto-moving carousels, and large transitions can cause discomfort or make interfaces harder to use.

Use the prefers-reduced-motion media query to reduce or remove nonessential movement for users who request it.

Also make sure important information does not depend on animation to become understandable.

Avoid content that flashes in ways that can trigger seizures.

19. Make Tables Accessible

Use tables for tabular data, not for general page layout.

Provide header cells for rows and columns where needed, keep relationships understandable, and add a caption when it helps users understand the table’s purpose.

On mobile, do not solve wide-table problems by simply shrinking the text until it becomes unreadable. Consider horizontal scrolling for the table container, simplified views, or alternative presentation where appropriate.

20. Use Automated Accessibility Testing, But Do Not Stop There

Automated scanners are useful for finding issues such as:

• missing alt attributes
• some contrast failures
• missing labels
• duplicate IDs
• certain ARIA errors
• structural problems

But automation cannot decide whether your alt text is useful, whether a focus order makes sense, whether instructions are understandable, or whether a workflow is genuinely usable.

Treat automated testing as one layer, not a complete accessibility audit. Google’s Learn Accessibility resource likewise separates automated, manual, and assistive-technology testing.

21. Test Manually With Keyboard, Zoom, and a Screen Reader

Before launch, perform at least these manual checks:

1. Navigate the entire page using only the keyboard.
2. Confirm focus is visible and follows a logical order.
3. Zoom text and the page to 200%.
4. Test a narrow viewport around 320 CSS pixels.
5. Submit every form with valid and invalid data.
6. Check mobile menus, modals, dropdowns, and accordions.
7. Test at least one common screen reader such as NVDA, VoiceOver, or TalkBack.
8. Check important flows on a real touch device.

Manual testing often catches practical failures that automated tools miss.

22. Recheck Accessibility After Every Major Site Change

Accessibility can regress.

A new plugin, navigation redesign, cookie banner, form, popup, page-builder component, checkout flow, or marketing script can introduce problems even if the site previously tested well.

Include accessibility in your normal QA process rather than treating it as a one-time project.

If you are maintaining a growing business site, our small business web design guide explains how accessibility fits alongside lead generation, performance, trust, and ongoing website maintenance.

Quick Website Accessibility Audit Checklist

Run through this shorter list before publishing a new template or major page:

• ☐ The page has one clear main heading and logical subheadings.
• ☐ Semantic HTML is used for links, buttons, lists, landmarks, and forms.
• ☐ Meaningful images have appropriate alt text.
• ☐ Decorative images do not create unnecessary screen-reader noise.
• ☐ Normal text meets 4.5:1 contrast and large text meets 3:1 where WCAG applies.
• ☐ Important controls and graphics have sufficient contrast.
• ☐ Information is not communicated by color alone.
• ☐ All interactions work with keyboard input.
• ☐ Focus is clearly visible and not hidden by sticky elements.
• ☐ A skip link lets users bypass repeated navigation.
• ☐ Link and button labels describe their purpose.
• ☐ Pointer targets meet minimum sizing or spacing requirements.
• ☐ Forms have persistent labels and clear instructions.
• ☐ Errors identify the problem and explain how to correct it.
• ☐ Text can be resized to 200% without losing content.
• ☐ The page reflows at narrow widths without unnecessary horizontal scrolling.
• ☐ Mobile and desktop layouts keep a logical source order.
• ☐ Video and audio include required alternatives.
• ☐ Motion respects reduced-motion preferences.
• ☐ Tables use proper headers and remain usable on small screens.
• ☐ Dynamic status messages are exposed appropriately.
• ☐ Automated and manual accessibility tests have both been completed.

Accessibility Mistakes to Avoid

Several shortcuts create recurring accessibility problems.

Do not remove focus outlines just because they do not match the visual design. Style them better instead.

Do not assume a page-builder widget, WordPress plugin, theme, or third-party embed is accessible because it looks professional. Test the output.

Do not use ARIA as a way to repair incorrect HTML without understanding the component’s expected behavior.

Do not hide important content from mobile users purely to make the page shorter. Mobile and desktop visitors should still have access to equivalent essential information.

Do not treat an automated “100 accessibility score” as proof that the complete user experience is accessible.

And do not wait until launch day to check accessibility. Fixing the underlying design system is usually easier than correcting dozens of pages one by one later.

Frequently Asked Questions