Get to Know the Accessibility Test Framework

Learning Objectives

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.

Introduction

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.

Automate Accessibility Tests

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.

Use Aura Component Accessibility Tests

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.

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 or frame elements with empty title attributes
• fieldset elements without legend tags
• th element without a scope attribute
• head element with an empty title 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.

Write Your Own Accessibility Tests

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.

Open-Source Accessibility Automation Tools

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)
  • https://github.com/evcohen/eslint-plugin-jsx-a11y
  • https://github.com/reactjs/react-a11y

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. 

Resources

• iOS Documentation: About Accessibility Verification on iOS
• Android Documentation: Test Your App's Accessibility