Testing for accessibility

How to test the focus indicator

Press the "Tab" key on your keyboard to navigate to each element on the page.

Look for the focus indicator on each element of the page that you can also click with a mouse. An element has keyboard focus when it has a unique visual display like a border or a highlight.

Why we test with a keyboard

Many people living with mobility disabilities use the "Tab" key to navigate a page. Without a focus indicator, keyboard users won’t know where they are on a page. It would be like trying to navigate with a mouse but the mouse pointer is invisible.

Example of a visible focus indicator

This image shows a list of links. The "Residents" link has a thick orange border, bold text, and darker background. These three features put the focus on the "Residents" link. When the user presses the "Tab" key, the focus indicator will move to the "Business" link.

How to test for keyboard traps

1. Press "Tab" to navigate and interact with a page. Use the spacebar and enter keys to select and activate page elements.
2. Look for a seamless experience with keyboard navigation. Users must be able to move forward and backward without any issue. If you can’t move forward or backward, you’ve found a keyboard trap. A keyboard trap prevents a user from using a page.
3. Be sure to test third-party widgets, pop-ups (also called modals), videos, and calendars. They often have keyboard traps.

Why we test for keyboard traps

Keyboard traps force people who rely on keyboard navigation to close or refresh the page. It causes them to lose any progress. People with sight and mobility disabilities often rely on keyboard navigation.

Example of a keyboard trap

A user triggers a modal to open while filling out a form. The user can’t exit or close the modal using either the escape key or a "close" button. The user has become trapped in the modal. They now must refresh the page to exit and will lose all their progress filling out the form.

How to test for color contrast  

Test colors with a color contrast checker. It will tell you if the color of your text contrasts enough with the background color.

Requirements for color contrast ratios:

• Normal text must be at least 4.5:1. An ideal value is 7:1.
• Large text must be at least 3:1. An ideal value is 4.5:1.

Visit the Color contrast tools section under the Basics tab.

Why we test color contrast

Text and informative graphics may be hard to read without enough color contrast. Color contrast especially affects people with sight disabilities.

Example of a color contrast test

The button on the left has text color that stands out against the dark blue background.

It has the ideal contrast ratio of above 7:1. The higher the contrast ratio, the easier it will be for users to read.

The button on the right fails color contrast. It does not meet the minimum contrast ratio of 4.5:1. The text color is hard to see against the dark blue background.

How to check content for enough visual differentiation

You can simulate the experience of a user who is color blind. Use the Chrome extension Colorblindly.

Why we test using color blindness simulators

Testing with color blindness simulators shows the colors you need to change. It also shows the identifiers you need to add. People who are color blind or have low vision can then view and differentiate your content.

Example of a color blindness test

This example shows how users would perceive an error message in a form field.

The image on the left is how a user who is not color blind would see it.

The image on the right is how a user with red-green color blindness would see the same error message. Anyone who is color blind may not be able to see the color red. They would miss the meaning of the alert if the system only uses a red color to convey the alert.

The "X" icon alerts color blind users of an error.

This example uses design along with color to convey meaning. The combination of color and design helps all users perceive the error message.

How to test for 8th grade reading level

1. Run your text through a readability checker, like the Hemingway Editor.
2. Follow the tips provided by the readability checker when possible. Use simple alternatives for complex words, limit adverbs, and shorten lengthy sentences.

Why we test for an 8th grade reading level

Complex text can be hard to read and understand. This is especially true for people with cognitive disabilities and English language learners. Writing at this reading level helps make the content accessible for all audiences. This is a county standard and WCAG AAA standard.

Example of a readability test

The Hemingway Editor color codes readability issues. It also gives the text a grade level. You can fix readability issues in the editor.

If possible, avoid using acronyms and jargon. Most of the county's audience doesn't know what they stand for. Use a full description. Also include program or county. For example, write out Community Development Block Grant program instead of CDBG.

For more information about acronyms and jargon, visit the writing guide.

How to test for link quality

