Manual Accessibility Testing: How You Can Check Website Accessibility

Why Manual Accessibility Testing is Necessary

Accessibility Checker is an excellent tool for identifying many of the most common accessibility problems on websites and those that can be identified via automated code review or AI. It is important to note, though, that not all accessibility problems can be identified automatically.

By some estimates, only 30-50% of accessibility problems can be automatically identified (or corrected). This is why Equalize Digital and other accessibility consultants say accessibility overlay tools and plugins don’t work. It’s also why our plugin uses the phrase “100% passed tests” instead of “100% accessible” when auditing your WordPress posts and pages.

Web Content Accessibility Guidelines (WCAG) on Manual Testing

WCAG 2.1 AA is the standard that most websites need to follow under website accessibility laws around the world. This is generally considered the bare minimum standard for meeting business/private website accessibility requirements. The current version of WCAG is 2.2, which was released in fall 2023.

WCAG 2.0 AA contains 38 “success criteria” or items that need to be achieved to ensure accessibility. 34 of the success criteria require manual review by a human. WCAG 2.1 AA added 12 new success criteria that also require manual review, and WCAG 2.2 added 9 success criteria that can only be assessed by a human.

Manual Testing is needed for legal compliance.

If you want to ensure true WCAG conformance or compliance with laws like Section 508, the Americans with Disabilities Act (ADA), the Accessibility for Ontarians with Disabilities Act (AODA), the European Accessibility Act, or any other website accessibility laws around the world, you need to do two things:

1. Check your website with an automated accessibility testing tool like Accessibility Checker.
2. Manually check your website for accessibility with keyboards, screen readers, and with magnification.

Then, you need to fix all problems identified through your tests.

What is Manual Accessibility Testing?

Manual accessibility testing is the review process a human goes through to determine if any accessibility problems exist on a website. Examples of manual accessibility testing include:

• Navigating through the website with only a keyboard to ensure that all content can be accessed, used, and engaged with by a user who cannot use a mouse.
• Listen to the website with a screen reader to ensure that text content and controls can be accessed by a screen reader and are understandable when read aloud.
• Watching embedded media to check for the presence and accuracy of closed captions and that no rapid flashing is present.
• Using the website on multiple device sizes and at multiple resolutions to ensure that it is just as easy to use on a phone as on a desktop computer and can be used if significantly zoomed in.
• Checking that the website respects motion sensitivities by looking for buttons to pause or stop auto-playing videos or carousels and other animations, and that any CSS animations don’t play animations if the users has turned on prefers reduced motion in their operating system.

Manual accessibility testing vs. user testing

Manual accessibility testing is different from user testing. When you perform user testing on your website, the users are doing manual tests; however, the users participating in user testing sessions are not typically looking at every web page exhaustively. Rather, they are attempting to accomplish certain goals that you have laid out for them in the testing brief.

As part of our accessibility audit and remediation process, we recommend completing automated and manual accessibility testing in tandem – then resolving all issues (in multiple rounds, as needed) – before performing user testing. We like to use user testing sessions to prove accessibility and only weed out a few small remaining issues. In our process, we conduct user testing once we believe the website is fully accessible and after all of our manual testing is complete.

How to Test Website Accessibility Manually

1. Create a plan

If your website is already live and you’re trying to identify accessibility problems that need to be fixed, your approach to manual accessibility testing will likely be different than if you’re testing a newly developed but not yet launched website.

If your website is not yet live, you can move through the content from the home page to interior pages in whatever order makes sense to you.

If your website is currently live, then we recommend testing interior pages in this order:

1. Test the page on your website that receives the most traffic (check Google Analytics or whichever tracking software you’re using).
2. Test pages where a conversion is expected to happen or that impact your bottom line. This includes product pages, cart and checkout pages, pages with forms, ad landing pages, or pages where people need to go to find your phone number.
3. Test your home page.
4. Test one representative page from each post type on your website (i.e., one staff bio page, one event calendar page, one blog post) and the archive page for any of these post types.
5. Continue testing through the rest of your content in order of most to least traffic received until you have tested every public URL on your website.

2. Start by testing keyboard navigation

The first place we like to start when performing manual accessibility tests is with keyboard navigation.

Not all people who visit your website will be able to use a mouse and, as a result, these people will be using a keyboard only to navigate the web.

This includes blind and visually impaired users who cannot see and will be using a keyboard in combination with a screen reader and sighted people who can see but are unable to use a mouse because of motor impairments or injuries. This latter group could include people with quadriplegia, people who have ALS (amyotrophic lateral sclerosis) like Stephen Hawking, veterans or others who have lost their arms, and the elderly. Some non-disabled users also prefer to use their keyboard only to move through websites or complete certain tasks, such as filling in forms.

Your first round of keyboard testing will benefit keyboard users who are sighted.

To keyboard test your website, load the page you want to test in any browser and then use only the keyboard (typically the tab key and arrows) to move through every page and interact with every feature. You want to make sure that everything you can do on your website with a mouse can also be done with a keyboard only.

Things to ask yourself when keyboard testing your website:

