Welcome to our series on the ICT Symposium’s Mobile Site and Native App Accessibility Testing. For the next couple of months we will be posting a couple of times a week! We will be posting a series of articles to help testers and developers determine and improve the accessibility of their mobile websites and apps. All this information is already online in Word format, so if you can’t wait check out our page on Mobile testing. Our previous article was Native App Accessibility Testing, Step 2: Define application functionality – Day Four, or check out our page with links to all the published Mobile Site and Native App Methodology articles.
Step 3: Critical issues
The Mobile Site and Native App sub-committees identified a series of “traps” in mobile sites and native apps. They are called “traps” because the committees deemed them equivalent to the keyboard trap in WCAG2, where when a user enters into an element, they can’t escape if they are a keyboard-only user. You often see this keyboard trap in elements like video players.
A mobile trap is when a user is trapped within a component and cannot escape without closing the browser or app. There are many more traps on mobile sites and native apps than on desktop. Traps are considered critical accessibility issues as they can completely stop the user from using the app or mobile site.
Mobile site and native app traps are divided into categories based on how the function traps the user.
Exit trap
Ensure there is always an accessible actionable item (e.g. a close button that meets color contrast requirements and has an accessible name) that closes any feature that overlays the current page (such as a full-page ad).
Example
 | In this example, an ad takes up a majority of the mobile page and does not have any way to close it. |
Swipe / scroll trap
Ensure you do not override standard mobile touch functions (swiping, scrolling, etc.) on the majority of the page.
Example
 | In this example, the user is unable to scroll up with touch. The screen will only move by activating the up arrow button. |
Text-to-speech trap
This trap only occurs in native apps, not mobile sites. If the app has an ability to provide content via text-to-speech, the screen reader user must be able to pause or stop the app speaking in a simple manner (e.g. by performing a swipe on a screen).
Example
 | In this example, once text-to-speech is activated within the app, screen reader users cannot stop it. |
Headset trap
Headset users must always be able to pause media (audio or video) content by using the Pause/Play control on the headset.
Layer trap
The user should not be trapped on a non-visible layer. This trap is most commonly encountered by screen reader users.
Example
In the following example, the screen reader user cannot access the menu, as the screen reader focus stays on the parent layer (1st screenshot) when the menu is opened (2nd screenshot).
Once critical issues have been addressed, testing can move on to other mobile-specific issues.
Up next
Up next for Mobile Site and Native App Accessibility Testing is Step 4: Test mobile-specific issues.
Contributors
This document was developed by the ICT Accessibility Testing Symposium Mobile Sub-Committee. Members include: Gian Wild (Co-Chair), Peter McNally (Co-Chair), Brent Davis, Corbb O’Connor, Karen Herr, Kathryn Weber-Hottleman, Kathy Eng, Laura Renfro, Megha Rajopadhye, Mona Rekhi, Morgan Lee Kestner, Rafal Charlampowicz, Ryan Pugh, Steve Sawczyn, Sunish Gupta, Tom Lawton and Chris Law This document was developed by the ICT Accessibility Testing Symposium Native App Sub-Committee. Members include: Gian Wild (Co-Chair), Jennifer Chadwick (Co-Chair), Kathy Eng, Ryan Pugh, Kathryn Weber-Hottleman, Brent Davis, Laura Renfro, Peter McNally, Karen Herr, Steve Sawczyn, Sunish Gupta, Tom Lawton, Sam Bouchat, Rafal Charlampowicz, Damon Wandke, Morgan Lee Kester, Mona Rekhi, Corbb O’Connor and Chris Law.