VoiceOver accessibility

[1ec5]

The changes in this PR are intended to reach parity with MapKit basic user expectations in terms of VoiceOver accessibility.

• Make the compass accessible
• Make the user dot accessible
• Give the ℹ️ sensible accessibility text
• Make annotations accessible (fixes Compass, user dot, annotations are inaccessible on iOS #1493)
• Make annotation callouts and their accessory buttons accessible
• Update accessibility when map viewport changes (fixes Crash interacting with annotation callouts with VoiceOver enabled — -[NSObject(UIStorage) accessibilityPerformAction:withValue:] #1494)
• Order annotation accessibility elements by distance from center / user location
• Bonus: Add accessibility-only controls for navigating the map

By comparison, MapKit has pretty good accessibility, while Google Maps is largely inaccessible on iOS.

There are also architectural improvements in this PR:

• MGLMapView now maps annotation IDs to annotation contexts, which contain the annotations themselves (Annotation tap gesture recognizer queries hard-coded region, ignoring image sizes #1504). Previously, annotations were mapped to annotation IDs. The new approach reduces the number of places we need to iterate over the entire mapping and will make it a bit easier to implement another kinds of annotations (merge GeoJSON vector tiles work #893). This was split out into Refactored iOS annotation selection #3261.

[1ec5]

Annotations are now accessible, but it requires more work to find a visible annotation by its unique ID than I’d like. Given how many times annotationIDsByAnnotation’s key enumerator is being turned into a sorted array in various parts of MGLMapView, I think annotationIDsByAnnotation should be inverted to map annotation IDs to dictionaries that contain annotations and their accessibility elements.

[incanus]

This is gonna be great.

Once we hit #352 at get a featuresAt() equivalent, we can start to think about iterating navigation elements on the map as well like Apple Maps does — streets, POIs, etc.

[1ec5]

Once we hit #352 at get a featuresAt() equivalent, we can start to think about iterating navigation elements on the map as well like Apple Maps does — streets, POIs, etc.

To my knowledge, Apple Maps' VoiceOver support when simply viewing the map is limited to POIs. But it'd be awesome if we could use pick out road labels to deliver more comprehensible location readouts at high zoom levels ("near the corner of Broad and High Streets, facing Central Park"), instead of prosaic coordinates and compass directions, without requiring separate calls to a geocoder.

[incanus]

To my knowledge, Apple Maps' VoiceOver support when simply viewing the map is limited to POIs.

Nah, they do all places visible + roads by default. Here's an example:

https://dl.dropboxusercontent.com/u/575564/voiceover.mp4

Sorry about the annoying speed I went through it — wasn't hearing the audio when recording so wasn't sure it was working.

[1ec5]

Nah, they do all places visible + roads by default.

Oh cool, although it must be really annoying to have to sift through all the road labels just to get to a POI. Our developers are mostly presenting maps where the annotations matter much more than the base map, so once feature picking gets us granular accessibility elements, we’ll need to make the level of detail configurable.

[1ec5]

2e71630 most likely fixes #1628.

[1ec5]

I split out and cleaned up the display string formatting in #4802.

[1ec5]

@boundsj, these changes shouldn’t conflict too badly with what you’re working on in #4801, but you’ll want to update some of this logic for annotation views. For example, a view-based annotation’s accessibility frame should be the view’s frame instead of the return value of -frameOfImage:centeredAtCoordinate:. A further optimization would be to have the annotation view be the annotation’s accessibility element, but I don’t think that’s strictly necessary.

[1ec5]

Filed #4820, #4821, #4822, #4823 to track further accessibility work.