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

Footnotes: Add aria-label to return links #54843

Merged
merged 4 commits into from
Sep 28, 2023

Conversation

alexstine
Copy link
Contributor

What?

Adds aria-label to the front-end footnotes return links.

Why?

Links with icons are not accessible.

How?

Adds the aria-label attribute.

Testing Instructions

  1. Insert a footnotes block.
  2. Create a footnote from a paragraph block by selecting More and then Footnote in the block toolbar.
  3. Save.
  4. View the front-end.
  5. Notice how the link has aria-label="Back to footnote reference X" for the number.

Testing Instructions for Keyboard

Screenshots or screencast

@alexstine alexstine added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility [Block] Footnotes Affects the Footnotes Block labels Sep 26, 2023
@alexstine alexstine self-assigned this Sep 26, 2023
@joedolson
Copy link
Contributor

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.

@apeatling
Copy link
Contributor

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

@alexstine
Copy link
Contributor Author

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

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change here looks good to me. Unfortunately the visual addition of the index next to the return character looks a little off to me.

If we're including that visually, I'd recommend we get some design feedback on the appearance. E.g. should we wrap the number in braces, brackets, or use <sup> to match the numbering when it exists in post content?

Here's a screenshot of how it's looking now:

image

From a visual perspective the additional number looks a little redundant to me because the footnotes use an ordered list, so there appears to be duplication of numbering. Another potential alternative might be to use a title attribute for the Back to footnote text?

If we'd like to get the aria-label fix in sooner, though, one option could be to remove the numbering from the visual content of the link for now, and we could look at the visual numbering in a follow-up, potentially.

Hope that helps, and apologies if I'm missing some context here!

@alexstine
Copy link
Contributor Author

@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?

@andrewserong andrewserong added the Needs Design Feedback Needs general design feedback. label Sep 27, 2023
@andrewserong
Copy link
Contributor

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.

@joedolson
Copy link
Contributor

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.

@afercia
Copy link
Contributor

afercia commented Sep 27, 2023

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.

@afercia
Copy link
Contributor

afercia commented Sep 27, 2023

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.

@jameskoster
Copy link
Contributor

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.

@richtabor
Copy link
Member

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

@alexstine
Copy link
Contributor Author

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

@andrewserong
Copy link
Contributor

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.

@alexstine
Copy link
Contributor Author

@andrewserong Done.

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the follow-up @alexstine, this is testing great for me and the code change is good. This feels like a good pragmatic step forward to me. LGTM! ✨

@andrewserong andrewserong added the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Sep 28, 2023
@alexstine alexstine merged commit 88c8c66 into trunk Sep 28, 2023
50 checks passed
@alexstine alexstine deleted the fix/footnotes-front-end-unlabeled-links branch September 28, 2023 05:44
@github-actions github-actions bot added this to the Gutenberg 16.8 milestone Sep 28, 2023
@afercia
Copy link
Contributor

afercia commented Sep 28, 2023

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.

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.

@afercia
Copy link
Contributor

afercia commented Sep 28, 2023

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.

@afercia
Copy link
Contributor

afercia commented Sep 28, 2023

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

@joedolson
Copy link
Contributor

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.

@alexstine
Copy link
Contributor Author

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

@richtabor
Copy link
Member

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.

mikachan pushed a commit that referenced this pull request Sep 29, 2023
* Add aria-label to footnotes front-end links.

* Add visual output. Fix PHPCS errors.

* Remove visual changes, fix in follow-up.
@mikachan
Copy link
Member

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

@mikachan mikachan removed the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Sep 29, 2023
@alexstine alexstine linked an issue Sep 29, 2023 that may be closed by this pull request
@andrewserong
Copy link
Contributor

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.

