A Practical, Phased Approach to Test Your Website for Accessibility

Getting a website to 100% WCAG 2.2 AA compliance is a significant undertaking. But that doesn’t mean you should throw your hands up and do nothing. The key is approaching accessibility testing systematically, in phases that build on each other.

In this guide, I’ll walk you through exactly how we audit websites for accessibility broken down into manageable testing phases. By the end, you’ll know what to check, how to check it, and what tools can help you catch issues before your users (or their lawyers) do.

Why Test in Phases?

Think of accessibility testing like a filter. Each phase catches different types of issues:

• Automated tools catch the low-hanging fruit: missing alt text, contrast problems, HTML errors.
• Manual testing reveals issues that require human judgment: confusing navigation, illogical focus order, ambiguous link text.
• Assistive technology testing shows you what screen reader users actually experience.
• Real user testing uncovers barriers that other checks could miss entirely.

This can feel overwhelming from so many different possible scenarios but the key is to work smart. Start with automated scans that take minutes, then invest time in manual testing where it matters most. This phased approach means you’ll catch the majority of issues efficiently while still being thorough where it counts.

Phase 1: Automated Testing (The 30-Minute Foundation)

Automated tools are your first line of defense but they’ll never catch everything. Studies show they identify only about 30% of accessibility issues but they’ll catch that 30% fast. Think of this as your foundation audit.

Automated tools do a great job of checking basic criteria.

• Missing or empty alt attributes on images
• Color contrast ratios
• Missing form labels
• Improper heading hierarchy
• Missing page language attributes
• HTML validation errors
• ARIA misuse

Our go-to automated testing workflow:

Step 1: Run a browser extension scan

We start with axe DevTools, WAVE, and ANDI. All are free and give you instant feedback:

• Install the extension for WAVE and axe DevTools in your browser, add a bookmark for ANDI (https://www.ssa.gov/accessibility/andi/help/install.html)
• Navigate to your page
• Click the axeDev or WAVE extension icon or the ANDI Bookmark
• Review flagged errors, alerts, and warnings

Pay special attention to anything marked as an “error” as these are violations that will definitely impact users. Warnings and alerts require your judgment.

Step 2: Check color contrast systematically

Even if your automated tool checks contrast, we recommend a dedicated contrast check because it’s such a common issue:

• Use a tool like WebAIM’s contrast checker (built into WAVE) or Colour Contrast Analyzer (a desktop tool)
• Test body text, button text, link text, and any text overlaid on images
• Remember the thresholds: 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold)
• Don’t forget non-text elements like icon buttons and focus indicators: they need 3:1 against adjacent colors

Step 3: Validate your HTML

Broken HTML can wreak havoc on assistive technology. Run your pages through the W3C Markup Validator:

• Go to validator.w3.org
• Enter your URL or paste your HTML
• Fix any errors, especially duplicate IDs, unclosed tags, and improper nesting

Tools I recommend for Phase 1

• WAVE browser extension: provides visual feedback directly on your page
• axe DevTools: detailed reports with remediation guidance
• ANDI: displays accessibility tree and focusable element analysis
• W3C Markup Validator: HTML validation

Time investment: 15-30 minutes per page, depending on complexity.

What you’ll catch: typically 30% of issues, mostly code-level problems.

Phase 2: Manual Testing (Where Human Judgment Matters)

This is where you roll up your sleeves and actually interact with your site the way users with disabilities would. Manual testing takes more time than running automated scans, but it’s where you’ll find the issues that matter most to real-world usability.

Keyboard Navigation Testing

Many users can’t use a mouse, instead they navigate entirely with a keyboard due to motor disabilities, blindness, or personal preference. If your site isn’t fully keyboard accessible, you’re locking these users out. This is by far the most egregious and common barrier we find on websites.

Basic keyboard access

• Hit Tab to move forward through interactive elements (links, buttons, form fields)
• Use Shift + Tab to move backward
• Press Enter to activate links and buttons
• Use the spacebar to activate buttons and toggle checkboxes
• Test arrow keys in custom widgets like sliders, tabs, and dropdown menus

Every interactive element should be reachable and operable without a mouse. No exceptions!

Focus indicators

