Accessibility Fail Fast — Execution

4 black and white cartoon drawings of people falling — off a ladder, slipping on a floor, off a flight of stairs, and off a curb

Second Part of a Two-part article

Part one is located here

Accessibility Fail Fast Step 1: Smoke test using an automated accessibility test suite

A smoke test is a non-exhaustive set of tests that check to see if critical functions work. The end goal of smoke testing is a decision on whether the build is of sufficiently decent quality to proceed with investing more time in it. Automated tests don’t always cover all critical functions, but they are fast to execute and fairly easy to interpret. Chances are if large chunks of automated test behavior are failing, that not a lot of attention was paid to accessibility requirements during any part of the development process.Expect about 30 % coverage from your accessibility automated test suite.

You want the automated tests to run relatively cleanly before you start manual testing. It’s fine proceed to manual testing if you are missing bits of alt-text and other things that can be fixed via the content manager — those are not high risk fixes. Having to change significant chunks of code, however, puts you at high risk for requiring repeated manual testing cycles. This is undesirable and the entire point of the Fail Fast methodology.

After step 1, all tests should be done with forms of assistive technology and browsers / environments you identified in your preparation process

Accessibility Fail Fast Step 2: Focus on Infrastructure not Content

Functional parts of templates, especially navigation, are of utmost importance for early fail fast testing. Each defect that shows up in a template can appear on every page (i.e. thousands of times). These types of defects native users of assistive technology from easily testing your product/website. Content is generally the last thing that gets finalized, sometimes just a few days before launch. Content defects are also generally quite easy to fix since they rarely require code changes, releases, or IT resources. Therefore, spend your fail fast test review time on infrastructure not on content.

Accessibility Fail Fast Step 3: Check your colors

Color is an AA guideline. And you probably reviewed it when you did your design review (you did do a design review, right?) So why would that be towards the top of things to test in a Fail Fast list?

  1. The colors in the design review may not have been the colors that got implemented. Humans are involved. They make mistakes. Or developers randomly made a bad color choice for something that the designers forgot to specify (like visited link color).
  2. Given how surprisingly easy it is to actually change color, the decision process is painfully slow. That is because the designers get dragged back into it. Branding gets dragged into it. If there is advertising or collateral with a single themed color, they get dragged into it. Sometimes when trademarks are involved, lawyers get dragged into it.

Check the colors of your release candidate early, if something needs to be changed, you want as much lead time on it as possible.

Accessibility Fail Fast Step 4: Is it an App? Turn your mobile device sideways

The new guideline in WCAG 2.1, 1.3.4 requires that unless one particular device orientation is essential to the purpose of your app, it *must* rotate.This is not a common exception: think-piano keys, or check depositing systems. People who use devices in fixed frames on their wheelchairs may be unable to turn them. Reorienting your display automatically allows everyone to participate.

Accessibility Fail Fast Step 5: Keyboard Accessibility

If you don’t support full keyboard access, this is an automatic fail across the board. You are forcing people into touch/mouse modes and there are several groups of people that can’t do that. The following keys should work as expected:

  • Tab — After a page is loaded, press the tab key. The first tab should bring up the “skip to content” component. As you continue to tab, the keyboard focus should move through all interactive elements on the page in an order that makes sense to the user. Left ->Right / Top -> Down is expected for English, unless there is a logical reason to do something different.
  • Shift + Tab — “tab backwards”, i.e. should do the reverse of the tab key
  • Enter/Return /Spacebar — On a link, button, or list item — activates that item. On an object that can change state, toggles the state (i.e. collapsed to expanded, checked to unchecked)
  • Arrow Keys — Move through sets of objects or lists

Accessibility Fail Fast Step 6: Forms / Error Messages

Forms can implicate ten of the WCAG guidelines above and beyond the standard language/color/alt-text/meaningful sequence guidelines that apply to all pages. Please don’t use this as a checklist (I hate checklists) but this is informative for people who have recently started their accessibility journey.

But wait, Sheri — your list is out of order???

Nope, this is the order that makes sense when you are testing, which is NOT how WCAG grouped its guidelines. 4.1.2 and 3.2.2 should be thought about when you are testing input, and all the error message tests should go together.

Accessibility Fail Fast Step 7: Custom Controls

When your designers and developers implement a custom control, the coders are responsible for all of the accessibility behavior associated with that control. The most common custom control is a tab where content underneath the tab changes as a new tab is selected. Another common custom control that is tricky to implement is master-detail where the data in the detail grid updates as a person scrolls through the master table going from record to record.

Conclusion

By doing these seven sets of accessibility checks on a new build, you should quickly know whether it is good enough that you want to continue to invest time in manual accessibility testing, possibly followed by VPAT creation. Any P0 defects discovered in these test should result in the build being rejected.

A good ratio for defects in an organization that is mature with respect to accessibility is 3:1 AA vs A. Another way of stating this is no more than 25 % of bugs you discover should be A-level. A-level bugs are blockers and can be hiding lots of defects behind them when you peel back that layer of the onion. Also, A-level defects are quite basic. Failing to follow A-level guidelines is a sign of a “training opportunity.” The Startup

0 comments on “Accessibility Fail Fast — Execution”

Leave a Reply