iOS design criteria

This guide aims to present the different accessibility criteria for getting an accessible iOS application.
Each criterion explains for whom it is important, when it can be implemented, why it is important and the corresponding accessibility rule.

Images

Access the information included in images for users who cannot access it.
Blocking point: an image without textual description is unusable by people with visual impairments or those that cannot display images (mobile, low bandwidth…).

Target: everyone, especially people with visual impairments.
When: as of design and during development.

Images are often used to convey a lot of information.
The blind cannot see the images, it is important that they have an alternative that gives all the information conveyed by the image.

In the case of an image containing text, this text will be used for the alternative.
In the case of an image that provides information as a graph, drawing or other, the alternative will contain all necessary information in the image.

Some images are used for decorative purposes: these pictures do not require alternative.
By default, pictures are not vocalized by the VoiceOver screen reader.

Illustrations in the application are also considered decorative images.
The rule is the same: there is no alternative text to add.
Icons are, conversely, widely used as buttons for various features. So they need relevant text alternatives.

The alternative of an image is set via the accessibilityLabel attribute (using the UIAccessibility protocol available on any children of UIView).

complete example of decorative picture and informative icon


By decomposing the image:

  • example of decorative picture no accessibilityLabel
  • example of informative icon - parameters buttonView.accessibilityLabel = "example_image_edit_accessibilityLabel".localized
  • example of informative icon - edition buttonView.accessibilityLabel = "example_image_settings_accessibilityLabel".localized
  • Images with information must convey this information through their text alternative.
  • Decorative images have no alternative text.


  • Colours

    Ease of reading for all users, especially the visually impaired, or people in a very bright environment (outdoors).
    Allow users who cannot distinguish colours or sensory information (colour blind, visually impaired, hearing impaired, mobile users in bright environment or in noisy environments…) to access the same information by other means.

    Target: everyone, especially people with visual impairments, elderly people and people with vision problems (colour blindness, vision contrasts...)
    When: as of the design phase and during development.

    Colours have a very important role in the transmission of information.
    Some colours are associated with concepts or feelings but we must never forget the part of the population that does not correctly distinguish colours.

    The bold font type will allow a weaker contrast for the lowest font sizes.


    The normal font type will require a higher contrast than the previous case.


    With Dynamic Type whose purpose is to increase the font size according to the user settings, the contrast isn't necessary fixed and must be adapted to the text size.


    Adding different forms to differentiate the information provided only by colors may unnecessarily overlay the graphic interface if the user doesn't need them.

    In this case, the Differentiate Without Colour accessibility option (iOS 13 new feature) will allow this display only at the user's demand.

    Tools:

    • The Colour Contrast Analyser application can quickly measure colour contrast levels (free for Windows and Mac).
    • The Accessibility Inspector tool provides a specific Color Contrast Calculator feature that reaches the same purpose since Xcode 11.
    The label “film | 8:40 PM…” does not have enough contrast. It will not be readable by all users.
    screenshot showing text with poor contrast

    Example of information conveyed through valid and invalid colour:
    example of information conveyed through valid and invalid colour
  • Do not use colour as the only way of conveying information, indicating an action, requesting a response or distinguishing an element.
  • The contrast between the colour of the background and the text must be appropriate (can be measured with the Colour Contrast Analyser tool or with the Color Contrast Calculator feature of Accessibility Inspector under Xcode 11).
  • With the Dark Mode iOS 13 new feature, special attention must be paid to the contrasts used in the different themes and that can be modified with the Increase Contrast accessibility option.


  • Alternative text

    Provide access to application information to screen reader users.

    Target: everyone, especially people with visual impairments.
    When: as of design, content writing and during development.

    Text alternatives are at the core of mobile accessibility. Thanks to them, a visually impaired user can use an application without loss of information.

    As for images, it is important to add a text alternative when information is not available for the visually impaired/blind.
    This is the case of components that provide information by colour, shape, position, sound… On mobile, all components can have a text alternative, it is possible to enrich the native vocalization of an element, including a simple text.

    Space on mobile is reduced, we often use abbreviations for text.
    However, this raises an issue for users of screen readers that vocalize abbreviations literally.
    To correct these vocalizations, simply place a text alternative on the text.
    This alternative contains the expanded text.
    Note that VoiceOver can recognize some common abbreviations: for example, “etc.” is vocalized “etcetera”.

    Some images are frequently associated with text to give information.
    This is the case of “unread messages” when a badge shows the number of messages to read and which describes a “message”.
    In this case, the solution is to set a text alternative on the text that gives all the necessary information: for example,“3 unread messages”.
    One can also set this alternative on the images but in this case we must make the text “invisible” to the screen reader.

    The text alternative of an element is set via the accessibilityLabel, accessibilityHint, accessibilityValue and accessibilityTrait (using the UIAccessibility protocol available on any child of UIView).
    The order of vocalization is as follows: label, value, trait and hint. This order cannot be changed and vocalization is done only once.

    For more technical information on these attributes, please refer to the text alternatives on the developer guide.

    Below is a common example of an icon that is associated with a text (badge) to add information.
    In our case, the “mail” icon associated with the “3” in the badge makes us understand that we have “3 unread mails”.

    If no text alternative is added, two vocalizations will be read “unlabelled button” and “3”: it's obvious that we must add text alternatives.

    icon example coupled with the text that requires a text alternative

    • Elements that require an alternative should have one.
    • The alternative text must be clear and understandable.


    Title and header

    Allow users to identify the topic of a page, to locate and get a clear idea of the content of the page without having to read it.
    Ease the navigation.

    Target: everyone
    When: as of design and during content writing.

    The page title is the first element vocalized or seen on a mobile screen.
    It makes navigation easier for everyone: at any time, we know where we are in the application.
    A common mistake is to set the same title for every page of an application (or even no title at all).

    iOS headers allow structuring pages providing additional information.
    This information is useful to the accessibility API because VoiceOver can navigate through the headers (VoiceOver wheel, header mode): it allows the user to browse the page faster.

    Invalid example:
    example of irrelevant title (no title)

    • Each screen must have its own title allowing us to know where we are in the app navigation (together with the back button).
    • The elements identified as headers must be declared as headers for assistive tools.


    Element states

    Allow screen reader users to access components information, their status, their nature so they can use them without any difficulties.

    Target: everyone, especially people with visual impairments.
    When: during development.

    If an element does not vocalize its status, nature or state, the VoiceOver user is unable to understand what is happening on the screen.
    Not specifying that a view is unfolded or that we have tabs are very common examples.

    By default, tabs in iOS are accessible.
    Meanwhile, it is very common to customize the tabs’ look and feel, so it is the developer’s responsibility to provide the tab state and nature to the user via the corresponding accessibility attributes.
    An example is available in the “Standard components” section.

    Another common instance of elements that do not vocalize their state : expandable views.
    Again, thanks to the text alternative title of the view, we can vocalize the state of the view for VoiceOver users.

    To set this kind of information, use the accessibilityLabel and accessibilityTrait attributes.

    Any item whose status changes when using the application must vocalize its status through its text alternative.

    example of an expandable list that needs text alternative

    For example, an item that can be selected/unselected must vocalize its state through a text alternative.


    Standard components

    Improve user navigation and overall maintainability while reducing development time.

    Target: everyone.
    When: when choosing the libraries and during development.

    Accessibility is taken into account in native components (most of the time).
    Additionally, the use of standard components allows the user to be in a situation or behaviour that they are already used to.
    Navigation through a standard interface is more comfortable.

    Use native components as much as possible and change their appearance.
    If no standard component corresponds to the need, create a dedicated component based on a standard component while keeping the navigation and accessibility consistency.


    Touch target

    Improve the user experience providing a more comfortable environment.

    Target: everyone, especially people with motor impairments.
    When: as of design and during development.

    If a touch target of a component is too small, it can prevent some users from enjoying the application.

    This can lead to frustration that can result in uninstalling it.

    Each clickable element must have a large enough touch target.


    Valid example:
    interactive component example with a fairly large touch target

    Invalid example:
    interactive component example with a small touch target

    44 pt is the recommended touch target size for elements according to Apple (height and width).


    Ghost element

    Allow screen reader users to navigate within the application without having hidden elements disturbing the reading of the current view.

    Target: people with visual impairments.
    When: during development.

    Although invisible on the screen, some elements can be vocalized by the screen reader (elements positioned outside the visible area or hidden by other elements).

    The superposition of screens is frequent when designing mobile apps but it generates very heavy accessibility problems if it is not done properly from the start.
    A screen reader such as VoiceOver is able to read information from a view that is placed “below” another but if the user is able to interact with this view, it totally disturbs navigation and it quickly becomes impossible.

    Ghost elements are very common when creating custom alert dialogs. However, this kind of component can be accessible.
    Please refer to the corresponding section on the developer guide.

    Invalid example:

    In the example below, the custom alert dialog has a ghost element.
    When VoiceOver is activated it vocalizes the content behind the current view (shown in black).
    ghost element example

    With the screen reader, no invisible element must be read or take focus when reading a page.


    Content Control

    Allow users to keep control on the application and the screen reader user to avoid noise pollution which may affect navigation while improving a natural indexation.

    Target: everyone and especially people with visual and cognitive deficiency.
    When: as of design and during development.

    On mobile, screen readers try to notify the user when there is a context change.
    In some cases, it can give constant vocalizations, and can therefore become inaudible, or prevent any user action.

    The user must control the content at any time.
    This is especially true with interactive content.

    So avoid video player launching directly in full screen mode or videos starting automatically without user action or a carousel scrolling automatically for instance.

    All interactive content must be controlled by the user (adding an accessible button to exit full-screen mode for instance).


    Changing content

    Provide access to changing content to screen reader users.

    Target: everyone, especially people with visual impairments.
    When: during development.

    When content is dynamically modified after a user action, the screen reader must notify it.
    Without any voice feedback, the user does not know that the content has changed.

    If the content has changed dynamically after a user action, it is important that the screen reader is notified so that it triggers a vocalization (refreshing a list or a timer for instances).

    To start a vocalization, one must send a notification to the accessibility API via the UIAccessibilityPostNotification method with the UIAccessibilityAnnouncementNotification notification in parameter and the text to vocalize.

    It is also recommended to notify the Accessibility API when there is a change of context.
    To do that, one must send a notification via the UIAccessibilityPostNotification.
    There are several types of notifications, but the two most used are:

    • UIAccessibilityLayoutChangedNotification: notify that a part of the content has changed.
    • UIAccessibilityScreenChangedNotification: notify a global change.

    For more technical information, please check out the corresponding section on the developer guide for iOS.

    With a screen reader, make sure that dynamic changes are vocalized.


    Horizontal scroll

    Provide a visual indication to users when there is an horizontal scrolling.
    Allow screen reader users to scroll horizontally.

    Target: everyone, especially people with visual impairments.
    When: as of design and during development.

    A horizontal scroll can be very difficult to detect if no visual feedback is displayed to help the user understand that there are several pages.
    Do not hesitate to display a view to indicate a horizontal scroll (dots on UIPageControl for example).
    When necessary, also add “next” and “previous” buttons.

    Valid example:
    Valid example of a horizontal scroll

    Invalid example:
    Invalid example of a horizontal scroll

    • The horizontal scrolls are visually indicated.
    • It must be possible to switch pages for screen reader users.


    Form

    Improve the navigation and the overall understanding of the page because form fields describing the expected input are easier to fill for visually impaired users.

    Target: everyone, especially people with visual impairments.
    When: as of design and during development.

    Binding the form fields with their labels provides an additional vocalization allowing the user to understand what happens when filling out a form field.

    We must use the accessibilityLabel attribute to associate a label to a form field.

    Form fields must vocalize their labels.


    Reading order

    Ensure logic order and coherent reading to screen reader users.

    Target: people with visual impairments.
    When: during development.

    The reading order allows the screen reader user to get their bearings and to ensure functional coherence.
    It is therefore important to pay attention to it.

    By default, the reading order of voice synthesis depends on the “logical” reading order (in France), from left to right and top to bottom.

    It is possible to redefine the VoiceOver reading order using the UIAccessibilityContainer protocol (take a look at the developer section if you need further information).

    In this example, the default playback order depends completely on the implementation and on the order of element declaration.
    In this case: 1, 2, 3, vol+, 4, 5, 6, p+, vol-, 7, 8, 9, p-, 0.
    Example of reading order
    A more consistent reading order is 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, vol+, vol-, p+, p-.

    Traversal order (VoiceOver) is logical and coherent.


    Language

    Ensure the understanding of the application text.

    Target : people with visual impairments.
    When: during development.

    VoiceOver vocalization uses the default language of the mobile.
    Sometimes some words/texts of an application are in a different language.
    In order to make them properly understandable, they have to be declared in that specific language.

    To change VoiceOver language pronunciation of a word or a text, use the accessibilityLanguage attribute, available via the UIAccessibility protocol (see the developer section if need be).

    The words/text in a different language than the rest of the application should be vocalized in their corresponding language.


    Screen orientation

    Improve a better legibility of the content.

    Target : everyone, especially people with visual and/or motor impairments.
    When : as of design and during development.

    The screen orientation mustn't impact the access of an application content.
    It's highly recommended to :

    • Implement both the portrait and the landscape modes to be easily toggled by the user if it doesn't go against some functional constraints of the application itself (serious game for instance).
    • Provide for iPad screen sizes in order to facilitate reading and gestures.
  • Perfectly detailed design guideline including all the screens to be implemented with their possible orientation constraints.
  • Very accurate definition of the way the transitions between portrait and landscape modes should occur.
  • Portrait and landscape modes flawless adaptation to the content thanks to a bunch of graphic tests (very important for the Dynamic Type).
  • Appropriate settings in the integrated development environment.


  • Accessibility options

    The accessibility options located in the mobile settings are all about to improve the experience of an impaired user who can be significantly helped by these options.

    It's then primordial :

    • To understand perfectly each one of these options that can have an impact during the conception or the implementation periods of an application.
    • To test each appropriate option so as to be sure that its purpose is completely taken into account inside the application.

    Target : everyone.
    When : as of design and during development.

    The full list of these options including their purpose and their coding name is defined hereunder:

    1. Increase Contrast
    2. AssistiveTouch
    3. Bold Text
    4. Subtitles & Captioning
    5. Greyscale
    6. Guided Access
    7. Invert Colours
    8. Mono Audio
    9. Reduce Motion
    10. Reduce Transparency
    11. Shake to Undo
    12. Speak Screen
    13. Speak Selection
    14. Switch Control
    15. VoiceOver
    16. Auto-Play Video PreviewsiOS 13 new feature
    17. Differentiate Without ColouriOS 13 new feature
    18. On/Off Labelsnew in iOS 13

    • Increase Contrast (UIAccessibilityDarkerSystemColorsEnabled) : see the WWDC 2018 video for a detailed description.

    Access illustration via Settings - Accessibility - Display & Text Size - Increase Contrast.
    Since iOS 13, this accessibility option is a traitCollection variable instance.

    Access illustration via Settings - General - Accessibility - Increase Contrast.

    • AssistiveTouch (UIAccessibilityIsAssistiveTouchRunning) : displays the homonymous menu in foreground, whatever the runnning application.

    Access illustration via Settings - Accessibility - Touch - AssistiveTouch - AssistiveTouch.

    Access illustration via Settings - General - Accessibility - AssistiveTouch

    • Bold Text (UIAccessibilityIsBoldTextEnabled) : see the WWDC 2018 video for a detailed description.

    Access illustration via Settings - Accessibility - Bold Text

    Access illustration via Settings - General - Accessibility - Bold Text

    • Subtitles & Captioning (UIAccessibilityIsClosedCaptioningEnabled) : displays closed captioning or subtitles when available in the appTV or Videos app.

    Access illustration via Settings - Accessibility - Subtitles & Captioning

    Access illustration via Settings - General - Accessibility - Subtitles & Captioning

    • Greyscale (UIAccessibilityIsGrayscaleEnabled) : makes the display more readable for color blind people.

    Access illustration via Settings - Accessibility - Display & Text Size - Colour Filters - Colour Filters

    Access illustration via Settings - General - Accessibility - Display Accomodations - Colour Filters - Colour Filters

    • Guided Access (UIAccessibilityIsGuidedAccessEnabled) : restricts use of a single application.

    Access illustration via Settings - Accessibility - Guided Access - Guided Access

    Access illustration via Settings - General - Accessibility - Guided Access - Guided Access

    • Invert Colours (UIAccessibilityIsInvertColorsEnabled) : reduces glare and eye strain thanks to a very helpful mode for visual impaired people.

    Access illustration via Settings - Accessibility - Display & Text Size - Smart Invert

    Access illustration via Settings - General - Accessibility - Display Accomodations - Invert Colours - Smart Invert

    • Mono Audio (UIAccessibilityIsMonoAudioEnabled) : allows a complete hearing understanding with headset on without missing a word or a sound for people who are hard of hearing or deaf in one ear.

    Access illustration via Settings - Accessibility - Audio Visual - Mono Audio

    Access illustration via Settings - General - Accessibility - Mono Audio

    • Reduce Motion (UIAccessibilityIsReduceMotionEnabled) : see the WWDC 2018 video for a detailed description.

    Access illustration via Settings - Accessibility - Motion - Reduce Motion

    Access illustration via Settings - General - Accessibility - Reduce Motion

    • Reduce Transparency (UIAccessibilityIsReduceTransparencyEnabled) : see the WWDC 2018 video for a detailed description.

    Access illustration via Settings - Accessibility - Display & Text Size - Reduce Transparency

    Access illustration via Settings - General - Accessibility - Reduce Transparency

    • Shake to Undo (UIAccessibilityIsShakeToUndoEnabled) : displays a menu to undo an action, preventing from holding backspace and watching all the letters disappear one by one for instance.

    Access illustration via Settings - Accessibility - Touch - Shake to Undo

    Access illustration via Settings - General - Accessibility - Shake to Undo

    • Speak Screen (UIAccessibilityIsSpeakScreenEnabled) : launches the vocalization of the screen content.

    Access illustration via Settings - Accessibility - Spoken Content - Speak Screen

    Access illustration via Settings - General - Accessibility - Speak Screen

    • Speak Selection (UIAccessibilityIsSpeakSelectionEnabled) : displays a menu that suggests to speak the selection that fired it.

    Access illustration via Settings - Accessibility - Spoken Content - Speak Selection

    Access illustration via Settings - General - Accessibility - Speak Selection

    • Switch Control (UIAccessibilityIsSwitchControlRunning) : activates the feature in point scanning mode or in item scanning mode.

    Access illustration via Settings - Accessibility - Switch Control - Switch Control

    Access illustration via Settings - General - Accessibility - Switch Control

    • VoiceOver (UIAccessibilityIsVoiceOverRunning) : launches the screen reader.

    Access illustration via Settings - Accessibility - VoiceOver - VoiceOver

    Access illustration via Settings - General - Accessibility - VoiceOver

    • Auto-Play Video Previews (UIAccessibilityIsVideoAutoplayEnabled) : see the WWDC 2019 video for a detailed description of this iOS 13 new feature.
      Access illustration via Settings - Accessibility - Motion - Auto-play Video Previews


    • Differentiate Without Colour (UIAccessibilityShouldDifferentiateWithoutColour) : see the WWDC 2019 video for a detailed description of this iOS 13 new feature.
      Access illustration via Settings - Accessibility - Display & Text Size - Differentiate Without Colour


    • On/Off Labels (UIAccessibilityIsOnOffSwitchLabelsEnabled) : once activated, this option whose programmatic access is new in iOS 13 displays each button state.
      Access illustration via Settings - Accessibility - Display & Text Size - On/Off Labels
    Once activated, if the accessibility option has no result in the application running, it's highly recommended to keep oneself posted of the impacted options states so as to provide the best user experience.
    The full list of the accessibility options with their dedicated notification is located in the developer part of this site.

    It may be particularly interesting to keep track of these options (de)activations with kind of indicators in order to have a better understanding of the users habits and to implement improvements accordingly.