Assistive technology guide, VoiceOver on iPhone testing steps

We’ll take you step by step through how to test a component or feature with VoiceOver screen reader on iPhone. Test with the latest version available.

How to turn VoiceOver on / off

VoiceOver screen reader for iOS comes already installed on iPhones. It's recommended to use a shortcut to turn VoiceOver on or off.

  1. Go to ‘Settings’, then within the ‘Accessibility’ menu look for ‘Accessibility Shortcut’, make sure VoiceOver is selected here. This shortcut will enable you to toggle VoiceOver on or off, from any screen or web page, at any time.
  2. With the VoiceOver shortcut enabled, on newer iPhones, you will now be able to triple click the side button to toggle VoiceOver on or off at any time. With older style iPhones the shortcut is a triple click of the ‘home’ button.
  3. If at any time you would like to stop VoiceOver while announcing something, do a two-finger tap anywhere on the screen.
  4. To activate an item, once it has focus, double tap anywhere on the screen.
  5. There are many VoiceOver gestures that you can use, though only a few are needed to perform the testing steps, all of which are explained below.
Back to page contents

It's speaking too fast

If you are new to VoiceOver, you may find the rate in which announcements are made too quick to understand. To find a speaking rate that you are comfortable with:

  1. Select ‘Speaking rate’ in the rotor menu by doing a two-finger rotation gesture (similar to how you might turn a dial with your thumb and finger) until you hear ‘Speaking rate’ announced
  2. The speaking rate can now be adjusted by swiping up or down
  3. Swipe down to decrease the speaking rate
  4. Swipe up to increase the speaking rate
Back to page contents

Testing in a foreign language

When testing with assistive technology it's important to test with content in a language that you can understand and with a language that is supported by the assistive technology. For further information see the assistive technology testing in a foreign language guide.

Back to page contents

Testing steps

We’ll take you step by step through how to test a component or feature. Following the same steps every time, ensures that everyone is testing using the same methods and using the most common techniques. The steps also enable anyone, in any role, to use VoiceOver for the first time.

To become more familiar and proficient using assistive technology, resist the temptation to cheat, always try to navigate like a user would.

As you go, make notes of any bugs you find.

Step 1 - Open Safari

Open Safari, this is the most used browser by VoiceOver users.

Note: VoiceOver is an Apple product built primarily for other Apple products such as Safari, while VoiceOver will work with other browsers you may encounter bugs which aren’t present in Safari; the default VoiceOver browser.

Back to steps

Step 2 - Go to the testing url

Navigate to or type in the testing url.

Back to steps

Step 3 - Turn VoiceOver on

Triple click the side button to turn VoiceOver on via the ‘Accessibility shortcut’.

Back to steps

Step 4 - Get in position to start testing

Get in position to start testing by navigating as follows, depending on the context on which you are testing your component, either within a page, at the top of a page or in isolation. This will ensure that when you start testing you don’t miss out any elements within the component that you can’t see, such as:

Testing a component within a page

Navigate as follows, to the last element in the component before the component you're going to test.

  • Swipe right until you reach the last element in the component before the component you're going to test.
  • If the component you're going to test starts with a heading, you may find it quicker to navigate to that heading via the rotor menu, then swipe left until you reach the last element in the component before the component you're going to test.
Testing a component at the top of a page or in isolation

Ensure you are right at the top of the page.

  1. To select the first item on the screen do a four-finger tap near the top of the screen
  2. Swipe right through the items in the address bar to the web page

Swipe right to move to the next item, swipe left to move to the previous item. You can swipe right or left anywhere on the screen. Ensure it’s a quick swipe, taking no more than a split second, otherwise what you have physically touched on the screen could be navigated to and read out instead.

Back to steps

Step 5 - Navigate through all items

You are now ready to start testing.

  1. Swipe right, you should enter the component.
  2. Listen to what's announced and check that the semantics and announced content match the screen reader UX. If the documented screen reader UX is missing, ask UX for this before continuing.
  3. If you need to hear what was announced again, swipe left to the previous item, then swipe right again.
  4. Swipe right through all items in the component, listening to what’s announced, until you reach the first item in the component after the component you're testing, or the bottom of the page if testing in isolation.
Navigating through all items bug examples
Back to steps

Step 6 - Navigate by headings

  1. Select ‘Headings’ in the rotor menu.
  2. Get in position to start testing, swipe up to navigate through headings until you reach the last heading in the component before the one you're testing, or if testing in isolation (or there are no other headings above) select the first item on the screen by doing a four-finger tap near the top of the screen.
  3. Swipe down to read the first heading in the component you're testing. Check that the semantics and announced content match the screen reader UX.
  4. If you need to hear what was announced again, swipe up to the previous heading, then swipe down again.
  5. Swipe down to go through all headings in the component, listening to what’s announced, until you reach the first heading in the component after the component you're testing, or the bottom of the page if testing in isolation (or there are no other headings).
Rotor menu

