- 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”
- 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.
- 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?
- 2. Citations could be improved:  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.
- 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.
- 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.
This is being held at this point until we hear back on accessibility audit. To not lose context, this is the discussion this is currently parked on:
Do we know what is happening with accessibility more broadly? I see some tags I can add to our doc that are meant for exactly what we’re hoping to do - notate when something is a link to a reference down the page, for example (role="doc-noteref). While I can certainly add these in PCS, they could also be valuable to the web version of the product. Of course, I’m still new and learning how we operate - Is it worthwhile to ask another group to work on this (on global wikipedia), and waiting for it to come downstream via PCS? Or just do it in PCS, as then we’ll have something working sooner? Or look into how hard it would be for me to make a patch upstream for this?
ARIA items that would be useful for us:
- For bibliography stuff
- role=“doc-noteref” in the link in the article
- role="doc-backlink” in link back up to article in footer
- role="doc-bibliography” for section header bibliography in references
- role="doc-biblioentry” - around each item in references
- role=“doc-endnotes” - for section header for footnotes
(role="doc-toc” - at header of our table of contents - would be useful if the TOC was presented as a web view. But it's not.)
Also, while we're in there, we should re-do how I did collapse/expand (both collapsible sections and collapsible tables) - it seems like aria-expanded and aria-collapsed are exactly what we wanted, and I basically rolled our own (which came with a bit of overhead).