• As you Tab through the page, can you always see where you are?
• Is the focus indicator clear and obvious (not a faint 1px outline)?
• Does the focus indicator meet contrast requirements (3:1 against adjacent colors)?
• Do any elements hide the focus indicator with CSS?

We see sites all the time with “outline: none” in the CSS and no replacement focus style. That’s a deal-breaker.

Focus order

• Does the focus order follow the visual reading order (top to bottom, left to right)?
• Do hidden elements receive focus? (They shouldn’t)
• When a modal or menu opens, does focus move into it?
• Can you navigate logically through complex layouts like multi-column designs?

Focus order issues often crop up when developers use CSS to reorder visual content without adjusting the HTML source order, for example using “order:1” and “order:2” Your Tab order should make sense, not jump around randomly.

Keyboard traps

• Can you Tab into and out of every component?
• Do modals, menus, or embedded widgets trap your focus? (They should)
• Can you close pop-ups and menus with the Escape key? Does focus return to the original button when it closes? (It should)

Mobile menu trapping is incredibly common. The menu opens, you can Tab through menu items, but then focus escapes to the page behind the menu instead of cycling back through menu items. That needs fixing.

Another common issue we encounter with menus (mobile and desktop) is focus cycling through hidden submenus. That also needs fixing.

Menu navigation behaviors

• Does your main navigation respond properly to keyboard input?
• Can users access submenus with Enter or arrow keys (not just on hover)?
• Does Escape close open submenus?
• Is there a skip link to bypass navigation and jump to main content?

Test your mobile menu separately to make sure users can open it, navigate through it, and close it entirely with the keyboard. If the mobile menu overlay is active, background content shouldn’t be focusable. Hidden submenus also shouldn’t be focusable.

Heading and Document Structure

Screen reader users rely on headings to understand page structure and navigate efficiently. They’ll pull up a heading list and jump directly to the section they need if your headings are set up correctly.

What to test:

• Is there exactly one H1 per page (usually your main page title)?
• Do heading levels follow a logical hierarchy (H1 → H2 → H3, not H1 → H4)?
• Are headings used for structure, not just styling? (Don’t make something an H3 just because you like how it looks.)
• Do your headings accurately describe the content that follows?

Run the ANDI bookmark and select “structures” to pull up the outline view. Does it make sense? Could someone understand your page structure from the headings alone?

Forms and Input Fields

Forms are high-stakes territory. If users can’t complete your contact form, checkout flow, or newsletter signup, you’re losing conversions and potentially facing complaints.

Labels and instructions

• Does every input have a visible, properly associated label?
• Are instructions provided before the field (not just as placeholder text that disappears)?
• Is required field information conveyed both visually and programmatically?

Error handling

• When validation fails, are error messages clear and specific?
• Is focus moved to the first field with an error, or is an error summary provided?
• Are errors announced to screen readers (using ARIA live regions or proper associations)?
• Can users understand what went wrong and how to fix it?

Grouping and relationships

• Are related fields grouped (like buttons, radio buttons, or checkboxes)?
• Is the group relationship announced to screen readers (using fieldset and legend)?
• Do multi-part fields like dates or phone numbers have clear instructions?

Test your forms by actually filling them out and intentionally triggering validation errors to see how they’re handled.

Links and Buttons

This seems simple, but we find issues here on almost every site we audit.

• Is link text descriptive out of context? (Avoid “click here,” “read more,” “learn more” without additional context)
• Are links and buttons semantically correct? (Links go places, buttons do things on the same page)
• Can you tell what will happen when you activate a link or button?
• Are there any empty links or buttons (visible on screen but no accessible name)?

Read your links in isolation. If someone heard “learn more, link” spoken by a screen reader, would they know where that link goes? If not, it needs more context.

Images and Alternative Text

Automated tools catch missing alt attributes. You need to check whether the alt text is actually good.

• Does the image add contextual value to the page or is it merely decorative. Learn the difference between decorative vs meaningful Images.
• Is the alt text concise but descriptive?
• Does the alt text convey the meaning or function of the image, not just a literal description?
• Are decorative images marked with empty alt (alt=””) or aria-hidden=true?
• Do complex images like charts and infographics have longer descriptions?
• Are images of text avoided? (If not, is the text included in alt text?)

Open your site with images disabled (in your browser settings) or with a screen reader and listen to the alt text. Does it make sense? Is it truly needed because it adds context to the page content? Does it convey what sighted users see?