You can select a method of navigation in the rotor menu for swiping up or down, by doing a two-finger rotation gesture (similar to how you might turn a dial with your thumb and finger). For example, if you select ‘Headings’ in the rotor menu by doing a two-finger rotation gesture until you hear ‘Headings’ announced, headings will now be selected as the method of navigation when swiping up or down.

Adding items to the rotor menu:

  1. If VoiceOver is on, triple click the side button to toggle VoiceOver off or with older style iPhones triple click the ‘home’ button
  2. Go to the ‘Accessibility’ menu in ‘Settings’
  3. Within the 'VoiceOver' menu to go 'Rotor'
  4. Check the desired item, such as 'Landmarks' or 'Tables'
  5. Navigate back to your testing url
  6. To resume testing, triple click the side button to toggle VoiceOver on or with older style iPhones triple click the ‘home’ button
Navigating by headings bug examples
  • A heading is defined in the screen reader UX, you swipe down and nothing is announced
  • A heading was announced and none were defined in the screen reader UX
  • A heading is announced twice
  • What's announced doesn’t match the screen reader UX
Back to steps
  1. Select ‘Links’ in the rotor menu.
  2. Get in position to start testing, swipe up to navigate through links until you reach the last link in the component before the one you're testing, or if testing in isolation (or there are no other links above) select the first item on the screen by doing a four-finger tap near the top of the screen.
  3. Swipe down to read the first link in the component you're testing. Check that the semantics and announced content match the screen reader UX.
  4. If you need to hear what was announced again, swipe up to the previous link, then swipe down again.
  5. Swipe down to go through all links in the component, listening to what’s announced, until you reach the first link in the component after the component you're testing, or the bottom of the page if testing in isolation (or there are no other links).

To activate a link, once it has focus, double tap anywhere on the screen.

Navigating by links bug examples
  • A link or button is defined in the screen reader UX, you swipe down, focus moves but nothing is announced
  • A link was announced and none were defined in the screen reader UX
  • A link is announced twice
  • What's announced doesn’t match the screen reader UX
Back to steps

Step 8 - Navigate by landmarks

  1. Select ‘Landmarks’ in the rotor menu. If that method of navigation isn't present, add it to the rotor menu.
  2. Get in position to start testing, swipe up to navigate through landmarks until you reach a landmark in a component before the one you're testing, or if testing in isolation (or there are no other landmarks above) select the first item on the screen by doing a four-finger tap near the top of the screen.
  3. Swipe down to read the first landmark in the component you're testing. Check that the semantics and announced content match the screen reader UX.
  4. If you need to hear what was announced again, swipe up to the previous landmark, then swipe down again.
  5. Swipe down to go through all landmarks in the component, listening to what’s announced, until you reach the first landmark after the component you're testing, or the bottom of the page if testing in isolation (or there are no other landmarks).
Navigating by landmarks bug examples
  • A landmark is defined in the screen reader UX, you swipe down and nothing is announced
  • A landmark was announced and none were defined in the screen reader UX
  • A landmark was announced without a label
  • What's announced doesn’t match the screen reader UX
Back to steps

Step 9 - Accessibility acceptance criteria

Accessibility acceptance criteria can be used for additional manual testing steps specific to your component and documented screen reader UX, specific VoiceOver gestures maybe needed.

  1. Read the accessibility acceptance criteria. If the accessibility acceptance criteria is missing, ask your team's business analyst for the criteria before continuing.
  2. Check that any criteria that is specific to using a screen reader is met with VoiceOver on iPhone.
Back to steps

Step 10 - Components with a table

  1. Select ‘Tables’ in the rotor menu. If that method of navigation isn't present, add it to the rotor menu.
  2. Get in position to start testing, swipe up to navigate through tables until you reach a table in a component before the one you're testing, or if testing in isolation (or there are no other tables above) select the first item on the screen by doing a four-finger tap near the top of the screen.
  3. Swipe down to the first table in the component you're testing. Check that the number of rows and columns announced is correct, and that a table caption was announced if one was defined in the screen reader UX. If you need to hear what was announced again, swipe right to the previous item, then swipe left.
  4. Select ‘Rows’ in the rotor menu, tables rows are now selected as the method of navigation when swiping up or down. Navigate all table rows. Swipe right or left to navigate through all table columns. Check that the semantics and announced content match the screen reader UX.
  5. Swipe down to go through all tables in the component, repeating the above steps, listening to what’s announced, until you reach the first table after the component you're testing, or the bottom of the page if testing in isolation (or there are no other tables).
Navigating by tables bug examples
  • You swipe down and nothing is announced
  • Number of rows and columns announced isn't correct
  • A table was announced without a caption
  • Table headings aren't announced when moving through table data
  • A table was announced and none where defined in the screen reader UX
  • What's announced doesn’t match the screen reader UX
Back to steps

Step 11 - Document any bugs

Document any accessibility bugs found, include as much information as you can, including information on how to replicate the issue and the bug priority level.

Note, this guide takes one approach, there are other ways you could do this. Back to top