While this started because of mobile html, I ended up spending a bit of time looking at VoiceOver in all the corners of our app.

Four notes

1. I tried to write this up clearly, but there are likely some parts that are closer to "Matt shorthand" than "easily understandable by others". Let me know if I should expand on or clarify any of these.
2. In many cases I've included suggested fixes. Please feel free to overrule that with different/improved text.
3. I've tried to do a first pass on triaging these by importance. 1 is "must do", 2 is "should do", 3 is "nice to have". Feel free to edit my comment (if Phab allows it) to reprioritize any of these. This was just my first shot at priority.
4. I ended up digging fairly deep on VoiceOver in the app. If this seems deeper than I should have gone, please let me know - so next time I can put a more appropriate amount of effort into this, relative to all the other things we're working on for 6.6.

The list

• Article (in order one would encounter in article)
  • 2. Header image - isn’t read by VoiceOver, and isn’t selectable at all - fix this
  • 3. Very low priority: between subhead and start of article says “separator, dim, en, banner”… could just be “small separator”
  • 1. All edit article buttons are read as “Index php link” - should be “Edit article link” or “Edit section link”
  • 2. Images in article - they read a lot of unneeded info, and never say they’re a link - correct this
  • 2. W button on top: Read something like “Wikipedia back to Explore button” - starting with “Wikipedia” seems unnecessary and clunky. Let’s just describe the actual action.
  • 1. Closed fact box - Reads as “Quick facts, colon [first couple words of box]”… It never announces the down arrow (which opens the box), and never explains it’s tappable. Let’s change this to “Quick facts, tap to open box” or something similar?
  • 2. Open fact box: the last link (which collapses the box) just says “close”. Could it say “close fact box” or simply “close box” or something similar?
  • 1. The reading experience is very difficult. When scrolling piece-by-piece, each “chunk” that it reads is whatever is in the exact same style. Anything bold, any link (including references), etc. - all those are different readable sections. Most sentences (especially those early in the article) have half a dozen sections. That’s… rough.
    • Examples
      • Just “we went to [Portland]. [2]” has 5 distinct sections one needs to swipe through: “we went to open bracket”, “Portland link”, “close bracket period open bracket”, “2 link” and “close bracket”.
      • In Greater Wynnewood Exotic Animal Park… “is situation on [break] 16 acres (6.5 [break] ha [break] and began as a shelter…”
    • Considering the three ways users can read (there could be more I’m unaware of), and how this plays out:
      • Swiping to have the entire screen read to you without stopping: This actually works well, but only works if you don’t want to pause or jump around.
      • Swiping between items (two fingers forward or backwards): This is tough, but workable. You have to prompt it to continue between every section, which typically ends up being several times per sentence.
      • Swiping your finger around the screen, having whatever you’re currently on be read out loud: This is non-functional, because some fragments span multiple lines, others don’t, etc.
    • … This obviously needs to be fixed. Apple News reads out the entire article, and just says things like “We went to Portland link 2 link.” We should do something like that. (News has a slight pause before reading the link, and says the word “link” afterward. We should ensure we have this pause at the start of the link, so there is a tell as to where the link begins. Example from News: “Far less deaths than [slight pause] Italy link, where fatalities…”)
  • 2. Citations could be improved: [2] is currently read as “open bracket, 2 link, close bracket”. Either “citation link” or “citation 2 link”?
  • 2. Small boxes that link to other wikimedia projects (“wikipedia commons has media related to [article title]”)
    • These read out the image w/ the logo for the project - those shouldn’t be read.
    • They also don’t have any indication they’re in a little grey box, almost as an aside - they are read as part of the article. This should be updated.
  • 1. “References” and “external links” are collapsed but don’t say anything about being expandable, and the upside down caret next to them don’t read in VoiceOver. Have VoiceOver read “tap for list” after the names, or something similar.
  • 3. “About this article” items are described as “menu item” after reading the text of each. Let’s update this to read as “link”.
  • 2. “Read more” - each article in this section has its title and description read as separate items, both with the word “link” afterward. Group these labels so they’re read together, and say “link” just once. (They’re grouped appropriately elsewhere in the app, like in search results.)
  • 3. Footer - “wikipedia” image doesn’t read at all - I don’t think we need it to, but wanted to mention it as we use that image as branding for sighted users, and so this seems like a difference.
  • 1. The Creative Commons and “view article in browser” links don’t read as links, just as text (even when they’re working - on some branches, bug to fix them is yet to deploy). Update them to read as the standard “view article in browser link”.
  • 3?. Have a hidden link (shown/read in VoiceOver, otherwise not present) at top of “table of contents” between the table of contents and starting to read it: “skip to article”? Otherwise when reading the entire page, it goes through the entire TOC. The more I think about it, the more I don’t like this idea - as soon as the user has an idea of our layout, it’s easy to skip over to the content by tapping the proper part of the screen. And this seems somewhat non-standard for VoiceOver, though I’m not quite sure. But leaving this on the list.
• Across the app:
  • 2. Anything that can be clicked says “[item text] Link” as read. If possible, should we make a difference between “article link” and general (off-wiki, reference, etc.) “link”? This would be handy in article (reference vs. link to another article), in the explore tab (some links open articles, while others open submenus), etc.
  • 2. Our “sync your saved articles?” overlay custom modal - and “enable location” overlay, and probably others - don’t make it clear that this is all that is on screen. The user probably understands that from the fact there are only a few readable items on the screen. But some little text at the start like “alert box” (better text welcome) would likely be helpful context.
• Explore tab
  • 1. The three dots (by every card) giving feed options are not selectable w/ VoiceOver (either while scrolling through or by tapping items on the page).
  • 2. “In the news” card - No indication that the title of sentence (of top news story) is tappable, which opens the full in the news feed. Only part that reads with “link” is “more current events link”. (And remember, users can’t tap to related articles until you dig in to the detail view.) So in sum, the VoiceOver read is “In the news, [article headline], more current events link”. “More current events” goes to same detail view as if the article headline was tapped. Maybe for clarity, have title of that link be read as “Article links and more current events” - so the read is “In the news, [article headline], article links and more current events link”.
  • 3. First item read on this page is “Settings button”. Seems like we should lead with something else - maybe the “Search wikipedia” box, and read the Settings after that?
  • 3. “In the news” detail view - When opened, there are a few mini-boxes with links to the actual articles. Should we read subheads for articles links in these? They seemed (to me) unnecessary and in the way in this context.
  • 3. “Picture of the day” - read picture description (if available), don’t read title?
  • 2. “Top read” card doesn’t read the ranking number, just reads titles.
• Saved tab
  • 2. Edit mode is tough, because buttons (after you select articles) are on the bottom and read last - should be read first, if possible?
• Places tab (TL;DR: maps are hard and this will probably never be perfect)
  • 2. Header is read as “Places”, and there really isn’t a time that we explicitly let folks know this is a map. Read the header as “Places: Place-based articles pinned on map” or something like that? Though if we implement the “future possibility” (final bullet in this section), that’s irrelevant.
  • 2. After the header, VoiceOver goes to the box of articles. This isn’t very helpful when you’re on the default zoomed-out map. Should it first move to the “bring map to me” compass point? (Or maybe just do that if we don’t have location permissions, and are defaulting to where we zoom? That’s probably over engineering this, but would be nice.)
  • 1. Could the box on the left (with articles) have a (hidden, used in VoiceOver only) title - something like “Articles with pins on current map”. Right now if swiping through this screen, it’s not quite clear what these articles are - and they are the first thing that are scrolled to after the headers.
  • 3. Maps are just hard. How should we handle maps for sightless users? I looked at how Google Maps and Apple Maps handle VoiceOver.
    • Stock Apple Maps reads out street-by-street. So you can VoiceOver everything, but it's hard to figure out where you're at.
    • Google Maps takes an interesting path, and one that maybe we should implement in the future - it basically ignores the map in VoiceOver - and is really a location-based search app, not a mapping app. It will never read the map in VoiceOver (it skips over that entirely), but handles all sort of location searching. If you search for “Goodwill”, it gives the full list of locations as default - the same as if you searched w/o VoiceOver and pulled the results list drawer handle up so it covers the map portion of the screen. And if you select a location, it defaults to the “no map, full screen of the location’s details”.
    • A potential way for us to handle this in the app - which almost certainly would be done as part of future work, if we wanted to use it - is something similar to how Google Maps handles it - just focus on location-based search. If VoiceOver is on, add another search box for location, so it is easy to get to the map center to any spot. VoiceOver ignores the map itself (except for things like the “bring map to me” compass point) - but with the two search boxes, you can get a list of articles near any point you’d like.

Going to wait on some feedback on this list before I start making changes, to make sure I'm on the right track with priorities.

I created T249330 to track the server-side work for mobile-html a11y. @JMinor feel free to add subtasks to that epic as the work from the excellent mobile-html article a11y audit @MattCleinman provided above is divided and prioritized.

@JMinor - this one is good to close, right?