This will fix the problem for screen reader users, but it still leaves problems for voice command users who won't have any visible text on the link, and any time there are multiple footnotes, they'll all have the same visible control. I'd like to see these have at least the footnote number as visible text.

@joedolson Could that be done as a follow up iteration or is it important to hit both at the same time?

@apeatling It was a quick enough add and I think important enough that its included.

@andrewserong The goal is to have some type of visible text for sighted users that can direct them when using voice commands. The title attribute should be avoided due to the hover aspect to see the tooltip, I am sure this icon likely doesn't have a very large pointer hover range. I forgot about the <ol>, I am sure that doesn't look great visually with the numbers duplicated.

Really need to figure out how to make these links work for everyone. Another consequence in not doing an accessibility review to start. Had no idea this block joined Core in 6.3.

Brackets might make it better? Maybe hiding the numbers with CSS?

Thanks for the extra context, Alex! I'll add the Needs Design Feedback label, as I'm not too sure what the best solution would be for the presentation of the number, either. It could even wind up being something that folks might want to style in a unique way depending on the theme?

I'll just ping @ellatrix and @jameskoster, too in case either of them have an idea for a good path forward.

I don't really see a visual problem with the repeated. numbers Technically, the numbers represent different loci: the ordered list represents the footnotes, and the link text represents the footnote locations. They should, of course, always match, but they are literally different objects.

I like seeing an instructive link text, e.g. "Return to [1]", and it would be nice if that was at least an option for the user.

As for priorities, the number one priority is making sure that there is a label on these links. Right now, there isn't one, and that's a serious accessibility flaw. I would like to have the number visible, and I'd like to see an option for something more substantial - longer text that provides a larger click target, etc. But I'd like to consider those as two separate tasks: first let's ensure that 6.4 ships without this major accessibility flaw, then let's figure out how we can enhance the accessibility.

I'd be happy to go with what this patch does as is; but if design can't agree on it, I can accept the screen reader only solution while we work out enhancements.

For reference, this was introduced in #51201

It's saddening seeing even very basic semantics and accessibility not being considered at all. Also saddening seeing not-accessible code being merged and, more importantly, released so lightly. A link that only contains an arrow character:

<a href="#%1$s-link">↩︎</a>

is, honestly, not acceptable after years of discussions around accessibility.

The goal is to have some type of visible text for sighted users that can direct them when using voice commands.

The intent is good but that wouldn't be fully accessible anyways. Regardless of the presence of the index number, the visible text and the aria-label would mismatch. For example:

• visible text: 2 ↩︎
• aria-label: Back to footnote reference 2

As such, speech recognition software users wouldn't have a clue what voice command to issue. This would also be a violation of WCAG Label in Name.

One more non-fully-accessible example is from Wikipedia, which uses a visible 'caret' character and the aria-label mismatches:

<a href="#cite_ref-5" aria-label="Jump up" title="Jump up">^</a>

Note: sometimes the aria-lable is Jump up, sometimes Jump back up, not sure why.

Overall, the only fully accessible option is what @joedolson suggested: visible, meaningful text:

Return to [2]

Should be the default output. We could maybe consider to add an option to only output an arrow, but that should be accompanied with a warning in the editor to inform users the link wouldn't be fuly accessible. For no reason, ever, WordPress should output or encourage usage of non-accessible markup.

I don't personally have a problem with Return to [x], though I'd suggest "Jump" or "Go" instead of "Return" as you may not always be returning.

As such, speech recognition software users wouldn't have a clue what voice command to issue. This would also be a violation of WCAG Label in Name.

Just for clarity/learning, how is this not an issue for linked icons? i.e. social icons that do not use a text-based "icon".

@afercia Part of me has always wondered why we have aria-label if it is required to match the same text, according to 2.5.3. It is redundant and not super helpful. For example, if this is an accessibility violation, why bother having an attribute for accessible naming?

<a href="www.google.com" aria-label="Open Google in new tab" target="_blank">Google <span class="new-tab-icon" aria-hidden="true"></span></a>

