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

Accessibility: Try adding the keyboard navigation/edit mode #5709

Closed
wants to merge 13 commits into from

Conversation

youknowriad
Copy link
Contributor

refs #5694

Adding the navigation/edit mode can be very impacting for the edit flow, so it's best to try to do it by steps.

In this PR.

  • tabbing navigate to blocks directly
  • Enter enters "edit" mode
  • Escape moves back to navigation mode

The drawback of the edit/navigation mode is that it's not possible to create an empty paragraph after the selected block by clicking "Enter", since "Enter" is the key used to move to edit mode. Is this acceptable?

Need help testing the different writing flow interactions to ensure there's no other regression.

@youknowriad youknowriad added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Mar 20, 2018
@youknowriad youknowriad self-assigned this Mar 20, 2018
@@ -129,13 +130,15 @@ class ButtonBlock extends Component {
onSubmit={ ( event ) => event.preventDefault() }>
<Dashicon icon="admin-links" />
<UrlInput
autoFocus={ false }
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Without this, the input was being focused when you tab to the button block.

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like an explanation worth attaching to the eslint-disable comment. :)

@@ -65,10 +65,14 @@ class NavigableContainer extends Component {
this.props.onKeyDown( event );
}

if ( this.props.disabled ) {
return;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a way to disable the tabbableContainer behavior without replacing the component (to avoid rerenders)

if ( TAB === keyCode ) {
const eventToOffset = ( evt, container ) => {
const { keyCode, shiftKey, target } = evt;
if ( TAB === keyCode && target.parentElement === container ) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The tabbable container behavior triggers only if we're currently focusing one of its children.

@youknowriad youknowriad requested a review from mcsf March 20, 2018 11:52
@jasmussen
Copy link
Contributor

🔥 thank you for working on this.

I think the ingredients for something great are here.

The behavior is a little bit confusing, it's easy to lose your place:

navigation

In this, I start by tabbing through blocks. Enter then enters the block, where pressing the Tab key now cycles the block UI. Only until I press escape, where tab now switches between blocks again. How do I get back to cycling through the block UI? How would I know to press Enter first?

Part of this confusion can be mitigated visually, by not showing the block toolbar or side UI in navigation mode, perhaps even highlighting the block in blue (like multi select) instead of showing the side UI.

Another part of the confusion is that only tab switches between blocks. Why don't arrowkeys? Given that this is an editor, the arrowkeys are so crucial to moving up and down the content, it feels weird when that jumps straight into edit mode and starts navigating with the caret. It feels brittle and not as modal as I think navigation mode would have to be in order to work.

Windows 10 has an interesting approach to keyboard navigation. Tab navigates between sections in a modal. Arrow keys then navigates items in that section:

windows 10

In the above GIF I'm first tabbing between the three columns of the start menu, then arrow-keying inside each section.

Perhaps something similar can work for us?

  • You start in navigation mode, and arrowkeys navigate between blocks. Tab and shift tab does the same.
  • Blocks are multi-select blue when selected in navigation mode.
  • Enter enters them where you get a caret, and the caret can also be used to navigate between blocks just like it can today.
  • In Edit mode, tab is used to access the side UI and block toolbar.

The chief benefit of this approach would be it would not be a new mode we add on top of what we already have. It would essentially be a set of keyboard enhancements to our existing multi select mode. See also this very long document I wrote about that here: #4382 (comment)

Notion.so works similarly to this, if you have questions about how this feels I'd recommend giving that a shot.

The biggest challenge with this branch is that you don't really know that you're in a mode, so the behavior of Tab is unpredictable. It's also confusing because even in edit mode, you can tab through all the blocks, because in this mode, tab tabs through EVERYTHING.

Immediate small steps to try would be:

  • In navigation mode, highlight a block same way as a multi selected block. Like this.
  • Arrow keys in navigation mode should not enter editing mode, they should switch between blocks, even if Tab and Shift Tab also did this. If you click text or press Enter to enter edit mode, the arrow key would work as it does in master now.
  • When you tab from the Title field to the prompt that currently says "Write your story", you are still in Edit mode, and you can just start typing.
  • Mousing around, keeps you in edit mode.

Future steps to explore could be:

  • Should tabbing in edit mode be modal to the block you're editing? You'd still be able to use arrow keys, or press Escape to enter navigation mode, to pick a different block you could then tab through.
  • Delete or Backspace when in navigation mode could remove the entire block.
  • Escape in navigation mode deselects everything.
  • Multi select with shift also works in navigation mode.

Copy link
Contributor

@mcsf mcsf left a comment

Choose a reason for hiding this comment

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

Nice, this feels like a solid start. I think it's worth keeping this PR small and address the following points later:

  • I'm not a screen reader user, and hopefully @afercia will provide better insight, but I have some expectation that pressing Escape when in navigation mode could take me out of the "blocks loop"; perhaps non-intuitively, the only way to move focus back to the WP-Admin sidebar is to tab to the last block, press Enter to switch to edit mode, then tab out of the block list.
  • Since pointer actions have no impact on the keyboard mode, behavior may be inconsistent for users who combine pointer and keyboard interactions. For instance, a user clicks into some text, edits, then tabs away; depending on their previous sequence of Enter/Escape input, tabbing may happen in either keyboard mode — seemingly randomly. This is naturally a minor point.

@@ -129,13 +130,15 @@ class ButtonBlock extends Component {
onSubmit={ ( event ) => event.preventDefault() }>
<Dashicon icon="admin-links" />
<UrlInput
autoFocus={ false }
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like an explanation worth attaching to the eslint-disable comment. :)

renderBlockMenu={ renderBlockMenu }
/>
) ) }
<TabbableContainer disabled={ this.state.keyboardMode !== 'navigation' } restrictNavigationToChildren>
Copy link
Contributor

