How to Test Your Website for Accessibility (A Step-by-Step Guide)

An accessible website works for everyone, including people who navigate with keyboards, use screen readers, or need higher contrast to read text. But how do you know if your website actually meets WCAG 2.1 accessibility standards? The answer is testing, and it takes more than a single automated scan.

In this accessibility testing guide, we walk through seven practical steps to test website accessibility. You will learn how to combine automated tools with hands-on manual testing to catch the widest range of issues. Whether you are running your first audit or building accessibility into your workflow, these steps give you a clear process to follow.

Step 1: Run an Automated Scan

Automated accessibility testing tools are the fastest way to identify common WCAG violations. They parse your HTML, check for missing attributes, evaluate color contrast, and flag dozens of known failure patterns. However, automated tools typically catch only 30 to 50 percent of accessibility issues. They are excellent at detecting missing alt text, form labels, and ARIA misuse, but they cannot judge whether alt text is meaningful or whether a custom widget is actually usable.

Start with one of these widely used tools:

• axe-core — An open-source accessibility engine that integrates into browsers and CI pipelines. Install the axe DevTools browser extension to scan any page in seconds.
• Google Lighthouse — Built into Chrome DevTools under the Audits tab. Run an accessibility audit alongside performance and SEO checks.
• WAVE — A web-based evaluation tool from WebAIM that provides a visual overlay of issues directly on your page.
• WCAG Repair — A free online scanner at wcagrepair.com that not only identifies WCAG violations but also generates specific fix guides for each issue, making it a practical starting point for your first audit.

Run your scan, export the results, and use them as a checklist. But do not stop here. The steps that follow catch what automated tools miss.

Step 2: Test Keyboard Navigation

Many users navigate entirely with a keyboard due to motor impairments, repetitive strain injuries, or personal preference. Keyboard accessibility is a core WCAG requirement, and testing it requires no special tools — just your keyboard.

What to Do

1. Click into the browser address bar, then press Tab to start moving through the page.
2. Use Shift+Tab to move backward.
3. Press Enter to activate links and buttons.
4. Press Space to toggle checkboxes and activate buttons.
5. Use Arrow keys to navigate within menus, radio groups, tabs, and other composite widgets.
6. Press Escape to close modals and dropdown menus.

What to Look For

• Visible focus indicators — Can you always see which element is focused? A missing or invisible focus ring is a WCAG 2.4.7 violation.
• Logical tab order — Does focus move through the page in a meaningful sequence? It should generally follow the visual reading order.
• Keyboard traps — Can you Tab into and out of every component? If focus gets stuck inside a widget with no way to leave, that is a WCAG 2.1.2 failure.
• Interactive elements reachable — Every link, button, form field, and custom control must be operable with the keyboard alone.

Step 3: Check Color Contrast

Insufficient color contrast is one of the most common accessibility failures on the web. Users with low vision, color blindness, or those reading screens in bright sunlight all depend on adequate contrast.

Minimum Contrast Ratios (WCAG 2.1 Level AA)

• Normal text (under 18pt or 14pt bold): 4.5:1 contrast ratio
• Large text (18pt+ or 14pt+ bold): 3:1 contrast ratio
• UI components and graphical objects: 3:1 contrast ratio

How to Test

• WebAIM Contrast Checker — Enter your foreground and background colors at webaim.org/resources/contrastchecker to see the exact ratio.
• Browser DevTools — In Chrome, inspect any text element and the color picker displays the contrast ratio with a pass/fail indicator.
• Automated scanners — Tools like axe-core and WCAG Repair flag contrast failures automatically, but always verify edge cases manually (text over images, gradients, hover states).

Common Failures

• Light gray text on white backgrounds
• Placeholder text in form fields with insufficient contrast
• Links that rely only on color to distinguish them from surrounding text
• Disabled button text that is unreadable

Step 4: Test with a Screen Reader

Screen reader testing reveals issues that no automated tool can detect: confusing reading order, vague link text, unlabeled icons, and widgets that do not announce their state. Even a brief test gives you valuable insight into how assistive technology users experience your site.

Free Screen Reader Options

• NVDA — Free, open-source screen reader for Windows. Download from nvaccess.org.
• VoiceOver — Built into macOS and iOS. Activate on Mac with Cmd+F5.
• TalkBack — Built into Android. Enable in Settings > Accessibility.

Basic NVDA/VoiceOver Commands

