Mobile Site and Native App Accessibility Testing, Step 3: Test critical issues – Exit trap – Day Eight

Welcome to our series on the ICT Symposium’s Mobile Site and Native App Accessibility Testing. For the next thirty working days we will be posting once a day! 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 Mobile Site and Native App Accessibility Testing, Step 5: Test mobile assistive technology and feature support – Day Seven, or check out our page with links to all the published Mobile Site and Native App Methodology articles.

Critical issue – 1.1: Exit trap

Methodologies: Mobile Site and Native App

Applies to: All users

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 or page that overlays the current page (such as a full-page ad) or an important mobile feature.

About this requirement

When a feature, such as a pop-up or an advertisement is displayed, it is imperative that all users have a way to dismiss it and that this method complies with all WCAG criteria. Incorrect implementation can present significant barriers to assistive technology users, potentially trapping them within the new feature and blocking them from returning to the underlying site or previous page. Many pop-ups and ads can be closed by tapping somewhere else on the original page, but this is not functionality that is available to all users. For example, screen reader users often cannot use touch gestures as they are captured by the screen reader. In the case of swipe gestures, this is because when the screen reader is on, the swipe right gesture moves you to the next focusable item and doesn’t perform as a swipe mechanism. For example, if you require your user to swipe right to complete a purchase, when the screen reader is on, the swipe right gesture moves you to the next focusable item and doesn’t complete the purchase. You must be able to perform the same action, by using a link, an up or down swipe, screen reader rotor action, or some other gesture.

There are two main features that can contain this trap:

• Ads that overlay the current page (please note that even ads that do not appear to overlay the full page may present an Exit trap to keyboard or assistive technology users)
• Pop-ups that overlay some or most of the page

There are six main ways that a user can get trapped in a feature:

• There is no Close actionable item
• The only way to close the feature is to tap outside the feature which can be impossible for assistive technology users, such as screen reader users, keyboard users, switch users and magnifier users.
• The user relies on a keyboard and the Close actionable item cannot be closed by a keyboard or does not have a highly visible keyboard focus indicator.
• The user relies on a screen reader and the Close actionable item is not accessible to a screen reader (usually due to the lack of an accessible name or a failure of Change of State).
• The user has a vision impairment or is colorblind and the Close actionable item does not meet color contrast requirements or relies on color alone.
• The Close actionable item does not meet Touch Target, Inactive Space, Native UI requirements and therefore cannot be seen or actioned by some users.

Please note that this requirement is similar to the Layer Trap and Touch Gestures requirement. A failure of the Exit trap requirement is that a user cannot escape from the feature. A failure of the Layer Trap requirement is that the user is trapped on a non-visible layer. As a result, Layer Traps are also often Exit Traps as some users cannot access the visible layer in order to dismiss it. A failure of the Touch Gestures requirement is that the user cannot choose content or a page (i.e. they are not trapped).

About timed ads

It is the opinion of this committee that timed ads (where the user cannot dismiss an ad until a a pre-set amount of time has passed – i.e. they are forced to watch the ad) are not a violation of the Exit Trap requirement, but only if:

• The timing function is accessible to all users
• When the Close actionable item is added it is announced to all users and meets accessibility requirements

This behavior is acceptable as this delay may be integral to the intended functionality of the ad (e.g. the advertisement may be required to remain visible for a certain period of time).

A note about iOS testing

As the keyboard only works in iOS when VoiceOver is enabled it is likely that a feature or Close actionable item that is not actionable by the screen reader is not actionable by the keyboard (and vice versa).

How to test – Non-timed features

1. Activate each actionable item that triggers a non-timed feature.
2. Is there a Close feature?
3. If there is a Close feature is it an actionable item (and not reliant on touch)?
4. If there is a Close actionable item is it accessible to the screen reader?
   1. Close the feature.
   2. Turn on the screen reader.
   3. Activate the actionable item that triggers a non-timed feature.
   4. Can controls within the feature receive screen reader focus?
   5. Are the name/role/value of each control properly conveyed?
   6. Can interactive elements be activated via the screen reader?
   7. Can the feature be dismissed via the Close actionable item using the screen reader?
