Page MenuHomePhabricator

Establish caret/arrow as jump mark for screen readers
Closed, ResolvedPublic1 Estimated Story Points

Description

Acceptance criteria

  • Using aria roles for screen readers, indicate that the arrow/caret will bring you back to the reading position
  • This should work no matter how often the reference was used (i.e. also, if there are no letter jump marks)
  • The jump marks ("a","b","c") will not be covered by aria roles

Notes

  • This will be the first time aria labels are being used in the CiteExtension.
  • It might make sense to add aria labels after the rest of the implementation has been covered, so that javascript has already been introduced
  • The existing message keys e.g. can be reused here cite_references_link_accessibility_label
  • We should best use the aria-label and the title attribute at the same time
  • We might want to remove the "old" screen reader "labels" from T40141

Mock:

Bildschirmfoto 2018-05-14 um 13.49.25.png (60×242 px, 9 KB)

Please note that the arrow you see in the mock is the German implementation. In en-wiki it is a caret (^), and the way this is being represented in all of the wikis should not change. Also don't pay attention to the blue background, or the bold character for this ticket.

Event Timeline

Lea_WMDE created this task.

Two questions @Lea_WMDE :

  • Should we also add title attributes to the links so that users could see browser tool-tip when hovering the links?
  • Is there already a dafined text that should be used in the label (/title)? Something like Return to the text, Return to where this citation was applied, ...

Two questions @Lea_WMDE :

  • Should we also add title attributes to the links so that users could see browser tool-tip when hovering the links?
  • Is there already a dafined text that should be used in the label (/title)? Something like Return to the text, Return to where this citation was applied, ...

Additional to the links in the <references> section at the button of a page, there are currently also no aria-lable (/title) attributes on the links in the text.
If we would want to add tags there as well, I guess to make these really useful we would need to add some "reference-preview-ish" kind of label text. - Is that also part of this task?

  • Is there already a defined text that should be used in the label (/title)? Something like Return to the text, Return to where this citation was applied, ...

Ok I just realized, that there are already labels defined for that purpose in cite_references_link_accessibility_label with the English text Jump up and German Hochspringen they are not really used at a place I would see as correct for screen-readers and I would recommend to fix that with this ticket.

The old ticket to that topic including the text discussion can be found here: T40141

While working on this I came upon this comment in the old accessibility code [0]:

// We can't use aria-label over here as that's not supported consistently across all screen reader / browser
// combinations. We have to use visually hidden spans for the accessibility labels instead.

Looking at [1] this seems to be just rarely true anymore and backs our idea that this could be replaced. I would still like to hear opinions on that, maybe also from @TheDJ

P.S.: This page seems to be a great and quite up to date resource for screen-reader compatibility and just using the title attribute seems to be not very reliable in that case when comes to screen readers [2].

[0] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Cite/+/refs/heads/master/modules/ext.cite.a11y.js#28
[1] https://www.powermapper.com/tests/screen-readers/labelling/a-aria-label/
[2] https://www.powermapper.com/tests/screen-readers/labelling/a-title/

We briefly discussed this today and we think:

  • We definitely should not add aria-labels and keep the old "hidden spans" code the same time. This might lead to the situation that screen readers read the text twice, which is almost as bad as having no label.
  • I checked and there is barely any code in core that uses aria-labels: https://codesearch.wmflabs.org/search/?q=aria-label%5Cb. Some extensions use it much more extensively. I, personally, think we should follow and start using it. Following a standard is just "the right thing" to do, isn't it?

Quickly pinging @hoo as he was involved back then.

Change 474893 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/Cite@master] Improve a11y support on backlinks

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

WMDE-Fisch changed the point value for this task from 3 to 1.Nov 20 2018, 12:54 PM

The patch https://gerrit.wikimedia.org/r/474893 will have a few effects:

  • The two messages "Jump up" and "Jump back up" will be visible to every user as a mouse hover tooltip, when hovering the up arrows. This was not the case before.
  • Some up arrows will say "Jump up", some others will say "Jump back up".
  • "Jump up" will be the tooltip for up arrows that are always visible (on references that are only used one time).
  • "Jump back up" will appear dynamically on references that are used multiple times. For these, the up arrow will only become clickable (and this will include the tooltip) when the reference got highlighted.

I'm fine with all this. I just wanted to make all this clear and visible to PM and possibly UX.

Thanks, @thiemowmde for the writeup!

@Lea_WMDE: I think the texts are nice and short. But what do you think about assigning them differently?

Suggestion:

Use Jump back up on all links that bring you back to where you came from. AFAIK this would be

  • for all arrows/carets, if the user didn't scroll to the footnote, but jumped there from the article body (also if there the footnote was only used once in the article)
  • for the highlighted letter itself

Use Jump up on all links that bring you "just up"

  • for all arrows/carets if the user scrolled down to the footnote section
  • for the non-highlighted letters in multi-referenced footnotes

What do you think?

I just had a talk with @Lea_WMDE about this and as a first step she approved what is done in the patch so far.

We also decided on, that if it is possible with little effort, we should add Jump back up labels to single referenced back links when the user just jumped there. ( this would also include removing them when jumping away again ) - Thinking about it I doubt that the effort is trivial ^^

i'm good with aria-label for a11y. It's 5 years later now, considerable progress has been made, as can be seen from the tables at powermapper

Note that aria-label is good for this type of element – [[ https://www.powermapper.com/tests/screen-readers/labelling/a-aria-label/ | <a aria-label> ]], for others like <input type="text" aria-label="Enter search text"> there are still screen reader/browser combinations that have hiccups.

Change 474893 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] Improve a11y support on backlinks

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

Again, can be tested on beta e.g. here: https://de.wikipedia.beta.wmflabs.org/wiki/Tacrin?purge=now ( cache might still hinder the feature from working that's why I applied the purge parameter. )

Change 484698 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/Popups@master] Also exclude the Cite extension's "Jump up" backlinks

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

Change 484698 merged by jenkins-bot:
[mediawiki/extensions/Popups@master] Also exclude the Cite extension's "Jump up" backlinks

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