Voice Control is an Assistive Technology for the iOS platform that allows users to speak structured commands and interact with items on screen. It is a powerful testing tool and should be your go to option within your development process.

Objection: But, shouldn't we test everything everywhere?

Answer: NO! It is unfair to expect everyone to be experienced enough to test with all technologies. This concept is covered deeply in Creating an Efficient iOS Accessibility Test Plan.

For the remainder of this article we will focus on:

• A very simple accessibility test you can do in 10 seconds.
• A more thorough version of this test in a condensed process outline.

Let's go!

The 10 Second iOS Accessibility Test

You can't test everything in Voice Control, however, the things you can test you can test very quickly! Below is a process that when practiced can test many aspects of iOS accessibility with a quick glance. This process looks like this:

Prerequisite - Turn On Voice Control

In order to test with Voice Control... Voice Control must be on!

Don't forget to turn on Voice Control :).

Step 1 - Show Names

The Show Names command displays the AccessibilityLabel above controls that are detected as interactive!

This simple test allows us to confirm two things:

1. Our controls interactive state is being detected properly.
2. That our controls have an effective AccessibilityLabel!

Confirming these two pieces of information for the entire screen at a glance is very valuable and covers a wide range of Accessibility Blockers and Critical issues.

Step 2 - Show Numbers

The "Show Numbers" command is similar to "Show Names" and provides the same value when it comes to interactivity blockers. However, you exchange information about labelling for information about Focus Order!

This simple test also allows us to confirm two things:

1. Our controls interactive state is being detected properly.
2. That our controls have a reasonable Focus Order.

Again we get a lot of value with very little effort!

A More Complete Voice Control Testing Process

If the above two tests are all that you do you have done quite a bit! However, there isn't a 100% guarantee that items with boxes are interactive. Occasionally they can overlapping hit targets.

If you need more complete validation the full Voice Control testing process would look like this:

1. Pre-req: Turn on Voice Control
2. For Each: Unique Screen State
   1. Say: Show Names
      1. Confirm: That the label above each control is reasonable and concise.
      2. Confirm: The label DOES NOT contain Trait/Value/State information.
   2. Say: Show Numbers
      1. Confirm: That there is a number above all interactive controls.
      2. Confirm: The number ordering is reasonable.
3. For Each: Unique Component
   1. Say: Tap {LABEL}
      1. Confirm: The default action is executed.
   2. Say: Show Actions for {Label}
      1. Confirm: All Custom Actions show up in the actions list.
      2. Note: Only required for controls with Custom Accessibility Actions.
   3. Say: Increment/Decrement {Label}
      1. Confirm: The control responds to both commands.
      2. Note: Only required for controls with the Adjustable Trait.

Conclusion

Voice Control testing is really powerful because it is fast and covers a very important spectrum of accessibility issues including your most common assistive technology blockers. As someone experienced with this process you can perform a portion of it in less than 10 seconds and the more thorough test does not take much longer than that. This makes Voice Control testing the perfect testing to add towards the beginning of your development process and should be performed before every release... ideally by engineers when making pull requests.