• Navigate by heading: Press H (NVDA) or VO+Cmd+H (VoiceOver) to jump between headings.
• List all links: Press Insert+F7 (NVDA) to open a list of page links.
• Navigate forms: Press F to jump to the next form field.
• Read continuously: Press Insert+Down Arrow (NVDA) or VO+A (VoiceOver).

What to Listen For

• Headings — Are they announced with correct levels? Can you navigate the page by headings alone?
• Link text — Do links make sense out of context? "Click here" and "Read more" are not descriptive.
• Form labels — When you focus on an input field, does the screen reader announce what it is for?
• Image descriptions — Are meaningful images described? Are decorative images skipped?
• Dynamic content — When content updates (alerts, form errors, live regions), does the screen reader announce the change?

Step 5: Check Zoom and Reflow

WCAG 1.4.4 requires that text can be resized up to 200 percent without loss of content or functionality. WCAG 1.4.10 (Reflow) requires content to work at 320 CSS pixels wide without horizontal scrolling.

How to Test

1. Set your browser zoom to 200% (Ctrl+= or Cmd+=). Navigate the entire site. Verify that no content is clipped, overlapping, or hidden.
2. Set zoom to 400% to test reflow behavior. Content should reflow into a single column without requiring horizontal scrolling (except for data tables, maps, and similar content that requires two-dimensional layout).
3. Test text spacing — Use a browser extension or custom CSS to increase letter spacing to 0.12em, word spacing to 0.16em, and line height to 1.5. No content should be lost or overlap.

/* Text spacing test overrides (WCAG 1.4.12) */
* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p {
  margin-bottom: 2em !important;
}

If your layout breaks at 200% zoom or text gets cut off by fixed-height containers, those are failures that need to be addressed.

Step 6: Review Your HTML Structure

Solid HTML structure is the foundation of accessibility. Screen readers use headings, landmarks, and semantic markup to help users understand and navigate pages.

What to Check

• Heading hierarchy — Headings should follow a logical order without skipping levels. Every page should have one <h1>, and subheadings should use <h2>, <h3>, and so on in sequence.

<!-- Bad: Skips from h1 to h4 -->
<h1>Products</h1>
<h4>Featured Items</h4>

<!-- Good: Logical heading order -->
<h1>Products</h1>
<h2>Featured Items</h2>

• Landmark regions — Use <header>, <nav>, <main>, and <footer> so screen reader users can jump directly to page sections.
• Lists — Groups of related items (navigation links, feature lists) should use <ul>, <ol>, or <dl> rather than styled <div> elements.
• Language attribute — Your <html> element must include a lang attribute (e.g., lang="en") so screen readers use the correct pronunciation.

Step 7: Test Forms and Error Handling

Forms are one of the most critical areas for accessibility. Users must be able to understand what each field requires, receive clear error messages, and correct mistakes without confusion.

What to Check

• Labels — Every input needs a programmatically associated label using the <label> element with a matching for attribute, or using aria-label / aria-labelledby.

<!-- Good: Associated label -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" required>

• Required fields — Indicate required fields both visually (asterisk or text) and programmatically (required attribute or aria-required="true").
• Error messages — When validation fails, errors should be specific ("Please enter a valid email address" rather than "Invalid input"), associated with the relevant field using aria-describedby, and announced to screen readers using a live region or by moving focus to the error summary.
• Focus management — After a form submission error, move focus to either the error summary at the top of the form or the first field with an error. Do not leave the user stranded at the submit button wondering what went wrong.

Putting It All Together

No single testing method catches every accessibility issue. Automated scans are fast and repeatable. Keyboard and screen reader testing catch interaction problems that machines miss. Together, they form a thorough accessibility testing process.

Build a regular testing cadence into your workflow:

• During development — Run automated scans and keyboard tests on every new feature or component.
• Before launch — Conduct a full manual audit covering all seven steps above.
• Ongoing — Schedule quarterly accessibility reviews to catch regressions and address new content.

The most important thing is to start. Even a basic automated scan followed by a few minutes of keyboard testing will reveal issues you can fix today.

Start with a Free Scan

If you are looking for a quick starting point, run a free accessibility scan at wcagrepair.com. WCAG Repair identifies WCAG 2.1 violations on your site and generates actionable fix guides for each issue, so you know exactly what to change and why. Pair it with the manual testing steps in this guide, and you will have a solid foundation for making your website accessible to everyone.