A Brief Overview of Accessibility

Overview

Firefox iOS should strive to implement accessibility for new features, as well as add missing accessibility for existing features. This document will show you the few easy steps to take to ensure that this is done well.

Apple's Built-in Accessibility

Many Apple UI elements have accessibility built in (UIButton, UISwitch, UILabel, etc). This means that their isAccessibiltyElement property is set to true by default. If you're creating a custom element and want it to be accessible for VoiceOver, you want to make sure to enable this.

Accessibility Tools

accessibilityLabel

Many Apple UI elements have some default behaviour for reading accessibility. For example, a UILabel will read its contents. However, some elements may not have text, or you wish for VoiceOver to read something specific. This is where .accessibilityLabel comes into play. Anything set here is what VoiceOver will read. This always needs to be localized.

accessibilityTrait

Many standard Apple UI elements have specific traits enabled on them. For example, a UIButton will read "Description of button, button". That "button" is added by the UIAccessibilityTrait.button that a UIButton has. If you wish to set specific traits on an element, you would do this using the .accessibilityTrait call on that object, and then either pass in a singular trait or a collection of traits. These traits should be reflective of the element.

Always review traits that are read on Voice Over elements. For example:

• If there's a click gesture listener on an image, that image should probably have the .button trait.
• Clicks that brings the users outside the application should probably have the .link trait.
• Section headers should have the .headers trait.
• Useful article about accessibility traits in mobile: Deque Article Always try to think as a user that can't rely on visual cues, if the context is clear enough to be interacted with and understood.

accessibilityHint

Hints can be turned off by the users, but aren't less useful to give more context as to what an element on the screen does. For example, we give hint to the user when they scroll in the tab tray, to indicate how many tabs are visible in their view port in respect to their total number of tabs. Another example, a switch might read "Toggle logo, switch, on". By setting the accessibilityHint to something like, "Toggles the logo on the homepage cycling wallpapers", VoiceOver will read this additional phrase after phrase (which contains the accessibility label, hint and traits), giving more context about UI element.

VoiceOver UIImage Recognition

One awesome feature of iOS is that it has image recognition. The VoiceOver Image Recognition feature can be enabled by navigating to Settings > Accessibility > VoiceOver > VoiceOver Recognition > Image Descriptions > ON. After it reads your accessibilityLabel content, it will follow with a description of the image. This feature can be tested by navigating to the Photos app and verifying the difference in image description with the feature turned on and off.

This may be useful in many aspects of web browsing, but, if you're trying to control how your UI is represented by VoiceOver, you may want to disable this. This is done using the .accessibilityTraits = .none on the UIImageView itself.

Additional Information

accessibilityIdentifier

This is a confusingly named trait of any UI object and is an identifier used for UI tests, generally. It is not part of user facing accessibility features for iOS. UI should be built in a testable way, so accessibilityIdentifiers should be added to required objects. An easy way of organizing reusable identifiers can be found in our AccessibilityIdentifiers struct.

Grouping Elements

Custom UI elements often needs to be grouped together, so the user can quickly know the content of a cell without having to navigate all elements inside that element. A good example could be the Pocket cells. There's an image, a title and a description. As a user, it's much more preferable to have the whole cell selectable with Voice Over, and having the title + description read back to back than having to swipe two times to have the title, then the description being read out loud. In that case, the labels in those cells need their accessibilityElement turned off, and the parent cell needs it's accessibilityElement turned on, and its accessibility label can be set as the combined text of the title and the description.