Page MenuHomePhabricator

UI elements in MinervaNeue inaccessible by screen reader
Closed, ResolvedPublic

Description

Certain buttons in article title area do not register as buttons by screen reader and their name and function is not spoken.

  • Hamburger (not sure why - already has a title attribute and label - just isn't spoken)
  • Search link (needs a title attribute - use the same one as Vector skin)
  • Edit link <a> needs a title attribute (not just the li attribute) [already fixed by @rmoen]
  • Watch star icon <li><span> should use a button or a instead of span [already fixed by @rmoen]

Event Timeline

Jaredzimmerman-WMF raised the priority of this task from to Normal.
Jaredzimmerman-WMF updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 27 2015, 7:57 PM
brion added a subscriber: brion.Jan 27 2015, 8:18 PM

For reference, is this with Apple's VoiceOver or a different screen reader?

The issue was demoed to me with the build in iOS VoiceOver functionality

*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

M +1 415 609 4043 \\ @Jaredzimmerman http://loo.ms/g0

Jdlrobson added a subscriber: Jdlrobson.

This might be better in beta (as part of UX standardisation icons are in flux). Can you clarify if you saw this in stable or beta or alpha?

It was originally in Stable, but i just tested Beta and Alpha and they have the same problem.

It also extends to the Hamburger menu, and I noticed i cannot even use the login page in access mode.

Jdlrobson renamed this task from Edit and watch actions on mobile web are not accessible to Inaccessible UI elements.Jan 28 2015, 10:57 PM
Jdlrobson updated the task description. (Show Details)
Florian added a subscriber: Florian.Feb 2 2015, 8:22 AM

@Jdlrobson, why shouldn't hamburger have a title? I agree, maybe label is not needed.

TheDJ added a comment.Feb 10 2015, 7:59 AM

@bmansurov There is something very wrong here at a much deeper level I suspect. Even the desktop version of Voiceover on the mobile website is totally unable to read and control the mobile website, and we are not entirely sure why that is. It's like it is being thrown off by some invisible surface... Perhaps due to the sliding menu ? Will require further investigation.

kaldari renamed this task from Inaccessible UI elements to UI elements Inaccessible by screen reader.Feb 12 2015, 1:45 AM
kaldari renamed this task from UI elements Inaccessible by screen reader to UI elements inaccessible by screen reader.
TheDJ added a comment.Feb 12 2015, 7:23 PM

It seems that this is caused by the text-indent hack to hide the text from view.
This trick also doesn't work well with rtl, so that's another reason to avoid it.

I do admit, that this is DIFFICULT to satisfy everyone, but there have been some insightful blogposts on this topic that should be a good guide:
http://www.nczonline.net/blog/2013/04/01/making-accessible-icon-buttons/
http://snook.ca/archives/html_and_css/hiding-content-for-accessibility

BTW, when googling about this text-indent trick, I came across the fact that his can impact performance on mobile devices, because it enlarges the render surface that needs to be calculated. http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/

rmoen moved this task from To Do to Doing on the Reading-Web-Sprint-54-28-Days-Later board.

Change 235134 had a related patch set uploaded (by Robmoen):
Make edit link and watchstar accessible to ios voiceover

https://gerrit.wikimedia.org/r/235134

The above change is only partially complete. This patch does not resolve the issues with the text-indent hack. Need to research this more.

Questions:

  • Should the menu have a label?
  • What is the search link in the description ? the search Input / placeholder form elements?
phuedx added a subscriber: phuedx.Sep 1 2015, 1:11 PM

@rmoen: You're not alone in seeing browser tests passing locally that fail in the integration environment…

Looks like this test is failing for other patches too - https://integration.wikimedia.org/ci/job/mwext-mw-selenium/682/console - so something has changed somewhere (ohhh the mystery of browser tests)

I'd suggest adding a separate patch to @skip it if you are unable to debug it. I can look at it later (I suspect race conditions again).

Jdlrobson updated the task description. (Show Details)Sep 2 2015, 11:47 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a project: good first bug.
Jdlrobson moved this task from Tech debt to Bugs on the MobileFrontend board.Sep 2 2015, 11:49 PM

Change 235134 merged by jenkins-bot:
Make edit link and watchstar accessible to ios voiceover

https://gerrit.wikimedia.org/r/235134

Volker_E added a subscriber: Nirzar.Apr 6 2016, 5:07 AM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 17 2016, 6:32 PM
Volker_E removed a subscriber: Volker_E.
Volker_E added a subscriber: Volker_E.
Aklapper removed rmoen as the assignee of this task.Jul 10 2017, 8:09 AM
Aklapper added a subscriber: rmoen.

[ Resetting assignee as assignee account is not active anymore ]

Jdlrobson renamed this task from UI elements inaccessible by screen reader to UI elements in MinervaNeue inaccessible by screen reader.Jul 13 2017, 5:42 PM
Jdlrobson edited projects, added MinervaNeue; removed MobileFrontend.
Jdlrobson moved this task from Backlog to Bugs on the MinervaNeue board.Jul 13 2017, 6:04 PM
Jdlrobson closed this task as Resolved.Nov 30 2017, 10:37 PM
Jdlrobson claimed this task.
Jdlrobson removed a project: Google-Code-in-2017.

Unless I'm mistaken this looks addressed. When I turn on VoiceOver for OSX and visit in Chrome all buttons are registered in the screen reader...

TheDJ added a comment.Dec 1 2017, 1:39 PM

Just to note, while things have improved with accessibility, specifically for the items mentioned, it's still far from being actually fully accessible.. Just to make sure that people don't think that MinervaNeue is accessible now...

Thanks for that note @TheDJ yes, I am sure there are many improvements still to be made.