fluiddot pushed a commit that referenced this pull request Oct 2, 2023
* Fix the install of system fonts from a font collection (#54713)

* Fix set upload dir test (#54762)

* Site Editor: Prevent unintended actions on the classic theme (#54422)

* Add action and selector to track access to Patterns page

* Add a URL parameter to check if the Patterns page was accessed directly

* Revert lib changes

* Fix critical error in the Post Editor

* Explicitly add `! isBlockBasedTheme` with `isTemplatePartsMode`

* Fix critical error in the Post Editor

* Patterns: Fix back navigation after pattern creation (#54852)

* Patterns: Fix category control width in site editor (#54853)

* Patterns: Allow non-user patterns under Standard filter (#54756)

* Performance Tests: Separate page setup from test (#53808)

# Conflicts:
#	test/performance/specs/post-editor.spec.js

* Performance Tests: Support legacy selector for expanded elements (#54690)

* Paragraph: Make 'aria-label' consistent with other blocks (#54687)

* Paragraph: Make 'aria-label' consistent with other blocks

* Update tests

* Try using BC labels in performance tests

* Move lightbox render function to filter (#54670)

* syntax refactor repace strpos with str_contains (#54832)

* Font Library: avoid deprected error in test (#54802)

* fix deprecated call

* removing unwanted line

* Fix the ShortcutProvider usage (#54851)

Co-authored-by: Marin Atanasov <8436925+tyxla@users.noreply.github.com>

* Image: Ensure `false` values are preserved in memory when defined in `theme.json` (#54639)

* Modify conditional when parsing config

* Only drop the value if it's undefined.

---------

Co-authored-by: Michal Czaplinski <mmczaplinski@gmail.com>

* Use "Not synced" in place of "Standard" nomenclature for patterns (#54839)

* Standard -> Not synced

* Fix broken test

---------

Co-authored-by: Glen Davies <glen.davies@automattic.com>

* Format Library: Try to fix highlight popover jumping (#54736)

* Move mime-type collection generation to a function that can be tested… (#54844)

* Move mime-type collection generation to a function that can be tested.  Refactored to use that function.

* linting changes

* Add unit tests to mime type getter

* Fixed linting errors

* test the entire output array and replace assertTrue by assertEquals

* fixing docs

---------

Co-authored-by: Matias Benedetto <matias.benedetto@gmail.com>

* Ensure lightbox toggle is shown if block-level setting exists (#54878)

* Block Editor: Update strings in blocks 'RenameModal' component (#54887)

* Footnotes: Add aria-label to return links (#54843)

* Add aria-label to footnotes front-end links.

* Add visual output. Fix PHPCS errors.

* Remove visual changes, fix in follow-up.

* Font Library: Changed the OTF mime type expected value to be what PHP returns (#54886)

* Changed the OTF mime type expected value to be what PHP returns

* add unit test for otf file installation

---------

Co-authored-by: madhusudhand <madhusudhan.dollu@gmail.com>

* Image: Fix layout shift when lightbox is opened and closed (#53026)

* Replace overflow: hidden with JavaScript callback to prevent scrolling

* Disable scroll callback on mobile; add comments; fix scrim styles

The page jumps around when trying to override the scroll behavior
on mobile, so I disabled it altogether. I've also added comments
to clarify this and other decisions made around the scroll handling.

While testing, I realized that the scrim was completely opaque during
the zoom animation, which does not match the design, so I added a new
animation specifically for the scrim to fix that.

* Add handling for horizontally oriented pages

* Move close button so that it's further from scrollbar on desktop

* Fix call to handleScroll() and add touch callback to new render method

* Improve lightbox experience on mobile

To ensure pinch to zoom works as expected when the lightbox
is open on mobile, I added logic to disable the scroll override
when touch is detected. Without this, the scroll override kicks
in whenever one tries to pinch to zoom, and it breaks the experience.

I also revised the styles for the scrim to make it opaque, as having
content visible outside of the lightbox is distracting when
pinching to zoom on a mobile device, and I think having a consistent
lightbox across devices will make for the best user experience.

* Fix spacing

* Add touch directives to block supports

* Fix spacing in block supports

* Rename attribute for clarity

* Update comment

* Update comments

* Fix spacing

---------

Co-authored-by: Ricardo Artemio Morales <ric.morales22@gmail.com>

* Font Library: move font uploads to a new tab (#54655)

* move font uploads to a new tab in the modal

* fix invalid success message and revert the dropzone to modal

* add success notice for font uploads

* make supported file formats message dynamic based on allowed extensions

* update hint text and clear successful message with a fresh upload

* Block custom CSS: Fix incorrect CSS when multiple root selectors (#53602)

* Block custom CSS: Fix incorrect CSS when multiple root selectors

* Fix PHP lint error

* Use `scope_selector` and `append_to_selector` method and update unit test

* Use `scopeSelector` and `appendToSelector` function and update JS unit test

* Update packages/block-editor/src/components/global-styles/test/use-global-styles-output.js

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>

* Update packages/block-editor/src/components/global-styles/test/use-global-styles-output.js

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>

* Update packages/block-editor/src/components/global-styles/test/use-global-styles-output.js

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>

* Update packages/block-editor/src/components/global-styles/test/use-global-styles-output.js

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>

* Update packages/block-editor/src/components/global-styles/utils.js

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>

* re-trigger CI

---------

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>

* Add new e2e test for creating a pattern (#54855)

* Use list role instead of listbox for patterns (#54884)

* Popover: Fix the styles for components that use emotion within popovers (#54912)

# Conflicts:
#	packages/components/CHANGELOG.md

* Footnotes: use core’s meta revisioning if available (#52988)

# Conflicts:
#	packages/block-library/src/footnotes/index.php

* Remove base url from link control search results  (#54553)

* Expose baseURL setting on Post and Site Editors via block settings

* Strip baseURL from rendered search results

* Only fetch baseURL once in top level component

* Simplify implementation to utilise URL parse functions

* Improve comment wording to avoid referencing undefined var

* Remove superfluous conditional

* Decode URL prior to operations

* Refactor for readability

* Fix where url is not defined

* Revert change to filter util

* Ensure that filterURLForDisplay always receives a string as an arg

* Make e2e test locator less strict

* Prefer pipe

* Force remove trailing slash

* [Site Editor]: Update copy of using  the default template in a page (#54728)

* Remove overflow: hidden from the entity title h1 in the site editor sidebar (#54769)

* Site Editor: Avoid same key warnings in template parts area listings (#54863)

* TemplateAreas use template part clientId as key
* HomeTemplateDetails use template part clientId as key
* Cleanup useSelect hook

* Fix ToolSelector popover variant (#54840)

* Font Library: refactor endpoint permissions (#54829)

* break the checking of user permission and file write permissions

* return error 500 if the request to the install fonts endpoint needs write permissions and wordpress doens't have write permission on the server

* do not ask file write permission on uninstall endpoint

* Standardize the output of install and uninstall fonts endpoints

Co-authored-by: Jason Crist <146530+pbking@users.noreply.github.com>
Co-authored-by: Jeff Ong <5375500+jffng@users.noreply.github.com>

* Handle standardized output from install and uninstall endpoints in the frontend

Co-authored-by: Jason Crist <146530+pbking@users.noreply.github.com>
Co-authored-by: Jeff Ong <5375500+jffng@users.noreply.github.com>

* Update the install and unintall fonts endpoints unit tests for the new standardized output format

Co-authored-by: Jason Crist <146530+pbking@users.noreply.github.com>
Co-authored-by: Jeff Ong <5375500+jffng@users.noreply.github.com>

* fix the refersh call for the library

Co-authored-by: Jason Crist <146530+pbking@users.noreply.github.com>
Co-authored-by: Jeff Ong <5375500+jffng@users.noreply.github.com>

---------

Co-authored-by: Jason Crist <146530+pbking@users.noreply.github.com>
Co-authored-by: Jeff Ong <5375500+jffng@users.noreply.github.com>

* Don’t use TypeScript files in scripts package (#54856)

* Fix Search Block not updating in Nav block (#54823)

* Avoid setState in render

* Attempt at test coverage

* Improve tests and make them work

* Remove word-wrap property (#54866)

---------

Co-authored-by: Matias Benedetto <matias.benedetto@gmail.com>
Co-authored-by: Aki Hamano <54422211+t-hamano@users.noreply.github.com>
Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>
Co-authored-by: Bart Kalisz <bartlomiej.kalisz@gmail.com>
Co-authored-by: George Mamadashvili <georgemamadashvili@gmail.com>
Co-authored-by: Artemio Morales <artemio.morales@a8c.com>
Co-authored-by: Riad Benguella <benguella@gmail.com>
Co-authored-by: Marin Atanasov <8436925+tyxla@users.noreply.github.com>
Co-authored-by: Michal Czaplinski <mmczaplinski@gmail.com>
Co-authored-by: Rich Tabor <hi@richtabor.com>
Co-authored-by: Glen Davies <glen.davies@automattic.com>
Co-authored-by: Jason Crist <jcrist@pbking.com>
Co-authored-by: Alex Stine <alex.stine@yourtechadvisors.com>
Co-authored-by: madhusudhand <madhusudhan.dollu@gmail.com>
Co-authored-by: Carlos Bravo <37012961+c4rl0sbr4v0@users.noreply.github.com>
Co-authored-by: Ricardo Artemio Morales <ric.morales22@gmail.com>
Co-authored-by: Kai Hao <kevin830726@gmail.com>
Co-authored-by: Adam Silverstein <adamjs@google.com>
Co-authored-by: Dave Smith <getdavemail@gmail.com>
Co-authored-by: Nik Tsekouras <ntsekouras@outlook.com>
Co-authored-by: Ramon <ramonjd@users.noreply.github.com>
Co-authored-by: Jason Crist <146530+pbking@users.noreply.github.com>
Co-authored-by: Jeff Ong <5375500+jffng@users.noreply.github.com>
Co-authored-by: Pascal Birchler <pascalb@google.com>
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 Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback.
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Footnote return link accessibility
8 participants