24.6 · Building and testing accessible components

The first pass covered what VoiceOver says. This section is about the code you write for it: what you can and cannot test headlessly, custom-drawn controls, modal screens and the gestures VoiceOver reserves, and how to control pronunciation.

Mental model. Standard controls are accessible only while an assistive technology is running; everything custom needs explicit elements, frames, traits and, where speech matters, speech attributes.

Components

Defaults, custom drawing, modality, pronunciation.

  1. What can a unit test assert about accessibility properties, and why does a standard UIButton report no label in a plain test process? 24.6.1 · L3
    Reading accessibility properties from a unit test or a command-line process is less informative than it looks. In the check below (run in the iOS Simulator…
  2. How do you make a custom-drawn control (a canvas, a chart or a hand-built segmented control) accessible with UIAccessibilityElement? 24.6.2 · L5
    A view that draws its own parts with Core Graphics has one view and no sub-views, so the accessibility tree has nothing to expose. The pattern is a container…
  3. How do you make a custom modal screen work with VoiceOver: modal views, the escape gesture and the magic tap? 24.6.3 · L3
    A visual modal (a custom dialog, a popup menu, a bottom sheet you built yourself) dims what is behind it, but VoiceOver does not see dimming: it will happily…
  4. How do you control how VoiceOver pronounces text: spell-out, language, punctuation and IPA? 24.6.4 · L3
    VoiceOver speaks with the voice and language of the user’s settings, which is wrong for part of your text more often than you would expect: an order code…

More in Accessibility & localization