Under this WCAG rule, it would be valid to do this.

<a href="www.google.com" target="_blank">Google, opens in new tab</a>

Sounds like navigational tools driven by voice need to start adapting as screen reader developers have because there will never be a world where UI designers are okay with "Google, opens in new tab" being visible to everyone. Icons take up less space and I guess, look better but the last part is something I wouldn't know anything about.

Anyway, there is yet another one of my complaints for the WCAG 2.1 guidelines and how we do things on the web. Maybe 3.0 will bring some much needed clarity on dealing with this ever increasing sighted world.

Maybe dictation software needs an elements list? Something that visually shows accessible names of links? It would make navigation slower so I see why the visible text is a requirement without the accessible name.

@richtabor Icons would suffer from the same issue. No meaningful label. I believe that's why Gutenberg editor has the text-only option.

In order to land this bug fix in 6.4, should I revert the visual changes? Are we okay with having visible "Jump to X" text? I am flexible.

Thanks.

Great discussion here, folks!

In order to land this bug fix in 6.4, should I revert the visual changes?

I'd lean toward reverting the visual change so that we can land this PR for now, that way a little more time can be given to considering the best path forward for changing things visually. Since the existing behaviour is already live on production sites running 6.3, I imagine some folks could be sensitive to changes made to how the block appears on their sites, so we might want to tread carefully in implementing the visual change. I quite like the idea mentioned about making the return link style configurable in the editor.

@andrewserong Done.

Just for clarity/learning, how is this not an issue for linked icons? i.e. social icons that do not use a text-based "icon".

@richtabor this is why I (and may other a11y specialists) personally insist on avoiding icon buttons. icon buttons should at least visually expose their accessible name in some way. In the editor we introdeuced the Tooltip component for that reason, but it's already a big compromise. Ideally, buttons should have visible text.

I'd liek to point out that all these issues have been discussed at length in the history of this project. As Accessibility team we provided plenty of feedback and also run user testing, but seems that many web designers and developers in this project still fon't get some fundamental points. After more than 6 years of the editor development I'd expect everyone to be familiar with some basic understanding of how the deviced and technologies we are suppose dto support actually work.

I'd like to remind everyone that the Accessibility team is now running Office Hours to discuss general accessibility principles and best practices. That's a learning opportunity for everyone and certainly a better place to discuss this kind of things, instead of going off-toopic in a GitHub issue.

For now, I can quickly point to some discussione and resources to get more familiar with speech recognition software.

• Feedback from Eric Wright @ewaccess on this issue: Improve "Visibility" and "Publish" labels in Post Settings #470 (comment)
• One hour user testing session video linked on this post from March 2018 (5 years ago): https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/

Edit:
I'd also like to remind everyone that, for those who are using macOS, Voice Control is built-in in your operating system and tou can start familiarazing with speech recognition software right now.

Part of me has always wondered why we have aria-label

@alexstine as you know, aria-label overrides any textual content (it any). However, it should never be used to completely alter the visible text. It is also meant to provide an accessible name to non-interactive elements and ARIA widgets that do not use any text. For example, to label a navigation landmark.

Theoretically it can be used to expand some visible text to provide more context. But that's very risky. The Label in Name criterion requires the accessible name to contaiin the text that is presented visually. I'd arrgue on the term 'contain': that wouldn't actually work with speech recongition software.

This markup example:

<a href="www.google.com" aria-label="Open Google in new tab" target="_blank">Google</a>

would be formally compliant because the accessible name does contain the visible text Google. I'd invite everyone to try this with a speech recognirion software. It doesn't work with Voice Control. I'm assuming it doesn't work with Dragon as well.

Based on my testing, the accessible name must at least start with the visible text. But also in that case sometimes it just doesn't work. This leads us to a big problem. We have to blame ourselves for the way we used screen-reader-text and aria-labels in the codebase across the years. In many cases, what we did is just optimization for screen readers but it's not really fully accessible, as it introduces barriers for other assistive technologies and thus for other users. I think this would worth a good discussion in the Accessibility team and we should reconsider the way we used these techniques.

