Notes on making UI Browser accessible

Continuing the discussion from UI Browser Documents:

Notes on making UI Browser accessible

2019-07-14

Group UI elements that are related, especially if the group is vertically oriented. See shouldGroupAccessibilityChildren.

Notify VoiceOver when onscreen content or layout changes.

Warn before user activates a control that opens a different app.

Support the VoiceOver rotor. See NSAccessibilityCustomRotor.

From Accessibility Programming Guide:

  • Assign a useful label. Every element that the user can interact with must have a meaningful value set for its accessibilityLabel property. Ideally, this label is a single word that briefly describes the control. Add, Play, Delete, Search, Favorites, and Volume all make ideal labels.

    Do not include the type of control in the label. For example, use Add not Add Button. The control’s accessibilityRoleDescription property already captures the control type. Also, to ensure that VocieOver reads the label with the correct inflection, the label should start with a capital letter. Do not put a period at the end. Finally, always localize your control’s label.

  • Modify the role description, if necessary. Accessibility clients use the accessibilityRoleDescription property when describing the control. Most of the time, the default value for the role description works perfectly well; however, you might find a few cases where you can make the control’s intent clearer by replacing the default role description. This is particularly true when you are using a standard control in a nonstandard manner.

  • Use help text to describe the effect. Accessibility clients use the accessibilityHelp property to describe the results of performing an action. Essentially, the help text acts like a tool tip.

    Use help text only when the results are not obvious from the control’s label. Just like the label, strive to make the help text as short as possible. Start with a capital letter. Begin with a verb and omit the subject. For example, use “Plays the song” not “This button plays the song.” Also, do not include a description of the action, gesture, view or control. Finally, always localize your help text.

  • Define links and groups to provide context. Visual users often know that sets of controls go together due to their proximity on screen. However, you must explicitly define these relationships before accessibility clients can use them as well. For example, a view could adopt the NSAccessibilityGroup protocol, indicating that its contents should be treated as a group of controls. Similarly, you can use the accessibilityLinkedUIElements property to define the relationship between a list item and the contents displayed in different pane or window. You can also use the accessibilityTitleUIElement to specify the static text element that acts as this control’s label.