Skip to content
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

Open
alinekeller opened this issue Sep 22, 2023 · 13 comments · Fixed by #54843 · May be fixed by #65727
Open

Footnote return link accessibility #54727

alinekeller opened this issue Sep 22, 2023 · 13 comments · Fixed by #54843 · May be fixed by #65727
Labels
[Block] Footnotes Affects the Footnotes Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.

Comments

@alinekeller
Copy link

alinekeller commented Sep 22, 2023

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:

  • NDVA with Chrome announces "link, Right arrow curving left";
  • VoiceOver with Safari announces "link, Leftwards arrow with hook with variation selector 15" (the french version of VoiceOver does not translate the name of the character, so it tries to read the english name with the french voice. This is completely incomprehensible).

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>.

@Mamaduka Mamaduka added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Block] Footnotes Affects the Footnotes Block labels Sep 22, 2023
@jordesign jordesign added the [Type] Enhancement A suggestion for improvement. label Sep 24, 2023
@sabernhardt
Copy link
Contributor

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.

@Mamaduka Mamaduka removed the [Type] Enhancement A suggestion for improvement. label Sep 26, 2023
@Mamaduka
Copy link
Member

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.

@alexstine
Copy link
Contributor

Partial fix here: #54843

Still needs visual work, CC @afercia .

@alexstine alexstine linked a pull request Sep 29, 2023 that will close this issue
@andrewserong andrewserong added the Needs Design Feedback Needs general design feedback. label Oct 1, 2023
@andrewserong
Copy link
Contributor

andrewserong commented Oct 1, 2023

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 idea

As raised in #54843 (comment)

  • Make the return link style configurable at the block level for the Footnotes block
  • Have newly added Footnotes block default to a new setting/style that displays the Footnotes return link in an accessible way (e.g. Return to [x] where [x] is the number of the footnote item to return to). This will ensure that the return link text is more readable and gives context to where the link goes to, while also increasing the size of the click target.
  • Still support the existing icon based return link for existing Footnotes blocks, and allow folks to select it as an option.

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.

@ellatrix
Copy link
Member

ellatrix commented Oct 3, 2023

Make the return link style configurable at the block level for the Footnotes block

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.

Have newly added Footnotes block default to a new setting/style that displays the Footnotes return link in an accessible way (e.g. Return to [x] where [x] is the number of the footnote item to return to). This will ensure that the return link text is more readable and gives context to where the link goes to, while also increasing the size of the click target.

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.

@andrewserong
Copy link
Contributor

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 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.

@DSGND
Copy link

DSGND commented Oct 5, 2023

Hi folks!

What about this POC?

This may complete this commit 9949351

ADD: arial-label
ADD: accessible content for the link

The content is hidden by default, then revealed on mouse over or focus state (keyboard TAB key navigation).

Markup HTML:

<a href="#3844ef6f-59fa-448b-836f-1c4ea9b722a8-link" aria-label="Jump to footnote reference [4]">↩︎ Jump to note [4]</a>

Markup CSS:

.wp-block-footnotes a[href*="-link"] {
    width: 12px;
    display: inline-block;
    text-wrap: nowrap;
    overflow: hidden;
    transition: width ease-in 10s;
}

.wp-block-footnotes a[href*="-link"] {
    width: 40px;
}

wp-footnotes-a11y

@jordesign jordesign added the [Type] Enhancement A suggestion for improvement. label Oct 9, 2023
@mrwweb
Copy link

mrwweb commented Oct 17, 2023

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.

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?

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.

@afercia
Copy link
Contributor

afercia commented Oct 27, 2023

I think the current option should be the default, given that 99% of all footnotes on the web look this way.

I'm not sure this is a good argumentation. Unfortunately, all the footnotes that 'look this way' are not accessible.

And the new aria-label gives additional info?

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.
As per the footnote number, I don't have a strong preference. It could be omitted as the ordered list already visually hints to the footnote number although the ordered list numbers and the footnote numbers are logically different objects.

Based on WCAG 2.2, the icon links violate at least 2 (and arguably more) success criteria:

@afercia
Copy link
Contributor

afercia commented Oct 27, 2023

As per the footnote number, I don't have a strong preference. It could be omitted

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

@rlautan rlautan linked a pull request Sep 30, 2024 that will close this issue
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Sep 30, 2024
@rlautan
Copy link

rlautan commented Sep 30, 2024

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:

<sup data-fn="{footnote_id}" class="fn"><a href="#{footnote_id}" id="{footnote_id}-link" aria-label="Go to footnote">1</a></sup>

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:

<li id="{footnote_id}">Footnote text <a href="#{footnote_id}-link" aria-label="Return to footnote reference in content - 1">↩︎</a></li>

It would be even better if the link to the footnote would add some more context to the aria-label like:

<sup data-fn="{footnote_id}" class="fn"><a href="#{footnote_id}" id="{footnote_id}-link" aria-label="Go to footnote - 1">1</a></sup>

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.

@afercia
Copy link
Contributor

afercia commented Sep 30, 2024

<a ... aria-label="Go to footnote">1

This would introduce a mismatch between the visible text and the actual accessible name.

2.5.3 Label in Name
https://www.w3.org/TR/WCAG22/#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.

@rlautan
Copy link

rlautan commented Sep 30, 2024

This would introduce a mismatch between the visible text and the actual accessible name.

2.5.3 Label in Name https://www.w3.org/TR/WCAG22/#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:
<sup data-fn="{footnote_id}" class="fn"><a href="#{footnote_id}" id="{footnote_id}-link" aria-label="Go to footnote: 1">[Footnote: 1]</a></sup>

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.

<li id="{footnote_id}">Footnote text <a href="#{footnote_id}-link" aria-label="Return to footnote reference in content: 1">↩︎ Return to footnote reference - 1</a></li>

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Footnotes Affects the Footnotes Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.
Projects
None yet