Reading Order vs. Visual Order

CSS lets us make content appear in any visual order, but assistive technology reads the DOM in source order. If these don’t match, it’s confusing.

• Turn off CSS (use the Web Developer extension to disable styles)
• Does the content still make logical sense in the order it appears?
• Compare the unstyled order to the visual layout – is anything wildly out of sequence?

This particularly matters for complex layouts with sidebars, cards, or multi-column designs. Your reading order should be logical even if it doesn’t match the visual layout exactly.

Time Limits and Animations

Users with cognitive or motor disabilities may need more time to complete tasks or may be distracted or triggered by motion.

• Are there any auto-advancing carousels, slideshows, or videos that autoplay? Can users pause them?
• Do any forms have time limits? Can users extend the time?
• Is there excessive animation or parallax scrolling? Can users reduce or disable it?
• Does your site respect the “prefers-reduced-motion” setting?

Navigate to chrome://settings/accessibility (or your browser’s equivalent) and enable “prefers reduced motion,” then check if your animations scale back appropriately.

Time investment: 1-2 hours per template/page type per device (you don’t need to test every single page, just each unique layout).

What you’ll catch: issues that require human judgment (focus order problems, unclear link text, poor alt text, keyboard traps, form usability).

Phase 3: Screen Reader Testing (See What Users Actually Experience)

Here’s where it gets real. You can pass every automated test and every manual check, but if your site sounds confusing or broken to a screen reader user, you’ve still got work to do. Screen reader testing is honestly the most valuable thing you can do after the basics are covered. It’s also the most intimidating for people who’ve never done it.

Getting started with screen readers

You don’t need to be an expert screen reader user to catch most issues. You just need to learn enough to navigate a page and hear what gets announced.

Which screen reader should you use?

• NVDA (Windows): free, widely used, good for testing. Download at nvaccess.org
• JAWS (Windows): most popular among professional users, but expensive. Offers a demo mode.
• VoiceOver (Mac/iOS): built in, free, used for testing on Apple devices (Macs and iOS).
• TalkBack (Android): built in, free, used for mobile testing on Android devices.

Start with whatever’s available on your system. NVDA on Windows or VoiceOver on Mac are great starting points. When we first got started, covering the monitor was helpful so we couldn’t “cheat.”

What to test:

Basic navigation

• Turn on your screen reader and navigate the page using headings (H key in NVDA, Control+Option+Command+H in VoiceOver)
• Can you jump between landmarks (D key in NVDA, Control+Option+U then left arrow to Landmarks in VoiceOver)?
• Is content announced in a logical order?

Interactive elements

• Tab through forms: are labels, instructions, and errors announced clearly?
• Activate links and buttons: is the purpose clear from what’s announced?
• Navigate through menus: does the expanded/collapsed state get announced?

Images and media

• Navigate through images: is alt text announced?
• Are decorative images silent?
• Are videos described adequately?

Dynamic content

Trigger a modal or notification: is it announced to the screen reader?
Submit a form with errors: is the error message announced?
Filter or sort content: are updates communicated?

What to listen for:

• Confusing or missing context
• Elements announced out of order
• Interactive elements not identified as clickable
• Changes to the page that aren’t announced (for example, menu expanded, menu collapsed)
• Excessive verbosity (too much announced) or silence (not enough announced)

You don’t need to memorize every keyboard shortcut. Just learn enough to navigate by headings, tab through interactive elements, and trigger your forms and menus. You’ll catch 80% of screen reader issues with those basics.

Time investment: 30-60 minutes per page type, longer as you’re learning.

What you’ll catch: real-world usability issues for screen reader users, confusing announcements, missing context, poor ARIA implementation.

Phase 4: Mobile and Touch Accessibility

More than half of web traffic is mobile these days, yet mobile accessibility often gets overlooked until late in the process. Don’t make that mistake. Here’s what to test on mobile devices.

Touch target size and spacing

• Are buttons, links, and other interactive elements at least 44×44 pixels?
• Is there enough space between tap targets to prevent accidental activation?
• Can users with limited dexterity accurately hit targets?

Pull out your phone and actually try tapping small buttons or links. If you miss and hit the wrong thing, it’s too small or too close to other elements.

Responsive design and zoom

• Does your layout adapt cleanly to smaller screens?
• Can users zoom in to at least 200% without content getting cut off or requiring horizontal scrolling?
• Does content get cut off or require horizontal scrolling on 320px screen size?
• Is text readable without zooming?

Mobile-specific interactions

• Does your mobile menu open and close reliably?
• Can screen reader users navigate your mobile menu (test with VoiceOver on iOS or TalkBack on Android)?
• Are gestures like swipe discoverable or do you provide alternatives?

Form input on mobile

• Are input types set correctly (email, tel, number) so the right keyboard appears?
• Are autocomplete attributes used to help users fill forms faster?
• Are error messages visible without being hidden by the on-screen keyboard?

Mobile menu trapping (this is huge)

• Open your mobile menu
• Turn on VoiceOver (iOS) or TalkBack (Android)
• Try navigating through the menu
• Can you escape the menu and return to it logically?
• Does focus get trapped in the menu while it’s open, or does it escape to background content?

Mobile menu focus management is one of the most common accessibility fails we see. When the menu is open, focus should stay within the menu. When it’s closed, focus should return to the menu button.

Time investment: 30-45 minutes per template on actual devices.

What you’ll catch: touch target issues, mobile-specific navigation problems, zoom and responsive design issues, mobile form problems.

Phase 5: Real User Testing (The Gold Standard)

No amount of technical testing replaces feedback from actual users with disabilities. If you have the resources, include user testing in your process.

Who to include:

• Screen reader users (blind or low vision)
• Keyboard-only users (motor disabilities)
• Users with cognitive disabilities
• Users who are deaf or hard of hearing (for video content)
• Users who have International Association of Accessibility Professionals certification (most reliable for catching 100% of WCAG 2.1/2.2 AA barriers which is a requirement when compliance is legally mandated)

What to test:

• Can they complete key tasks (find information, fill out forms, make purchases)?
• What’s confusing or frustrating?
• Where do they get stuck?

User testing doesn’t have to be elaborate. Even 1-3 users can reveal critical issues you’d never catch with technical testing alone.

Time investment: varies widely depending on scope.

What you’ll catch: real usability barriers, confusing flows, issues that technical compliance misses.

Bringing It All Together

Recommend approach for a first-time audit:

1. Run automated tests on every template (Phase 1)
2. Fix all automated errors before moving forward
3. Manually test each unique template and component/module/widget (Phase 2)
4. Test high-priority pages with a screen reader (Phase 3)
5. Test on mobile devices (Phase 4)
6. Conduct user testing if possible (Phase 5)
7. Fix all barriers starting with the most severe

For ongoing maintenance:

• Automated testing on every new page or component before publishing
• Ongoing, automated testing using a third party service that runs weekly/monthly, lists barriers in order of severity with suggested remediation approach, PDF reports for Board Members and Legal teams, and weekly/monthly emails with status
• Manual audits (yearly or when making major changes)
• Screen reader spot-checks on new pages or components
• Mobile testing on new new pages or components

For quick triage (you have limited time):

• Automated scan (Phase 1) – 30 minutes
• Keyboard navigation test (Phase 2) – 30 minutes per device
• Screen reader test of critical pages (Phase 3) – 60 minutes per page per device

That 120-minute audit won’t catch everything, but it’ll catch the most critical issues affecting the most users.

The Bottom Line

Website accessibility testing doesn’t have to be overwhelming. By breaking it into phases you can systematically catch issues without drowning in details.

Start with automated scans to knock out the easy wins. Invest time in manual testing where human judgment matters. Test with assistive technology to hear what users actually experience. Check your mobile experience on real devices. And if you can, get feedback from users with disabilities.

Is this comprehensive? Yes. Will it take time? Absolutely. But here’s the thing – you don’t have to do it all at once and you don’t have to do it alone.

If you’ve read this far and you’re thinking “this is exactly what I need to do, but I don’t have the time,” that’s completely fair. Accessibility testing and remediation is what we do at All Terrain Studios. If you’d rather focus on running your business while someone else handles the accessibility audit, let’s talk.

And if you’re ready to dig in yourself, you’ve now got a roadmap. Start with Phase 1 automated testing this week, move to Phase 2 manual testing next week, and build from there.

Your users will thank you, not to mention your SEO rankings will improve.