Test for Accessibility
After completing this unit, you’ll be able to:
- List examples of items to check when manually testing for accessibility.
- Identify factors to consider when testing keyboards and screen readers.
- Explain some strategies for creating your own accessibility tests.
Automated testing is fantastic, but it’s important to do manual testing as well. Manual testing with a keyboard simulates how a user navigates your feature using only a keyboard. It’s also crucial to manually test with a screen reader to simulate how a visually impaired user experiences your feature. Keyboard access isn’t enough on its own, although it’s a good first step.
Keyboard testing is a great way to ensure a user without a mouse can navigate and interact with the UI in straightforward, expected ways. Designers, engineers, and project managers should think about:
- Input-device agnostic. Not just for keyboard but also for other 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 keyboard are going to miss out.
- Efficiency and consistency.
- Motor, dexterity, and vision impairments.
Enable Keyboard Navigation on MacOS
When testing on a Mac, you need to enable Full Keyboard Access in the Keyboard system preferences.
- Open Keyboard settings in System Preferences.
- Select Shortcuts tab.
- Under Full Keyboard Access, select All controls.
- Open Safari’s Preferences.
- Select the Advanced tab.
- Under Accessibility, check Press Tab to highlight each item on a webpage.
Use these keys to navigate in a web page.
- Tab and Shift+Tab. Navigate through links, input fields, and other interactive controls. Tab moves forward through the UI and Shift+Tab moves backward. Don’t be alarmed if you can’t tab to every single thing on the page—just interactive things.
- Ctrl+Tab. Navigate through frames.
- Enter. Activate links.
- Enter and Space. Activate buttons.
- Space. Activate input field checkboxes and select dropdown menus.
- Up Arrow and Down Arrow. Navigate menus, picklists, and autocomplete dropdown menus.
- Left Arrow and Right Arrow. Navigate through tabs in a tabset or carousel.
- Esc. Close menus, modals, and panels.
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 the W3C’s 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 site to help you build and test these components.
- Keyboard Interaction Accessibility Guidelines: A checklist of manual keyboard tests
- Global Focus Guidelines: Tips on expected behavior for focus management
- Accessibility Patterns: HTML and interaction specs for common widgets/patterns
Test Keyboard Navigation
When testing keyboard navigation, verify these items.
- 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 it 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.
For more, follow our Keyboard Interaction Accessibility Guidelines checklists.
We recommend testing on both macOS and Windows. MacOS has a built-in screen reader called VoiceOver, which is handy for testing. VoiceOver speaks aloud the selected element and reads its label or alt text. When you test with a screen reader, you find out whether your alt text was helpful, meh, or a bit annoying. Never fear, that’s what testing is for—you can always go back and fix it.
Simple Checks with VoiceOver on MacOS
- Cmd+F5. Toggles VoiceOver on/off.
- Cmd+u. Opens the Web Rotor.
- Use Web Rotor to check:
- Links and buttons have concise, meaningful labels.
- Headings are in proper order.
- Page has good landmarks.
- Tab through the UI to verify:
- 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. Because screen reader users have specific keyboard shortcuts for navigating element-by-element through the page, including noninteractive elements, the Tab key doesn’t have to (and really shouldn’t) reach everything. With VoiceOver, you can use Ctrl+Option+Left arrow or Ctrl+Option+Right arrow to read linearly backward or forward, respectively, through the page content.
On Windows, we recommend using NVDA.
Disclaimer: Testing with a screen reader when you don’t use one regularly is highly prone to user error. Learn more about the ins and outs of screen reader usage by viewing the A11ycasts videos in the Resources section.
Accessibility should be part of your test plan! Be sure to include accessibility in your component specs, acceptance criteria, and user stories.
Example: App Launcher
The App Launcher can be launched from the waffle-like App Launcher button in the upper-left corner of any Salesforce page. 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?
The table is a sample test plan for different use cases associated with the app launcher.
||Clicking tile opens app
||Pressing Enter on tile opens app
All keyboard expectations apply
||Tile has move cursor when hovered
||Tile move button has distinct visual focus indicator
||User is notified of possible interactions
||Click and hold tile initiates dragging
||Space key initiates drag mode
||Grab state, position, and instructions read out when user enters drag mode
||Drag mode has distinct visual state
(tile at angle with blue border)
|Drag mode has distinct visual state (tile at angle with blue border)
||Moving mouse when dragging moves tile
||Arrow keys move app to next/previous position in list
||User sees preview of app position
||User sees preview of app position
||App position reads out when it changes
||Mouse release ends dragging
||Enter key exits drag mode
||Final position and grab state read out
when user leaves drag mode
What other test cases can you add? How do you go about testing this? We may be able to write automated tests for the screen reader attributes and even for the keyboard behavior, but you still want to do some manual testing to ensure the experience is seamless.
Write a Test Plan
Possible content for your test plan:
- In component tests, call
$A.test.assertAccessiblefor key visual states.
- Manually check keyboard flow.
- Other considerations unique to your use case.
Test Early and Often
This is true for everything and especially true for accessibility. While building user interfaces:
- Manually test.
- Enable test automation.
- Look for opportunities to lock in accessibility with custom tests.
Log and Fix Bugs
At Salesforce, we treat accessibility bugs as high priority. Even if they don’t affect a large group of users, for the users they do affect, the bugs can fundamentally block a user from their work. However your organization prioritizes bugs, advocate to keep accessibility debt at a minimum.