Choose a reason for hiding this comment

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

I suspect restrictNavigationToChildren is a leftover artifact.

return;
}

this.focusFirstTextFieldOrContainer( -1 === initialPosition );
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor, but I find readability to be improved by doing:

const isReverse = -1 === initialPosition;
this.focusFirstTextFieldOrContainer( isReverse );

@youknowriad
Copy link
Contributor Author

This is not easy to get right. I agree we should leave this PR small because if we try to make everything right here, this will never land as it's too complex.

So I'm proceeding by small steps and would love if you could tell me what the minimum required to land this.

In my last commit I try to solve this issue:

I'm not a screen reader user, and hopefully @afercia will provide better insight, but I have some expectation that pressing Escape when in navigation mode could take me out of the "blocks loop"; perhaps non-intuitively, the only way to move focus back to the WP-Admin sidebar is to tab to the last block, press Enter to switch to edit mode, then tab out of the block list.

The approach I took is to avoid cycling through blocks and navigate away when we reach the end. I'm not totally happy with the code though, it seems too complex for a small enhancement. Can't think of an alternative though. What do you think?

@jasmussen
Copy link
Contributor

Small PRs sound good, and hopefully better devs will chime in with code feedback. Ideally, though, each step along the way brings with it something useful, with as few regressions as possible. Here are some thoughts as to what would be the minimum amount we need necessary in order to progress.

The chief challenge in this branch as is, is that it's impossible for a user to know when they are in navigation mode, and when they are in edit mode. Since the Tab button acts differently depending on mode, this will cause confusion as to when tab switches between blocks, and when it enters the movers/ellipsis/block toolbar.

In that vein, perhaps in order to move on, the only change we need to do is to hide the mover, the block toolbar, and the ellipsis when in navigation mode. You'd only see the 1px border.

Everything else could be intact and work as it used to, even exiting navigation mode by using the arrow keys. What do you think?

@youknowriad
Copy link
Contributor Author

In that vein, perhaps in order to move on, the only change we need to do is to hide the mover, the block toolbar, and the ellipsis when in navigation mode. You'd only see the 1px border.

When do you decide to show the movers and the block toolbar in that case since when you use the mouse, to click etc.. the mode is not changed?

@jasmussen
Copy link
Contributor

When do you decide to show the movers and the block toolbar in that case since when you use the mouse, to click etc.. the mode is not changed?