• Can you always see the focus and where you currently are on the page or do you easily lose track of where your focus is? Every link or button should have an obvious outline or color change when you tab to it.
• Do the colors for focus states meet contrast ratios?
• Can you move to different pages using the navigation menu?
• Can you quickly jump to content without having to tab through the navigation menu? (I.e., are there skip links present on your website?)
• If a popup opens can you close it? Is your focus locked into the popup until you engage with it or close it, or can you tab out of the popup without closing it?
• Can you interact with any special features like maps, sliders, and video or audio players?
• If you interact with a feature or close a popup does your focus shift unexpectedly?
• Can you fill out and submit forms?
• Can you complete a purchase or do any other actions you want your visitors to take?

3. Test your website with screen readers

As noted above, people who are blind or visually impaired will navigate your website and interact with it using a screen reader. After performing keyboard tests to check your website for a visible focus state and to ensure everything can be interacted with as expected, the next step is to test your website with at least one screen reader.

Which screen reader to use

There are three common screen readers that you can choose from for testing:

• VoiceOver: If you have a Mac, VoiceOver is built into your computer and is a great place to start, but it is not the preferred screen reader for blind desktop users.
• NVDA: NVDA is a free, open-source screen reader that you can download and use on your PC. This is the preferred screen reader for testing, as most blind people are Windows users.
• JAWS: JAWS is a paid screen reader, so it may not be where you want to start, but it is very popular with blind and visually impaired users, so it would also be good to fit into your testing plan as your budget allows.

Because screen readers do not all say the same thing for each element they encounter, we recommend testing your website with at least two different screen readers. This will ensure you have a full picture of what users of different technology will encounter on your website.

If you only have a Mac, BrowserStack allows users to test with NVDA on Windows virtually.

How to screen reader test

To test a web page with a screen reader, install or turn on your selected screen reader and load the page you want to test. Move through your website from top to bottom just as you did during keyboard navigation. Listen to what the screen reader says as you go down the page and test all the features.

Listen for anything that sounds confusing or incorrect, for example:

• Links that don’t describe their purpose: you might hear “Clickable graphic, clickable graphic” or “link, link, link” over and over again and have no idea what it’s supposed to do or how they’re different from one another. This also applies to ambiguous links (like “learn more”) that have no meaning when heard out of context – “Learn more about what?”
• Elements with confusing interaction: we see this a lot with tabbed content or accordions. If the tab is clicked or the accordion is opened but the focus does not move to the content inside the tab or accordion, and if the content is not immediately available with a tab or arrow action, screen reader users will not know how to find the content.
• Hidden interruptions: if you have a slider or media automatically playing elsewhere on the page, that can interrupting what the screen reader is currently reading lower down on the page and be disruptive to the user.

4. Check embedded media and linked content for accessibility

There are a number of items related to media and other embedded content that need to be tested manually. Whether you have a YouTube video, a slider, an embedded PDF or Doc, or a third-party widget or iframe on your website, you need to make sure that these embeds are all accessible too.

There are a number of considerations you need to take regarding different media types whether they are linked to or embedded on the page. We have specific information about those items in other help articles:

• Sliders
• Videos
• MS Office
• PDFs

If you have embedded content from social media (like an Instagram post) or an iframe from a third-party site, these need to be able to be fully interacted with just as the rest of your website can be. Make sure that you test them with both keyboard navigation and a screen reader.

5. Check the website for zoom/mobile accessibility

Users with low vision may zoom in on your website to be able to read the text. It’s important to check that your website works for these users when they visit. Zoom the website in 200% and 400% and make sure that the following applies:

• No content is lost on zoom.
• No content goes off the side of the screen or is not mobile responsive.
• The mobile menu can be used with the keyboard alone.
• All tap targets (buttons) are at least 24×24 pixels.

6. Check the website for motion-sensitive accessibility

Some users may find animations or motion on websites distracting or even nauseating. There are several WCAG success criteria that relate to testing website accessibility for motion sensitivities. To ensure your website works for these users check for the following:

• Anything that auto-plays for more than 5 seconds (including videos, background videos, carousels/sliders, and animated GIFs) has a pause button that allows users to stop it from playing.
• Nothing flashes more than three times per second (this can trigger seizures for some people).
• All animations disappear if the user has turned on reduced motion in their operating system.

You can test that your animations respect “prefers reduced motion” by turning on this setting in your own operating system. Here’s how:

• In Windows 11 go to Settings > Accessibility > Visual Effects > Animation Effects
• In macOS go to System Preferences > Accessibility > Display > Reduce motion

Once you turn this on in your operating system, refresh the web page you are testing for accessibility and confirm that all animations, auto-playing video, etc., has stopped.

For instructions on turning this on in other operating systems, see the MDN developer docs for prefers-reduced-motion.

Get Help With Manual Accessibility Testing

Manually testing a website for accessibility doesn’t have to be overwhelming. With the right tools and a thoughtful approach, you can move through your website page by page, making it accessible one page at a time.

However, if manual testing feels too complicated or you would like an expert review of your content, Equalize Digital is happy to help.

You can purchase an audit and accessibility remediation plan that includes manual accessibility testing and fixes or contact us if you would like a full accessibility audit.

We were proud to be the accessibility auditing team on the new NASA.gov website. Our team has experience testing website accessibility for higher education, enterprise businesses, nonprofits, marketing agencies, and other organizations with in-house developers, and we would love to help you!