Operable

Guideline 2.1 Keyboard accessible

Make all functionality available from a keyboard.

What should the tester do?

Make sure the user can navigate the app and operate it with a keyboard or other external assistive technology.

How?

Luckily, to test this one, you don’t need a keyboard or assistive technology – it can easily be tested with an accessibility setting called Switch Access or Switch Control, depending on the platform you are testing. You can read more about it in the Accessibility Settings section of this handbook.

What to report?

All issues that make the user unable to use the app with this setting turned on. They can be something like:

• Some elements cannot be focused on with Switch Access.
• Some elements cannot be tapped with Switch Access.
• Some elements are Keyboard Trap – you cannot navigate away from them once they are in Focus.
• Any other issues that make it hard or impossible to finish main flows in the app with the option turned ON.

Guideline 2.2 Enough time

Provide users enough time to read and use the content.

Success Criterion 2.2.1 Timing Adjustable

What should the tester do?

For each time limit that is set by the content, at least one of the following is true:

• The user is allowed to turn off the time limit before encountering it; or
• The user is allowed to adjust the time limit before encountering it over a wide range of at least ten times the length of the default setting.
• The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, a dialog is shown to ask the user they are still there and if they want to continue), and the user is allowed to extend the time limit at least ten times; or
• The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
• The time limit is essential, and extending it would invalidate the activity; or
• The time limit is longer than 20 hours.

How?

Exploratory testing

What to report?

• Whenever there is a time limit in the app, and the user cannot do one of the things mentioned above (think creating a transaction in the banking app, making a purchase in an e-commerce app, or creating and saving content in any content creation app).
• Remember that some of them will probably require a discussion with the rest of the team due to security issues.

Success Criterion 2.2.2 Pause, Stop, Hide

What should the tester do?

Test that for moving, blinking, scrolling, or auto-updating information that:

• starts automatically
• lasts more than five seconds (for moving, blinking, and scrolling only)
• is presented in parallel with other content

There is a mechanism for the user to pause, stop, or hide it or to control the frequency, unless the moving, blinking, scrolling or auto-updating is part of an activity where it is essential. If removed, it would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform.

How?

Exploratory testing

What to report?

All breaches of the rule explained above. Look for animations, auto-updating content, and similar.

Guideline 2.3 Seizures and physical reactions

Do not design content in a way that is known to cause seizures or physical reactions.

What should the tester do?

Make sure that designers conform to this one :) It would probably be caught in the design review, but another check would be useful. You need to check that the app does not contain anything that flashes more than three times in any one-second period, or that the flash is below the general flash and red flash thresholds.

How?

Good old exploratory testing again.

What to report?

All the elements that look suspicious to you – some of them cannot be noticed with the bare eye, so you can ask the developer or designer to double-check on the ones that look suspicious to you.

Guideline 2.4 Navigable

Provide ways to help users navigate, find content, and determine where they are.

What should the tester do?

Few things to make sure the page is navigable to both users using it in a regular way and to users using it with accessibility settings/technology such as screen readers or switch access:

• Test that there is a way for the user to skip blocks of content that are repeatable and have a lot of elements (think stories on Instagram or 100 recipes in a carousel in a cooking app).
• Make sure that all screens have titles that describe the topic or purpose.
• Make certain that if the app can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
• The purpose of each link which the user may encounter on the screen is clearly stated (e.g. there should be no “Tap here” links – every link provided should have a clear name, e.g. “Privacy Policy”).
• Make sure that navigation through the app is clear and comprehensible and that it is easy to navigate to all the parts of the app. This is kind of vague and depends highly on the UX of the app – but if you have something very odd (an important part of the app is hidden 4 or 5 layers deep in the navigation, and there is no other option to reach it), raise it to the team.
• Content in the app has clear headings.
• Focus is visible (e.g. when you use a screen reader or a switch access tool, the element in focus has an outline).

How?

Exploratory testing combined with screen reader and Switch Access/Switch Control.

What to report?

All breaches of the rules above. In cases where: big blocks of content are not skippable; titles are not on the screens; the ordering of elements doesn’t make sense when navigated with screen reader/switch access tools; links don’t have proper labels; the focus is not visible; headings in the content are not readable with screen readers, and similar.

Guideline 2.5 Input modalities

Make it easier for users to operate functionality through various inputs beyond the keyboard/tapping on the screen.

What should the tester do?

There are a few important things to check when it comes to this guideline:

• Check that input fields and other components (e.g. buttons) have a proper label (and it’s the same one as the one read out loud by the screen reader).
• Any action that can be done with a gesture or motion can also be done by the UI component.
• Making actions with gestures or motions can be turned off (e.g. shaking to hide the balance in the Monese app) to avoid accidental actuation.
• And one thing that is Level AAA so it’s not obligatory, but it’s fairly easy to check and improves UX significantly – touch targets. You can check their size with the Accessibility Scanner/Accessibility inspector.

How?

Exploratory testing/screen readers/Accessibility Inspector/Accessibility scanner

What to report?

• Missing labels
• Actions that require complex gestures or motions and don’t provide any alternative (they are usually hard/impossible to do with a screen reader or switch access)
• Actions that require gestures or motions that cannot be turned off (e.g. shake to undo)
• Any touch targets that are not in line with the iOS/Android accessibility guidelines (Accessibility Inspector and Accessibility Scanner will detect them)