1. Read all link text.
2. If the link is vague or unclear, rewrite the link text.
3. For more information about writing links, visit the Digital Writing section.

Why we test for link quality

People who use screen readers can view a list of links on the page. Without descriptive link text, it will be hard for them to know where the links lead to.

Example of link text

Bad example: Click here to learn more.

Good example: For more information about writing links, visit the Digital Writing section.

How to test for button label quality

1. Read all button text.
2. If the button text is unclear or long, rewrite the text to describe the action of the button when used. For example, a button to submit a form should include the word "submit."

Why we test for button label quality

Vague or unclear button text will lead people to confuse the purpose of the button. This could cause an unintended action.

Example of button labels

Label a button that submits a form as "Submit" or "Submit form."

How to test heading levels

1. Navigate to each heading on the web page. Listen for every heading level included in the content. In general, screen reader controls use a hot key. For example, NVDA uses the 'H' key.
2. Listen for the correct heading level hierarchy. For example, you should hear heading levels increase from Heading level 1 to 4. Hennepin County’s best practices state there should only be one Heading 1. Make sure the following headings are in logical order.

Why we test heading levels

Screen readers communicate heading levels to users to help them navigate content. This helps users who are visually impaired understand the structure of the content.

Example of a screen reader navigating headings

How to test alt text

1. Navigate to every image on the page you’re testing.
2. Use the screen reader controls to listen to the alt text. Check that alt text is present and gives an accurate description of the image and its context.
3. Screen readers ignore decorative images.
4. For more information about alt text, visit the Writing for accessibility section.

Why we test alt text

People who can’t see images rely on alt text to understand and learn from the image. If the screen reader doesn’t detect alt text, these users will miss important information.

Example of a screen reader announcing alt text

How to test landmarks

On NVDA, use the "D" hot key to move between landmarks.

Examples of expected landmarks

• Header or banner: the first section of the page with the website title
• Navigation: list of links for navigating the website
• Main: the primary content of the page
• Footer: the last section of the page with information and links about the website

Think of landmark regions like parts of the human body: the head or header in this case, should be first. The feet, or footer, should be last. The main landmark is the main body torso. The landmark order needs to be in logical order. For example, think of the song, "Head, shoulders, knees, and toes."

For more information about landmarks, visit the Developing for accessibility guide.

Why we test landmarks

Landmarks break down a page into expected sections. This helps users create a mental map of that page to navigate it successfully.

Example of landmarks

A person wants to find the social media link that usually exists at the end of a page. They would use the "D" hot key to navigate quickly to the footer landmark where they can get to the social media link.

This helps them skip over content and landmarks they don’t need.

How to test screen magnification

Use screen magnifier tool to check that text isn’t blurry when zoomed to 200%.

If images become blurry when resized, use images in svg format. If layout and space changes content when resized, use responsive design. This allows content to reflow around spacing modification without cutting off text or losing content.

Another way to check responsive design is by using Browserstack or the "Toggle device toolbar" in DevTools. Both tools mimic the perspective of various devices.

Why we test screen magnification

People with certain sight disabilities may need to adjust the content on a page to make it easier to see. If the content and layout is not responsive, then content may not be readable and may be lost. Navigation will also become more difficult for those users.

Example of screen magnification

The following two images show Hennepin County's navigation bar. The first image is what the text looks like with default text spacing and size, and the second image has increased spacing between characters. Both images include the same text, so the navigation bar is compatible with text spacing editors.

How to test speech recognition

1. Don’t pause while saying a command. Pause after each command is spoken.
2. Navigate through your page. For example, you may say the command "Tab" to move from a text input field to the submit button.
3. Test all buttons and links to make sure they can be selected and activated using only the speech recognition tool. For example, saying the command "Click submit button."
4. Test mouse control using spoken commands. For example, saying "Mouse grid" and "Move mouse up."

Why we test speech recognition

Being able to navigate and use a page using only speech commands is critical for people with mobility disabilities. They rely on speech commands to successfully use digital products.

Example of speech recognition