As soon as you hover a block, or click a block, you are in edit mode.

Maybe just moving the mouse puts you in edit mode.

@afercia
Copy link
Contributor

afercia commented Mar 22, 2018

Thanks for working on this, pretty excited after some first testing.

I'd tend to agree with many of the considerations made here. Trying to proceed step by step, the main thing I see now is the "blocks loop" dilemma. As @mcsf pointed out, there's no way to exit the loop and I totally agree with @youknowriad: there shouldn't be a loop in the first place 🙂

One of the main goal of this experiment is to put the blocks in a natural tab order. Once on the last block (or the first when shift-tabbing) the expected behavior would be being able to continue tabbing the UI in a natural tab order.

As per the expected interaction when using a screen reader, there's a big difference in terminology and "arrowing" is the default way to explore all content. Without entering into details about what browse mode and forms mode are, I think the best option is trying to emulate the interaction model users would expect in a form, where tabbing navigates through the form controls. I'm not fully convinced arrowing should navigate through blocks, that wouldn't be expected. Comparison with desktop UIs (Windows 10 start menu) is a bit misleading as they're built following an interaction model that is close to the one some ARIA widgets use (e.g. tabs or grids) but it's very different from the one expected in web forms.

@joen I'd tend to agree in navigation mode the blocks UI shouldn't be displayed. Navigation mode should be just that: navigation :) I'd agree the "modes" should be made clear and communicated to users. For sure, keyboard interaction in a complex application requires documentation and an user guide (see #5420) but I'd tend to agree the modes should be communicated also visually.

Should tabbing in edit mode be modal to the block you're editing?

I'd tend to say yes but I guess this could be addressed in a future iteration? See also the initial a11y recommendations in #297

treating each content area as a modal once it has focus might be a good idea. The advantage is that it forces the context to be contained within the editable area.

Regarding:

The drawback of the edit/navigation mode is that it's not possible to create an empty paragraph after the selected block by clicking "Enter", since "Enter" is the key used to move to edit mode.

But it is still possible when in Edit mode, right?

Lastly: as a final step, there will be the need to give a role and properly label the container where focus lands in navigation mode. We already use a label for the blocks, I think that should be moved. Currently, when using a screen reader and landing in navigation mode on a block, all the content of the block gets announced because that container has no semantics, it's just a div with a tabindex="0". See below testing with Firefox and NVDA:

  • ignore the red border, that's from a plugin I use to test focusable elements
  • on the right: all the block content gets announced when a block is focused

screenshot 86

@youknowriad
Copy link
Contributor Author

Thanks for your feedback all.

Before trying to add the visual distinction suggested by @jasmussen between the two modes, I'm trying an alternative technical approach to this issue relying on the WritingFlow component in this branch https://github.com/WordPress/gutenberg/compare/try/writing-flow-edit-mode

I'm thinking it's a better approach that scales better. I'm waiting for feedback here on this second approach before continuing.

@jasmussen
Copy link
Contributor

Nice work Riad. I tried the try/writing-flow-edit-mode branch, and it seems to work well there as well.

One thing I noticed in that branch, is that arrowkey navigation doesn't exit edit mode and give you the caret like it does in this branch. I know I noted that wasn't desirable earlier on — but I feel like either the arrow-keys should exit navigation mode and enter edit mode with the caret, or the arrowkeys should work for navigating between blocks in edit mode.

The more I think about it, though, the more I think (unlike my past assumption) that maybe it's good that the arrow key exits navigation mode. Unsure. But in either case, the arrowkeys should do something in navigation mode.

Otherwise, seems good!

@youknowriad
Copy link
Contributor Author

youknowriad commented Mar 22, 2018

One thing I noticed in that branch, is that arrowkey navigation doesn't exit edit mode and give you the caret like it does in this branch.

Good catch and I did it on purpuse :). My idea was that moving the mouse will trigger edit mode, so maybe it's fine that in navigation mode, the arrows do nothing. That said, it's easily tweakable. We can either navigate the blocks like the tabs, keep the caret navigation or do nothing. your choice :).

