Navigation iOS SDK Accessibility

[vincethecoder]

Identify all the views and controls that require UIAccessibility information to be consumed by third-party app's user interface.

/cc @mapbox/navigation-ios

[1ec5]

Making the navigation SDK’s UI accessible requires more effort than merely conforming to UIAccessibility piecemeal, control by control. That’s the route Google Maps has taken, and there are a lot of complaints about its usability. We’ll need to design user interaction around concrete user flows.

[vincethecoder]

@1ec5 The main idea behind this ticket, was to achieve the following highlights (goals):

• Ensure this improves the user experience for voice-over navigation. Thus, group accessibility elements wherever necessary with a user intuitive navigation flow eg. swift left to right, etc.
• Ensure the controls announce the proper accessibility hints. Example, turn left in 4 meters, double tap banner to reveal direction steps, close button -- double tap to dismiss view etc.
• Ensure the developer can easily embed our SDK into a target app with user accessible capabilities.

[akitchen]

Sounds to me like next steps are to audit what's there currently and create user stories for each distinct bit of functionality, with clear acceptance criteria.

[1ec5]

Without having dug into the navigation SDK’s accessibility support in much detail, I think this is a reasonable characterization of what’s there so far:

• If an application embeds NavigationMapView directly, such as for a preview screen, the map view is accessible to a very granular level of detail thanks to Make places and roads accessible to VoiceOver mapbox-gl-native#9950. For example, you can navigate among each label and road on the map. While this level of granularity is appropriate for some map use cases, a navigation application’s preview screen would only call for what we implemented in VoiceOver accessibility mapbox-gl-native#1496, in which only interactive elements such as annotations were navigable with VoiceOver enabled.
• Turn-by-turn navigation is supposed to be very focused, guided activity, like watching a movie. But instead NavigationViewController is like a airplane cockpit to a VoiceOver user. Every time a label’s value changes somewhere on-screen, the new value is read aloud. To exit navigation, the user has to trudge through almost every control – and every element on the map.

Auditing individual controls’ accessibility hints for correctness is a reasonable stopgap measure, but we should be mindful that this step alone will take us from 0% to 10%. Since we need to think above the level of individual controls, I agree that we need to start by creating user stories. However, I’d expect the user stories to intersect with our sighted user stories. After all, a sighted driver seldom looks at the screen but consumes guidance all the while.

To exercise our user stories, I’d suggest building a “headless” navigation experience using nothing but Core Navigation. We could put the headless application in the examples repository or perhaps put it in a dedicated, experimental repository.

[vincethecoder]

@1ec5 Great stuff! 👍