search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Meaningful link text in spec #158

Closed michael-n-cooper closed 6 years ago

michael-n-cooper commented 7 years ago

Filed by private email

There are two links on the page that do not have meaningful link text. They are:

    <a id="toc-jump" href="#toc"><span aria-hidden="true">↑</span> <span>Jump to Table of Contents</span></a>

    and

    <a id="toc-toggle" href="#toc"><span aria-hidden="true">→</span> <span>Pop Out Sidebar</span></a>

    When I look at the code...my brain thinks..."I see link text...it should be fine."  But when I tried it in VoiceOver, NVDA and JAWS...alas....the link text is not good in any of these 3 screen readers.
awkawk commented 7 years ago

What do the screen readers voice for these links?

steverep commented 7 years ago

NVDA in Firefox will read differently based on whether those links are tabbed to or arrowed to and things also change depending on whether the mouse is hovering them. IMHO, this issue goes way beyond meaningful link text though. The whole TOC mechanism is not very screen reader friendly.

For example, the collapse and pop-out sidebar link should really be a button and marked with aria-expanded like an accordion. Then it gets confusing because you can still jump to the TOC which has moved into the main flow under the abstract... In short, I only navigate these Respec documents via heading because the TOC is confusing (and there's no main landmark so that doesn't help either).

michael-n-cooper commented 7 years ago

This issue is complicated for us because the problems come from sources we do not control.

The statement "The whole TOC mechanism is not very screen reader friendly" may relate primarily to the W3C TR styles, which all TR documents are required to use. We can attempt to override some of the styles, but there are rules about that and publication will be refused if we break them. We should file issues on the TR styles repository and request to have the styles update, that will likely be the primary fix we can obtain but it won't come quickly.

Some of the specific problems noted in the original issue may come from how Respec instantiates the TR design. For that latter we can do some things by manual post-processing, but I'm anxious to minimize the amount of work involved in that. I would need a concrete list of things we might address that way. I would need a specific edit-list of things to add to my "fix bad stuff Respec does" list.

steverep commented 7 years ago

@michael-n-cooper, I totally get that this is not a WCAG issue but one that affects all TR documents, so we definitely should file these issues in the appropriate repository (as with the above Respec issues I referenced regarding permalinks inside heading tags).

However, we should not just accept that such issues won't get fixed quickly. The irony of producing a WCAG publication that wouldn't pass an accessibility audit is too great.

jake-abma commented 7 years ago

The toc-nav is indeed unreliable and doesn’t deserve the beauty award. Here the results where especially the link lists and arrow keys may cause weird feedback.

We may have an exemption if it’s not under our own control but also an obligation to put some friendly pressure on who does.

Firefox / NVDA mentions in…

Link list:

Tab key:

Arrow key:

InternetExplorer / Jaws mentions in…

Link list:

Tab key:

Arrow key:

Safari / Chrome / VoiceOver mentions in…

Link list:

Tab key:

Arrow key:

awkawk commented 6 years ago

Not a WCAG 2.1 issue but a respectable issue. @michael-n-cooper is this one filed with respect?

michael-n-cooper commented 6 years ago

This is TR design not Respec. I filed Issue 136 there, closing here.