Testing as part of a workflow
When creating accessible content in Studio, it’s important to continuously test and evaluate your content throughout your entire workflow—from initial planning to final publication. Screen readers and keyboard navigation software rely heavily on the HTML content rendered in your published experience, and while the accessibility features in the Studio enable you to create accessible HTML, the studio can’t determine if that HTML is easy to understand and navigate.
Due to the flexible, free-form nature of the Studio, it’s not possible to create a one-size-fits-all approach for creating accessible content—nor would we want to. As a result, testing should happen during the design and implementation process and not wait until the end. Remediating an inaccessible implementation after the fact can be very labor-intensive and costly.
Throughout the design/implementation process, there are a few key things that you should be testing for:
Validate keyboard navigation– Ensure that all of the interactive components on the page (ie. menus, popups, carousels, etc.) can be easily tabbed through without the use of a mouse. See the Keyboard Navigation section below for more information on testing keyboard navigation.
Validate screen reader navigation– Leverage a screen reader such as JAWS, NVDA, or VoiceOver to test that all of the content in the experience is being read out appropriately. Read on through this article for more information on screen readers.
Run accessibility scanning tools– Scanning tools such as Lighthouse, Wave, AXE DevTools, ARCToolkit, and Siteimprove can be used to detect further accessibility errors.
Check color contrast ratios– Ensure that you have sufficient contrast between your text and background colors within the experience. Check out our Accessibility Best Practices guide for more information, as well as a link to a color contrast validator tool.
It’s important to take these steps early and often, as identifying a few issues on one popup, for example, is much easier to fix than a few issues on 60 popups. Early detection can be the difference between a quick fix and weeks of work.
Only after the above areas are addressed would we recommend submitting a design for a formal accessibility audit. And even then, it’s very common to find additional issues in a final audit. There’s no substitution for accessibility testing with impaired users who are keyboard and screen reader experts. But hopefully, weaving in accessibility considerations and testing often throughout your entire process will reduce the number of final accessibility remediations you will have to make to the experience.
Although not an exhaustive list by any means, below, we have identified several tools and tips to give you a leg-up on creating accessible content. However, always check with your accessibility team to ensure you are following company guidelines.
Testing Methods
Keyboard Navigation
Being able to navigate digital content without the use of a mouse is one of the most commonly used accessibility tools for those with visual or motor impairments. Luckily, it’s also one of the easiest accessibility features to test.
Try using your tab key to first highlight something you want to uncover or navigate to, and then hit the enter key to execute your action. Think of tab being moving your mouse, and enter is your click. Were you able to navigate through the experience in the correct content order? Did it trigger the correct interactions? Do your hyperlinks work? These are crucial controls to make your content accessible to a wider audience.
The main keys used in testing include:
Tab: Moves forward
Shift-Tab: Moves backward
Enter: Selects elements
Read more about keyboard navigation here.
Scanning & Evaluation Tools
Scanning tools will test your experience to see if it meets compliance requirements. Keep in mind, however, that some scanning tools may surface “errors” that may not actually be end-user issues. For example, it may flag an image as “missing an Alt tag” but the image is purely decorative and isn’t intended to communicate information to the user.
A few options for scanning & evaluation tools are:
Lighthouse (Chrome extension)
Screen Readers
Using a screen reader will also help you identify problems with reading order, navigation, and many other aspects of accessibility. Note that tabbing, though effective with keyboard testing, shouldn’t be used with screen readers.
JAWS (Windows)
JAWS runs best with Chrome or Firefox. Most JAWS keys use a special modifier key as part of the key sequence. For JAWS that is the “insert” key. When you see “JAWS” in a key sequence, it means to use the right option key on your Windows keyboard.
Note: JAWS sometimes enables reduced motion (stop animations) automatically when it loads. You can turn it back on in the Windows System settings. In Windows, navigate to Settings > Ease of Access > Display to enable the “Show animations in Windows” option.
NVDA (Windows)
NVDA runs best with Chrome or Firefox. Like JAWS, most NVDA keys use the Windows “insert” key as the modifier key.
If you need to access NVDA on a Mac, you can access it through a Virtual Machine. Just be aware you will have to map a key (we suggest your right ‘Option’ key) to serve as the Windows ‘insert’ key.
VoiceOver (MacOS)
VoiceOver is built-in to the MacOS and works natively in the Safari browser, so there’s no installation required. The primary modifier key combination is Ctrl+Opt and is referred to as the “VO” key.
VoiceOver Rotor
Use the rotor function to quickly navigate page landmarks, buttons, and links. Press Ctrl+Opt+U for the rotor. Select an item with arrows and enter. Then navigate from the landmark using Ctrl+Opt+-left|right arrow. Using regular up/down arrow keys will start from wherever the keyboard focus is, which most likely won’t be the selected landmark.