Test for Accessibility

Learning Objectives

After completing this unit, you’ll be able to:

• Explain why it’s critical to conduct manual accessibility testing in addition to automated testing.
  
• Summarize steps for conducting keyboard and focus-management testing on MacOS.
  
• Identify checks to complete when conducting screen-reader testing with VoiceOver.
  
• Recognize elements to include in your accessibility test plans.
  
• Describe strategies for effective manual accessibility testing.
  

Understand the Importance of Manual Testing

While automated accessibility tests can catch a lot of issues, they don’t consider context or identify more nuanced accessibility issues. And sometimes they even miss significant issues. That’s why it’s critical that you conduct manual testing as well to catch any barriers that automated testing failed to identify. Manual testing also allows you to validate issues you’ve uncovered during automated testing and identify false positives.

Unlike automated accessibility testing, manual testing assesses the user journey as a whole to simulate the experience of a user who has a disability or uses assistive technology. For example, manual keyboard testing simulates how a user navigates your software using only a keyboard, while manual screen-reader testing simulates how a visually impaired user experiences your software.

Let’s take a closer look at manual accessibility testing, starting with keyboard and focus management.

Conduct Keyboard and Focus-Management Testing

Keyboard and focus-management testing are great ways to ensure users can navigate and interact with the UI in straightforward, expected ways.

When keyboard testing, explore questions such as:

• Is content accessible using a variety of inputs? Users should be able to navigate content using various input devices, such as speech commands, touch screens, and switch controls. If some content is available only on mouse hover, users of touch screens, voice dictation, and keyboards are going to miss out.
  
• Is the focus order logical? Focus order refers to the sequence in which interactive elements—such as links, buttons, and form fields—receive focus. Illogical focus order can make navigation difficult.
  
• Can a user navigate the content with efficiency and consistency? Unexpected changes in navigation, such as different keystrokes or commands, challenge the end user, especially if they use assistive technology.
  
• Can all users navigate this content? Consider individuals with motor, dexterity, and vision impairments.
  

When testing on a Mac, you need to enable full keyboard access in the Keyboard system preferences. Follow these steps.

Enable Keyboard Navigation on MacOS

1. Open Keyboard settings in System Preferences.
   
2. Select the Shortcuts tab.
   
3. Under Full Keyboard Access, select All controls.
   

Enable Keyboard Access for Safari

1. Open Safari Preferences.
   
2. Select the Advanced tab.
   
3. Under Accessibility, check Press Tab to highlight each item on a webpage.
   

Navigate a web page with these keys.

Can You Reach Every Interactive Element and Trigger Its Action?

Some complex components with multiple interactive elements have more unique keyboard interactions beyond the basics, including comboboxes, menus, data grids, non-modal and modal dialogs, and tabsets. These keyboard interactions follow certain expectations defined by World Wide Web Consortium (W3C) ARIA Authoring Practices.

Salesforce builds its keyboard guidelines on these expectations, and these guidelines are used in the Lightning and Lightning Design System’s React component libraries. We’ve compiled some helpful resources on the Lightning Design System 2 site to help you build and test these components.

• Keyboard Interaction Accessibility Guidelines: A checklist of manual keyboard tests
  
• Global Focus Accessibility Guidelines: Tips on expected behavior for focus management
  
• Accessibility: HTML and interaction specs for common widgets/patterns
  

Test Keyboard Navigation

When testing keyboard navigation, verify that:

• Tabbing order is logical. Use the keyboard to tab through your app. The default navigation order should be logical and feel natural.
  
• Keyboard focus is visible. Use the keyboard to navigate a page and confirm that a visual indicator shows the element that has keyboard focus.
  

• Actionable items receive focus. Use the keyboard to navigate around a page. Test that all buttons, links, form fields, tabs, and any other interactive items can accept keyboard focus. If a user can click an item to perform an action or hover over it to reveal information, it must accept keyboard focus.
  

• Interactive elements can be navigated. Verify that you can navigate all interactive elements such as menus, modals, drag-and-drop elements, tabsets, panels, and autocomplete dropdowns. Verify that you can use the keyboard to select and activate items.
  

