-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Footnote return link accessibility #54727
Comments
This is a bug. The arrow character does not describe the purpose the link. The arrow also makes the link 'text' identical for all footnote return-to-content links, and links need to be distinguishable from each other. |
Yes, it's an a11y bug. We don't need to add a second type label. P.S. Here's a more general discussion on whether an 11y label should be combined with other labels - #54724. |
Update: just recapping some of the discussion from #54843. While #54843 improved the accessibility for screen readers, some good ideas were raised for how to improve the visual accessibility of the return links: Proposed ideaAs raised in #54843 (comment)
Before implementing the above, we might wish to settle on a proposed approach / design that meets accessibility and design requirements, so I've added the Needs Design Feedback label to this issue. |
I think this should be a global style/setting that applies to all footnote blocks. Doesn't make sense to have to configure each and every block.
Could you elaborate more on why that's needed? The ordered list gives the context on the footnote number, both for visual and non visual users? And the new aria-label gives additional info? So why is it necessary to include it in the text? I think the current option should be the default, given that 99% of all footnotes on the web look this way. |
I was mostly trying to capture the discussion from #54843 (where I too thought the ordered list would be enough for context). I'll just ping @afercia and @joedolson, as they provided a few arguments for why they thought it should be the default (i.e. in this comment: #54843 (comment)), so they might be best placed to clarify. |
Hi folks! What about this POC? This may complete this commit 9949351 ADD: arial-label The content is hidden by default, then revealed on mouse over or focus state (keyboard TAB key navigation). Markup HTML:
Markup CSS:
|
Agreed with @DSGND that both foot note links (to to the footnote and back from it) could be more clearly described. When tabbing through links in the content "1" is definitely not enough context to understand what the link does.
I do not rely on a screen reader, but in my testing with NVDA + Windows + Firefox, I found that "1" is announced when reading the footnote, but the fact that I'm in a list or the number of items that list has is not mentioned. (I'm guessing because the link targets the list-item that's already inside the list?) If that experience is even somewhat common, some clearer link text like "Continue reading from Footnote 1" or something feels like a good idea. |
I'm not sure this is a good argumentation. Unfortunately, all the footnotes that 'look this way' are not accessible.
That is not accurate. The aria-label doesn't provide additional info. It actually replaces any content. The aria-label would only work for screen readers. Accessibility isn't only about screen readers. I would greatly appreciate that once screen readers accessibility is addressed we don't call accessibility 'done'. As explained in #54843 (comment) the text must be visible, at least as a default setting. An icon is insufficient as it doesn't visually expose the accessible name. Just to mention one group of users who won't be able to use the icon links: speech recognition software users won't have a clue what the voice command to issue is. In the editor, we partially addressed this problem by teh means of tooltips (and that's already a compromise). On the front end we don't have tooltips. As such, the only accessible solution is making the text visible. Based on WCAG 2.2, the icon links violate at least 2 (and arguably more) success criteria: |
I'm having a second thought on this. Themes may style the ordered list. Some browsers, most notably Safari, don't expose the default list role for styled lists. In this case only relying on the ordered list number won't be enough. Test page: https://codepen.io/afercia/full/WxmJWx |
During an accessibility audit we basicly came accross the same issue and started to come up with a solution for the same problem. Our auditor asked for more context for the to and return link of a footnote. An aria-label attribute or a text label would fix this. The link to the footnote lacks a clear description of its purpose. This can be fixed by adding an aria-label:
With that also the link from the footnote back to the content lacks a clear description. This can be fixed by adding another aria-label:
It would be even better if the link to the footnote would add some more context to the aria-label like:
As for styling: I would keep away from a radical solution but also don't keep with the 'That's what everybody does' mentality. Sometimes the standard just isn't that good. |
This would introduce a mismatch between the visible text and the actual accessible name. 2.5.3 Label in Name While that pattern would help blind screen reader users, it would introduce a barrier for other users e.g. sighted screen reader users and voice control users. |
I do agree with you but I imagine the visual change may be too much for some. A solution like this might be better: I changed the dash to a colon because I think the short pause in reading software will be helpful. That leaves something to think about for the reference link but since its clear that it needs to be easilly distinguishable from the others perhaps we should dive deeper in earlier suggestions.
In my short research I also found that Voice Over perfectly read ::before and ::after content I had put on the link. This could offer an elegant solution in some cases but I'm uncertain of what way to best handle to translatable string in this case. |
What problem does this address?
In the Footnotes block, the return link to the main content only contains a unicode arrow character (↩︎):
<a href="#44929aa1-746d-417b-9c72-e431a4339eba-link">↩︎</a>
This seems like an issue for screen reader users. The screen reader will announce the name of the unicode character, with no other information about the link. I tested with two different screen readers:
The name of the character doesn't give much useful information to the users, who don't know what will happen when they click the return link.
What is your proposed solution?
Users should know what is the purpose of the link, and what action will be triggered when they click it.
A label like "Return to content – Note 1" would help make the return link more accessible for screen reader users. This could be achieved simply by adding an
aria-label
attribute to the<a>
tag.It could also be useful to add a more descriptive label to the reference link, something like
<a id="..." href="..." aria-label="Note 1">1</a>
.The text was updated successfully, but these errors were encountered: