Get to Know the Accessibility Test Framework
After completing this unit, you’ll be able to:
- Describe the issues Aura accessibility tests check for.
- List strategies to automate and write your own accessibility tests.
Let’s dive into testing for accessibility. Why? We want to find barriers and fix them before users ever encounter them. Ideally, there are never any accessibility bugs to begin with, but bugs do happen during development. Our goal here is to ensure that none of those bugs reach your users. In this unit, we cover test automation, Aura component accessibility tests, writing tests, and open-source automation tools.
Use a mix of prebuilt test utilities and custom test cases to catch accessibility regressions in your user interfaces. The mobile test frameworks for iOS and Android include basic accessibility checks. If you develop features using native code, add tests to perform basic checks supported by the test frameworks. We don’t cover mobile testing in this module, but we do provide a great resource for mobile testing in the Resources section.
When you develop with Aura components, you can use Salesforce’s test tools to check for common accessibility issues. You can call Aura accessibility tests in two environments.
Environment | Function Call |
---|---|
JSTEST
|
$A.test.assertAccessible()
|
WebDriver Test
|
auraTestingUtil.assertAccessible()
|
These functions check the rendered DOM elements to make sure they pass Salesforce’s accessibility validation.
When you use these tools, there are two outcomes: pass or fail. If the tool doesn’t find any accessibility exceptions, it returns an empty string. If the tool does find accessibility exceptions, it returns the accessibility rule that failed, the erroneous tag, and a stack trace of where it was found in the code.
Since Aura components and pages are dynamic, make sure to retest your components’ accessibility every time something changes in the DOM. Otherwise you aren’t checking every UI state your users encounter.
The Aura accessibility tests look for these issues:
- Images without
alt
attributes - Anchor elements without textual content
-
input
elements without associated labels - Radio button groups not in
fieldset
tags -
iframe
orframe
elements with emptytitle
attributes -
fieldset
elements withoutlegend
tags -
th
element without ascope
attribute -
head
element with an emptytitle
attribute - Headings (
H1
,H2
, and so forth) increasing by more than one level at a time - CSS color contrast ratio between text and background less than 4.5:1
Note that these tests are not all-encompassing. If your code passes every test, it’s not a guarantee that your product is fully accessible. However, these tests do surface major accessibility issues, and putting them in place ensures that a regression will never make your code inaccessible.
If you’ve done a lot of work to make a component accessible, write tests to make sure it stays that way. You can write automated tests for a variety of accessibility concerns, including expected keyboard functionality and that the role, state, and property ARIA values for HTML elements are correct.
Example: Testing an Expandable Section
Say you have an expandable section. When you click Codey’s name, the section expands to tell you more about him, and when you click his name again, the section below collapses.
Here’s some pseudocode for an Aura component test that toggles the collapsed and expanded state of an expandable section.
testToggleExpandCollapse : { test : [ function(cmp) { // Default: collapsed this.assertCollapsed(cmp); // Toggle to expanded this.clickToggleButton(cmp); this.assertExpanded(cmp); // Toggle back to collapsed this.clickToggleButton(cmp); this.assertCollapsed(cmp); } ] }
First, we assert the element is collapsed by default, then we click the toggle button, verify it’s expanded, click the toggle button again, and verify it’s collapsed.
How can we embed accessibility checks into this test? Let’s explore the two helper functions assertCollapsed
and assertExpanded
.
assertCollapsed : (cmp) { var button = this.getButton(cmp); var section = this.getSection(cmp); // Button indicates section is collapsed aura.test.assertEquals( button.getAttribute('aria-expanded'), "false", "Button should indicate it's collapsed" ); // Section is visually closed aura.test.assertFalse( section.classname.indexOf('slds-is-open') > -1, "Section should be collapsed" ); }
For an expandable section to be accessible, it must communicate its expanded/collapsed state to assistive technology users, such as screen reader users. The best way to do this is with an ARIA state attribute, aria-expanded
, on the button,
which is true
when the section is expanded and false
otherwise. To make sure this attribute is always properly set, we can assert it has the correct value. In assertCollapsed
, we assert that aria-expanded
has a value of false
. Now, in assertExpanded
, we can assert that aria-expanded
has a value of true
.
assertExpanded : (cmp) { var button = this.getButton(cmp); var section = this.getSection(cmp); // Button indicates section is expanded aura.test.assertEquals( button.getAttribute('aria-expanded'), "true", "Button should indicate it's expanded" ); // Section is visually open aura.test.assertTrue( section.classname.indexOf('slds-is-open') > -1, "Section should be open" ); }
If the code that’s setting aria-expanded
regresses, we catch the bug before it reaches screen reader users. Now let’s go back to our testToggleExpandCollapse
test case. Let’s add $A.test.assertAccessible()
in two
strategic places so that we run Salesforce’s default set of accessibility checks against the section’s expanded and collapsed states. Remember, we want to test every state, not just one. If we test only the collapsed state, we might miss accessibility
bugs in the expanded section.
testToggleExpandCollapse : { test : [ function(cmp) { // Default: collapsed this.assertCollapsed(cmp); // Toggle to expanded this.clickToggleButton(cmp); this.assertExpanded(cmp); $A.test.assertAccessible(); // Toggle back to collapsed this.clickToggleButton(cmp); this.assertCollapsed(cmp); $A.test.assertAccessible(); } ] }
Now we have accessibility checks running automatically in WebDriver, we have them enabled in our component tests, and we’ve added some custom tests.
In addition to our automated test framework, there are a number of robust open-source tools for testing for accessibility.
- axe
- Linters (es-lint and others)
Now that you’ve been introduced to the accessibility framework, automating accessibility tests, and open-source tools, let’s see how you can write accessibility test plans.
- iOS Documentation: About Accessibility Verification on iOS
- Android Documentation: Test Your App's Accessibility