This flexibility is harder to achieve in the current branch though :)

@jasmussen
Copy link
Contributor

Love the sound of that. Then we should go with what seems best intellectually for now, and then tweak and adjust as we test it in master. 👍 👍 🔥

@afercia
Copy link
Contributor

afercia commented Mar 22, 2018

Nice work!

Couple things: while we're here, can we please move the aria-label={ blockLabel } to the div that gets focused in navigation mode? I'd also add a role="group" for now (will check if there's a more appropriate role). I've tested it and good news!

  • Safari + VoiceOver
  • IE11 + JAWS 2018
  • Firefox + JAWS 2018

they all correctly announce the type of the block, which is what we want:

screen shot 2018-03-22 at 14 40 48

This is ideal because users will have an immediate feedback while navigating through the blocks. For example:

  • press tab -> "Block: Cover Image"
  • press tab -> "Block: Paragraph"
  • and so on

Instead, Firefox + NVDA 2018.1 do announce, for example, "Block: Paragraph" but they announce also the whole content of the block including the movers, formatting toolbar etc. A bit unfortunate, but seems to me a peculiar behavior of NVDA and can probably be improved using a more appropriate role. Will try to iterate on this.

@youknowriad thanks very much. I've just noticed a small thing, please check if you can reproduce, when you have a chance:

  • add a title and a couple paragraphs, for example:

screen shot 2018-03-22 at 14 57 48

- in navigation mode, tab to the second paragraph - tab again - the "insertion point" button doesn't appear and focus goes to the sidebar (if it's open)
  • now Shift+Tab from the sidebar to the blocks list
  • the "insertion point" button appears and gets focused
  • Shift Tab again: the second paragraph is skipped

Not sure what the best option is, but I'd tend to think the last "insertion point" should always appear.

Of course, the behavior is different if the last block is, for example, an image.

Copy link
Contributor

@afercia afercia left a comment

Choose a reason for hiding this comment

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

Please see last comment

@youknowriad
Copy link
Contributor Author

  • in navigation mode, tab to the second paragraph - tab again - the "insertion point" button doesn't appear and focus goes to the sidebar (if it's open)
    now Shift+Tab from the sidebar to the blocks list
    the "insertion point" button appears and gets focused
    Shift Tab again: the second paragraph is skipped
    Not sure what the best option is, but I'd tend to think the last "insertion point" should always appear.

The issue here is that the insertion point is part of the last block (inside the writing flow). What I do know is skip to the end when we reach the last block. But if I don't do this logic, when you reach the last block, you'll go through all its inner tabbable elements before reaching the sidebar (movers, toolbar...)

@youknowriad
Copy link
Contributor Author

  • I updated the PR based on the WritingFlow component.
  • Moved the block label to the focusable element + role group
  • Hide all UI aside the border on navigation mode
  • Switch to edit mode as soon as you move the mouse

Let me know what you think about the current state, I'd like to stop enhancements at this level to avoid complexifying more.

@afercia
Copy link
Contributor

afercia commented Mar 22, 2018

The issue here is that the insertion point is part of the last block (inside the writing flow).

Ah i Understand. I also realize now the modes are "global", meaning once you switch to edit mode, all blocks are in edit mode. Which is fine, I guess.

Any thoughts about the second paragraph that gets skipped on Shift+Tab?

I understand the need to not introduce further complexity at this point, I'd defer to @jasmussen any decision.

@youknowriad
Copy link
Contributor Author

@afercia Actually, I was able to fix both issues with the last commit. Always skip the inserter in navigation mode and focus the last paragraph.

@afercia
Copy link
Contributor

afercia commented Mar 22, 2018

Ahh maybe I've catched one thing. Ideally, for keyboard users the default should always be "navigation mode. However, when using Shift+Tab, as soon as I press Shift it switches to Edit mode.

@youknowriad
Copy link
Contributor Author

Ahh maybe I've catched one thing. Ideally, for keyboard users the default should always be "navigation mode. However, when using Shift+Tab, as soon as I press Shift it switches to Edit mode.