because there will never be a world where UI designers are okay with "Google, opens in new tab" being visible to everyone.

I'd argue that in a software that aims to be accessible, that's exactly what designers should understand: use visible text whenever possible. Icon buttons are always a problem, also visually.

Maybe dictation software needs an elements list? Something that visually shows accessible names of links?

I'd tend to think that should be a browser feature. In an ideal world.

@alexstine @andrewserong
has a follow-up issue been created already?

I quite like the idea mentioned about making the return link style configurable in the editor.

Yes, I think we should do that. But we should change the default, at least for new posts.

I'd like to be very clear that this PR is only a partial improvement and only optimizes for screen readers. These links are still not accessible and need to be fixed.

For the future, I'd not recommend to merge changes that fix accessibility for only a specific assistive technology. That's not accessibility as it doesn't really provide universal access for everyone. Personally, I'm not sure I'm happy to support changes that improve things for some users at the expenses of other users. That is not inclusive and I think it's ethically not acceptable. Thanks.

For clarity, I only would accept this partial solution because we have already shipped something that's extremely broken. The icon for this scenario has multiple problems: one of those is the lack of an accessible name. Fixing that is crucial, and should happen as soon as possible. I actually think that should be put into 6.3.2, and a fuller fix should go into 6.4.

The additional problems include very small click targets and lack of visible text.

@afercia Also, very much willing to continue this discussion in the next Accessibility Team office hours if I can make it next week.

I fixed what I could fix and I agree its not great that we only patched for a subset of users. Hopefully someone who can take care of visuals can pick up where I left off.

No follow-up issue was created by me.

I'd liek to point out that all these issues have been discussed at length in the history of this project. As Accessibility team we provided plenty of feedback and also run user testing, but seems that many web designers and developers in this project still fon't get some fundamental points. After more than 6 years of the editor development I'd expect everyone to be familiar with some basic understanding of how the deviced and technologies we are suppose dto support actually work.

I'd like to remind everyone that the Accessibility team is now running Office Hours to discuss general accessibility principles and best practices. That's a learning opportunity for everyone and certainly a better place to discuss this kind of things, instead of going off-toopic in a GitHub issue.

@afercia Learning is much more connective in context, and should be welcomed. Discouraging questions would be detrimental to all aspects of the editor—not just accessibility. To be frank, this sentiment discourages progress. We should be encouraging developers to ask questions, to learn, to express curiosity, to grow—anywhere and everywhere.

For the future, I'd not recommend to merge changes that fix accessibility for only a specific assistive technology. That's not accessibility as it doesn't really provide universal access for everyone. Personally, I'm not sure I'm happy to support changes that improve things for some users at the expenses of other users. That is not inclusive and I think it's ethically not acceptable. Thanks.

I'm of the notion that every iteration matters, big or small. The key is not to settle—nor forget—but rather to consistently build upon what we've built so far.

I just cherry-picked this PR to the commits-for-6.4-beta2 branch to get it included in the next release: 9949351

Thanks for the continued discussion, folks! Discussion about best practices is a great thing to do in code reviews in Github, as it helps improve visibility for the issues for contributors working day to day in the code base (especially new contributors), and creates good exposure to accessibility principles that folks might not have learnt otherwise. This is quite similar to how we might discuss other best practices relevant to code changes, i.e. how to use new CSS features, or how to optimise React hooks, for example.

For features (or bugs) that already exist in trunk, and where the PR doesn't impede future iterations, I think it's good for us to land improvements in smaller increments to ensure we can improve things in a progressive way, as Rich touches on. As a developer, I believe this makes it easier to tackle larger problems, by breaking them down into smaller steps.

has a follow-up issue been created already?

The issue in #54727 already covers the accessibility issues for return links. That issue hasn't been closed yet, since this PR didn't resolve it entirely. I've added a comment to that issue to capture the discussed ideas for next steps: #54727 (comment)

Let's continue the discussion and ideas for follow-ups over on that issue.