5. If there is a Close actionable item can it be activated by the keyboard?
   1. Close the feature.
   2. Connect an external keyboard and (in iOS only) turn on the screen reader.
   3. Activate the actionable item with the keyboard that triggers a non-timed feature.
   4. By pressing tab or the up and down arrow keys, does each control receive keyboard focus?
   5. Is keyboard focus visually indicated and does the focus comply with proper color contrast ratios?
   6. Can interactive elements be activated via the keyboard?
   7. Can the feature be dismissed via the Close actionable item using the keyboard?
6. If there is a Close actionable item does it have an accessible name and use native UI elements?
7. If there is a Close actionable item does it meet color contrast requirements?
8. If there is a Close actionable item does it meet Touch Target and Inactive Space requirements?

How to test – Timed features

1. Activate each actionable item that triggers a timed feature.
2. Is the timing of the feature visible?
3. Once the timing is completed, is there a Close feature?
4. If there is a Close feature is it an actionable item (and not reliant on touch)?
5. If there is a Close actionable item is it accessible to the screen reader?
   1. Close the feature
   2. Turn on the screen reader.
   3. Activate the actionable item that triggers a timed feature.
   4. Is the timing announced by the screen reader?
   5. As the timing changes, is this announced by the screen reader?
   6. When the timing ends, is this announced by the screen reader? Alternatively, is the Close actionable item announced by the screen reader once the timing ends?
   7. Can controls within the feature receive screen reader focus?
   8. Are the name/role/value of each control properly conveyed?
   9. Can interactive elements be activated via the screen reader?
   10. Can the feature be dismissed via the Close actionable item using the screen reader?
6. If there is a Close actionable item can it be activated by the keyboard?
   1. Close the feature
   2. Connect an external keyboard and (in iOS only) turn on the screen reader.
   3. Activate the actionable item with the keyboard that triggers a timed feature.
   4. By pressing tab or the up and down arrow keys, does each control receive keyboard focus?
   5. Is keyboard focus visually indicated and does the focus comply with proper color contrast ratios?
   6. Can interactive elements be activated via the keyboard?
   7. When the timing ends can the Close actionable item be activated by the keyboard?
7. If there is a Close actionable item does it have an accessible name and use native UI elements?
8. If there is a Close actionable item does it meet color contrast requirements?
9. If there is a Close actionable item does it meet Touch Target and Inactive Space requirements?

Examples

Pass 1 – Accessible hamburger menu

In the SF MOMA website, when the hamburger menu is closed the icon is a hamburger menu (see Figure 1). When the hamburger menu is open, this hamburger menu changes to a close link which can close the menu (see Figure 2)

Figure 1: Accessible hamburger menu (closed)

Figure 2: Accessible hamburger menu (open)

Pass 2 – Accessible hamburger menu

The Age website hamburger menu has an accessible name and icon which changes whether the menu is open or closed.

Figure 3: Accessible hamburger menu (open)

Figure 4: Accessible hamburger menu (closed)

Pass 3 – Accessible Menu

In the AccessibilityOz website there are two non-standard controls: the navigation menu and the slideshow controls. When the navigation is closed, the menu icon is “Show menu.” When the navigation is open, the menu icon is “Close menu.”

Figure 5: Accessible menu (closed)

Figure 6: Accessible menu (open)

Pass 4 – Accessible menu

In the Portland Audubon site, the menu opens over the content of the website. However, it can be closed by activating the menu close button.

Figure 7: Accessible menu (closed)

Figure 8: Accessible menu (open)

Pass 5 – Accessible close feature (link)

In this website a pop-up appears with additional information about a particular word. There is a close button to the left of the pop-up which meets color contrast requirements.

Figure 9: Accessible close feature (link)

Pass 6 – Accessible close feature (link)

The sign in pop-up can be closed with a close button that meets color contrast requirements.

Figure 10: Accessible close feature (link)

Pass 7 – Close button is accessible to the keyboard

With the hamburger menu open, activating the hamburger menu again with the keyboard closes the menu.

Figure 11: Close button is accessible to the keyboard

Pass 8 – Close button is accessible to the keyboard

The Cookie policy pop-up has a button called “Accept policy” that can be activated by the keyboard.

Figure 12: Close button is accessible to the keyboard

Up Next

Up next for Mobile Site and Native App Accessibility Testing is Critical issue – 1.2: Swipe and / or Scroll Trap.

Access the complete Mobile Site and Native App Accessibility Testing Methodology

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.