Actually, it's not the case but since it's hard to start tabbing without moving the mouse first, you end up being in edit mode before maybe?

@afercia
Copy link
Contributor

afercia commented Mar 22, 2018

You're right, happens only in Safari. As soon as I press Shift, the block UI appears and I'm in edit mode. Can you reproduce?

@youknowriad
Copy link
Contributor Author

@afercia I can't seem to reproduce Safari Version 11.0.3

@youknowriad
Copy link
Contributor Author

@afercia Wait I do reproduce now. safari 😱

@youknowriad youknowriad force-pushed the try/navigation-edit-mode branch from e104018 to 0793684 Compare May 29, 2018 09:14
@youknowriad
Copy link
Contributor Author

I rebased this, let's try to get it to the finish line. Even if it doesn't benefit all the users for now, it's still an improvement as is.

a specific UI control, i.e. a button for each block to switch mode

I think we want to avoid a button per block as it's too cumbersome.

a "global" (at page level) mode switching, based on a keyboard shortcut

I'm leaning towards a global keyboard shortcut for now. What would be this shortcut? And do we know if the global shortcuts work on screenreaders?

@jasmussen
Copy link
Contributor

jasmussen commented May 29, 2018

In the spirit of looking at alternate approaches, here's a very silly question. I expect the answer to be "no, that doesn't make sense", but I'm going to pose the question regardless just in case it inspires something else.

What if you used page down and page up buttons to select blocks. 20 blocks on a page, press page down 20 times to get to the last one.

Everything else is unchanged, you can still tab or use arrow keys.

@youknowriad
Copy link
Contributor Author

Or maybe "Ctrl + arrow" instead of "page up/down"?

@afercia
Copy link
Contributor

afercia commented May 29, 2018

Even if it doesn't benefit all the users for now, it's still an improvement as is.

Hm, hold on please. If the click on the div is the only way to switch to edit mode, this results in the complete inability to edit a block for screen reader users on Windows.

@youknowriad
Copy link
Contributor Author

@afercia What's the way forward for you, we have several propositions here and it doesn't make sense to hold this more.

@afercia
Copy link
Contributor

afercia commented May 29, 2018

@youknowriad I've just tested it again on Windows (Firefox + NVDA) and it really creates a huge barrier for screen reader users. When in browse mode, pressing Enter on the div doesn't work.
Instead, a new block gets added, I guess because the keydown propagates:

unnamed

As discussed at length, this is expected with Windows screen readers in browse mode. It's standard behavior and there's nothing to "fix". It's also one of the reasons why jsx-a11y warns to not use events on non-interactive elements.

There are only two ways to make this work I can think of:

  • use a proper ARIA role on the div to make screen readers stop intercepting key strokes: unfortunately there are no suitable roles in this case
  • use a separate UI control that is natively interactive: a button

A few days ago we've also discussed a bit this issue with @mtias here's some point emerged:

  • this button could be the "breadcrumb label" that currently appears only on hover
  • alternatively, the switch could be "global", at a page level, i.e. via a global shortcut
  • any alternative way to implement the switch is welcome but we can't use the keydown on the div

@jasmussen
Copy link
Contributor

Let's try and unstick this.

Turns out Slack has a very cool version of this, that I think might work for us. It works like this:

  • When the canvas region has focus, up and down arrows navigate between chat "blocks"
  • When a chat block has focus, you can use tab to navigate through every item for that block, such as star, emoji react, author, more menu, etc.
  • You could also tab through everything, but that's a lot of tab stops

Here's a GIF:

slack keyboard nav

If you noticed, once you started tabbing, a neat little "tip" modal was invoked (cc: @karmatosed) that suggests more keyboard shortcuts:

slack

I like this approach because:

  • tab works like it would always do, it tabs through everything
  • arrow keys work like they do in editors, i.e. they navigate up and down the document, but they double as a block selector
  • because of the combination of tabs and arrowkeys, the arrow key navigation can be seen as "additive" on top of the stock tab behavior, and I would suggest it as an intuitive

I think Andrea's suggestion could make this work for us:

use a separate UI control that is natively interactive: a button
this button could be the "breadcrumb label" that currently appears only on hover