A person with carpal tunnel navigates to the Hennepin County homepage using spoken commands. They say the command "Mouse grid" to put a grid overlay on the page with 9 numbered squares. The user can say a number of 1 through 9 to create a deeper grid of 9 squares in that space. This helps the user get to a specific link they want to visit. Video of a user activating the mouse grid commands with a speech recognition tool (YouTube).

How to test controls

1. When you open your website or digital product, look and listen for videos or animations that automatically move for more than 5 seconds.
2. Check that there is a way to pause, stop, or hide these videos or animations.

Why we test controls

Moving animations and videos can be distracting, especially for people living with cognitive disabilities like ADHD. It can draw their attention away from everything else on the page.

Example of controls

If your website has an image carousel that continuously rotates through photos, include a pause button and arrows to move through the photos manually.

How to test accurate transcripts or captions

1. Review all pre-recorded content for available transcripts or captions. Video only- and audio only- content require a text transcript. Video with audio requires captions.
2. Captions and transcripts must include all dialogue and important sounds.
3. Make sure to check for accuracy. Automated captioning can have many errors.
4. Check the captions and transcripts for spelling or grammar mistakes.
5. Transcripts are either beside the pre-recorded content or are included through a link.
6. To increase accessibility for videos with audio, you may include a transcript.

Why we test accurate transcripts or captions

Captions and transcripts provide a visual alternative to auditory information. This is especially important for people with hearing disabilities.

Example of accurate transcripts or captions

This is an example of a properly captioned video. Select the "CC" button on the video to view captions. Select the "Show transcript" button in the video description to view the transcript.

How to test synchronized captions

1. Watch the video and listen to the audio.
2. Closed captions must match all spoken words and important sounds heard in the audio.
3. Each caption frame must align with the audio track.
4. Captions are presented at a readable speed of 3 to 7 seconds on the screen. While time duration isn’t a WCAG standard, it is an FCC requirement for closed captions.
5. Videos must include captions from to start to end.
6. Captions don’t block other important visual content.

Why we test synchronized captions

Synchronized captions help people who are deaf or hard of hearing understand the audio content of a video at a reasonable pace.

Example of synchronized captions

This is an example of a properly synchronized video captions. Select the "CC" button on the video to view captions. Select the "Show transcript" button in the video description to view the transcript.

How to test alt text

1. Informative images must include meaningful alt text. For more information about crafting meaningful alt text, visit the Writing for accessibility guide.
2. Use an empty alt tag alt="" for decorative images. For example, decorative lines that divide content.
3. Complex images, such as charts or maps, must have two types of alt text: a short description and long description. A short description describes the image of the chart or graph. A long description explains or summarizes the data and findings.

Why we test alt text

People with sight disabilities rely on alt text to understand visual information. Bad or missing alt text prevents people with sight disabilities from understanding content.

Example of alt text

The following image might include the alt text: "A person wearing a white shirt and blue blazer stands on a busy city street."

How to test page titles

1. Page titles are displayed on browser tabs. Make sure a page title exists and is specific to that page.
2. To find the <title> attribute, go to the <head> section of the HTML file.
3. An example format for writing page titles at Hennepin County is "Residents | Hennepin County."

Why we test page titles

Page titles serve as a navigation point. Screen readers use page titles to let users know what page on the website they are accessing.

Example of a page title

On the Hennepin County Contact page, the page title on the browser tab is "Contact | Hennepin County." The corresponding code is <title> Contact | Hennepin County </title> in the <head> section. Visit the Hennepin County Contact page.

How to test heading levels

1. Headings are used to organize and structure the content. For more information about headings, visit the Navigation section in Developing for accessibility.
2. Each web page only needs one <h1>. The <h1> should be the main topic of the page.
3. The next heading must use an <h2> tag.
4. The content hierarchy for the rest of the page should use heading levels <h2> through <h6>.

Why we test heading levels

People using assistive technology, such as screen reader and speech recognition tools, rely on properly coded headings to navigate and comprehend content.

Example of heading levels

For an example of heading level page hierarchy, visit W3C’s Headings that reflect the page organization.

How to test keyboard shortcuts

If your digital product is using a keyboard shortcut, follow these 3 requirements:

1. Make sure it can be turned off.
2. Users can change the shortcut to include other keyboard keys. For example, the user can choose to also use the ctrl key.
3. Keyboard shortcut is only activated when component has focus.

Why we test keyboard shortcuts

Speech input users and keyboard users need to be able to customize keyboard shortcuts. This helps prevent accidental command actions. Speech input users may try to spell out a word but accidentally activates a letter "m" keyboard shortcut. Users with mobility disabilities may accidentally hit a wrong key and trigger a keyboard shortcut. The ability to customize keyboard shortcuts have greater control over their navigation experience.

Example of keyboard shortcut

To see an example of a customized keyboard shortcut, visit the Deque University character keyboard shortcuts.

How to test input assistance

1. Instructions are clear and understandable.
2. Instructions are easily found by assistive devices.
3. When an error occurs, all users know where it is.
4. The user knows what the error is and how it can be fixed.
5. The error message may include additional indicators but must have text.

Why we test input assistance

Input assistance tells users how to successfully complete a form.

People who are visually impaired are most impacted when instructions and errors are not clear, buried in content, or are not indicated beyond color.

Example of input assistance

How to test component predictability

1. Look for components that trigger changes upon interaction. This includes form fields, selects, checkboxes, radio buttons, and any custom widgets.
2. Interact with these components to see if any content changes occur.
3. If changes occur, verify that there are instructions to inform people of the changes in advance. The changes should also be minor and not disrupt the user's workflow. For example, let people know ahead of time that choosing a specific option within a select will change the follow-up question.

Why we test component predictability

Predictability is important for people to successfully navigate and interact with a website or form. The disorientation caused by unexpected changes can make pages or forms unusable, especially for people with cognitive disabilities. Changes that do not require a page reload but update content should be expected or communicated to people beforehand. For example, let people know ahead of time that sections of a page update dynamically.

Example of component predictability

A form selection triggers additional fields. Next to a select component is text informing users that choosing certain options will display additional questions specific to that option. Because there are clear instructions informing people of the change in advance, the select component passes this test.

How to test time limits

Check if at least one of the following is true:

• Turn off: can remove time limit
• Adjust: can change time limit
• Extend: can extend time
• Exception: time limit is required and cannot be extended; user gets a warning message before session closes

Why we test time limits

Having more time to navigate, understand, and use a site benefits various accessibility needs. For example, people using screen readers require more time to understand screen layout, locate controls, and operate them. People with cognitive disabilities require more time to read, understand, and respond to content. People with physical disabilities, require more time to complete tasks accurately.

Example of time limits

An online registration form gives people a chance to extend their current work session by another 15 minutes. They get 10 opportunities to extend their work session. After 10 extensions, there is a warning that the extension limit has been reached and the session will officially end after 15 minutes.

How to test pause, stop, or hide controls

1. Find any content that moves, blinks, scrolls, or auto-updates. For example, look for carousels, animations, or auto-updating feeds.
2. Check that there are control mechanisms for people to stop or hide the moving content. For auto-updating content, people can also control the frequency of updates unless the auto-updates are essential.
3. Test the controls to ensure they are operable and meet screen reader and keyboard-only navigation requirements.
4. Verify that people have enough time to read and understand content before it automatically updates.

Why we test pause, stop, or hide controls

• Moving or auto-updating content are issues for people with cognitive disabilities, motion sensitivity, or who are visually impaired.
• People who have difficulty focusing or are easily distracted may find moving and auto-updating content disruptive.
• People with reading disorders may find scrolling or blinking content difficult to read.
• Moving or flashing content can cause physical discomfort or nausea for people with motion sensitivity.
• Screen readers have difficulty reading auto-updating content.

Example of pause, stop, or hide controls

A video about water safety is embedded on a web page. The video doesn’t automatically start. It has clear and easily navigable control buttons to play, pause, pause, stop, or hide the video.