• Modal dialogs can be navigated. Use the keyboard to open and navigate a modal dialog and operate every control in it. Verify that you can interact only with the current modal window, not the page behind it. When a modal is open, focus should be trapped inside it. Make sure that when the modal is closed, focus returns to the correct place on the page.
  

Keep in mind that keyboard testing and screen-reader testing are not one and the same. Try keyboard testing before testing with a screen reader to highlight many issues that a screen reader might not catch.

Conduct Screen-Reader Testing

We recommend testing screen readers on both MacOS and Windows. MacOS has a built-in screen reader called VoiceOver, which speaks the selected element aloud and reads its label or alt text. When you test with a screen reader, find out whether your alt text is accurate, then make the necessary adjustments.

Here are some simple checks you can complete with VoiceOver on MacOS.

• Use Cmd+F5 to toggle VoiceOver on and off.
  
• Use Cmd+u to open the Web Rotor.
  
• Use Web Rotor to check that:
  
  • Links and buttons have concise, meaningful labels.
    
  • Headings are in the proper order.
    
  • The page has good landmarks.
    
• Tab through the UI to verify that:
  
  • Editable fields speak their label, input type, and the word edit.
    
  • Tabsets indicate which tab is selected and can be navigated with the arrow keys.
    
  • Checkboxes audibly speak their states when toggled with the spacebar.
    

Don’t worry if you can’t reach every piece of content by tabbing through a UI using a screen reader. Screen-reader users have specific keyboard shortcuts for navigating through the page element by element, including noninteractive elements, so the Tab key doesn’t have to (and really shouldn’t) reach everything. With VoiceOver, you can use the Ctrl+Option+Left arrow or the Ctrl+Option+Right arrow to read linearly backward or forward, respectively, through the page content.

On Windows, we recommend using NVDA.

Conduct accessibility testing with multiple screen readers. If you only test with VoiceOver, you might miss specific issues that other screen readers—such as JAWS or NVDA—will catch.

If you’re conducting testing with a screen reader, and you don’t use one regularly, it’s common to encounter user error. Reference the A11ycasts videos in the Resources section to learn more about the nuances of using screen readers.

Write Accessibility Test Plans

Make accessibility part of your test plan by including it in your component specs, acceptance criteria, and user stories.

Example: App Launcher

To open the App Launcher, select . In the App Launcher, users can search for apps, open apps, read app descriptions, and rearrange apps.

What Test Cases Can You Create for Rearranging Apps?

Here’s a sample test plan for different use cases associated with the App Launcher.

For context, functionality refers to what a product or system is capable of doing—its features and actions. Affordance is a design element that suggests how an object should be used based on its appearance or behavior.

What other test cases can you add? How will you go about testing these? While you might be able to write automated tests for the screen-reader attributes and keyboard behavior, you still want to do some manual testing to ensure the experience is seamless.

Use Manual Testing Strategies

Ready to put it all together? Here are some strategies for conducting effective manual accessibility testing.

Write a Test Plan

You might include:

• Calling $A.test.assertAccessible for key visual states (for component tests).
  
• Manually checking for keyboard flow.
  
• Considering factors unique to your use case.
  

Test Early and Often

While building user interfaces:

• Manual testing.
  
• Enabling test automation.
  
• Looking for opportunities to lock in accessibility with custom tests.
  

Log and Fix Bugs

At Salesforce, we prioritize accessibility bugs, regardless of the number of users they affect. For users affected by these bugs, they can be a fundamental barrier to completing their work. However your organization prioritizes bugs, advocate for keeping unresolved accessibility issues to a minimum.

By conducting both automated and manual accessibility testing and removing accessibility barriers, you provide a truly inclusive digital experience that everyone can participate in and enjoy!

Resources

• Webpage: ARIA Authoring Practices
• Salesforce Site: Lightning Design System 2: Keyboard Interaction Accessibility Guidelines
• Salesforce Site: Lightning Design System 2: Global Focus Accessibility Guidelines
• Salesforce Site: Lightning Design System 2: Accessibility
• Website: NV Access
• Website: Freedom Scientific: JAWS
• Video: A11ycasts: How I do an accessibility check—A11ycasts #11
• Video: A11ycasts: Screen Reader Basics: VoiceOver—A11ycasts #07
• Video: A11ycasts: Screen Reader Basics: NVDA—A11ycasts #09