I think we can work with this, especially if #6773 lands first. Imagine if the following GIF showed you using up and down arrows, instead of me mousing over it:

key nav

Although it looks like the block is selected/hovered, in fact the breadcrumb button is focused. And when you press Enter or space or whatever you need to press to invoke that button, well then you're editing that block.

CC: @mtias

@afercia
Copy link
Contributor

afercia commented Jun 1, 2018

Hm... it's an interesting idea. Not sure it will work, as the arrow navigation would need a keydown event on the blocks wrapper div and keyboard events don't work on non-interactive elements with Windows screen readers in browse mode....

@jasmussen
Copy link
Contributor

Is there any way we can find that out?

@afercia
Copy link
Contributor

afercia commented Jun 1, 2018

Is there any way we can find that out?

Well it's basically the same thing that happens in this PR. There would the need of a keydown event on the block wrapper, then filter the key pressed to check for arrows, then fire some function. However, Windows screen readers in browse mode use arrows for their own navigation, they intercept these key presses and the browser would be unaware a keydown occurred.

@aardrian
Copy link

aardrian commented Jun 1, 2018

A word of caution — asking screen reader users to switch browse mode on and off is one of the issues that keeps screen reader users from Slack. In short, Slack's interface overall is inaccessible and should be used cautiously for pattern ideas. Related thread from March: https://twitter.com/LeonieWatson/status/974615133044359168

@afercia
Copy link
Contributor

afercia commented Jun 21, 2018

We've discussed this issue during WCEU contributor day with @aardrian and decided to try a new way:

  • use a visually hidden button with a click event to trigger the mode switch
  • the button could be named in a way to convey both the block type information and the associated action, e.g. "Block: Paragraph. Click to edit."
  • navigation mode should navigate through these visually hidden buttons, then some CSS should make the block look like "focused"

Not fully sure it is possible from a technical point of view, but it's something definitely worth trying as a native button with a click event would always work even when a screen reader is running.

@jasmussen
Copy link
Contributor

@afercia @aardrian Per the new way suggested, would we be able to accomplish the proposed direction suggested in #5709 (comment) ?

Let me know if you'd like me to explain that approach in more detail.

@afercia
Copy link
Contributor

afercia commented Jun 22, 2018

@jasmussen with Windows screen readers, the expected behavior is (in short):

  • arrows in browse mode navigate through all elements including not-focusable ones (text, etc.)
  • arrows in focus mode work inside input fields as they normally do
  • Tab always work as it normally does

So the expected behavior with the arrow keys in browse mode is to navigate through all the content. In this mode, key presses are intercepted by the screen reader and the browser is unaware a keyboard event occurs. That's to say arrows to navigate through blocks won't work because the keydown event used for that won't work.

For clarity, the Gutenberg Writing Flow arrows navigation works because the blocks have a role=textbox so they're perceived as textareas and screen readers switch to focus mode, they stop to intercept key presses and the keyboard events work again.

To my knowledge there are only to options:

  • use a button with a click event to switch mode: this would work always regardless of the screen reader mode
  • use "role=application" (see Try ARIA role application on the writing flow area. #5807) on the whole editor but that's something that should really be tested in depth and could potentially have a devastating impact

Overall, I think we should try to avoid "smart behaviors" of the application because they're hardly understandable by users. Instead, an UI control that must be intentionally activated by the user would be way more clear.

@aduth
Copy link
Member

aduth commented Sep 13, 2018

Is there still a relevancy / desire to continue the work here?

@aduth aduth added the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label Sep 13, 2018
@jasmussen
Copy link
Contributor

Is there still a relevancy / desire to continue the work here?

This is still blocked awaiting a response to mockups in #5694 (comment)

@tofumatt
Copy link
Member

Between arrow keys moving through blocks and #10545 giving us a keyboard-accessible (even with Firefox + NVDA) way to move throughout the post's blocks with an easy overview, I think the intent of this PR is covered. I think we should close it for now; please re-open if this is still something we want to look at, but there are issues with this approach that #10545 managed to bypass 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants