Nav block accessibility improvements

[getdave]

There has been a lot of work put into making the Navigation block (and its principle child blocks) as accessible as possible.

That said, we can always do better.

Nav block specific

Here are a list of current known Issues with the block (based on this filter). We will augment this list as necessary as we move towards WP 6.0.

• Focus is lost after selecting option from "Select Menu" dropdown #38169
• Navigation block should be identifiable with aria-label #24369
• useNoRecursiveRenders can cause all of its children to be unmounted from the DOM #39044
• Navigation block not focused on setup #39301

Wider editor issues

These fixes are not specific to the Nav block but if resolved will contribute back to the a11y of the block.

• Navigation menu block: blue selection border is inconsistent with other blocks #20808
• Fix useFocusFirstElement in non-contenteditable Blocks #37934

[getdave]

cc'ing @tellthemachines who I know has been instrumental in leading the work on a11y around the block. Isabelle are there any other outstanding issues you are aware of that should be addressed here?

Also could we conduct some basic testing to try and discover for ourselves where the current problems lie before reaching out to the Core Accessibility team for further guidance?

[alexstine]

@getdave I like where the thought is but this needs to be a bigger picture type of situation. The Navigation Block isn't the problem, there are other issues effecting other Blocks like the Navigation Block. The PR here goes in to trying to fix that.

#37934

Really need to fix these issues and then the Navigation Block and other related Blocks may not need as much work as we think.

Please, always involve the Accessibility team. While my blindness prevents me from really planning from the beginning, we have other members who can help from the start.

Thanks.

[getdave]

@getdave I like where the thought is but this needs to be a bigger picture type of situation.
The Navigation Block isn't the problem, there are other issues effecting other Blocks like the Navigation Block.

@alexstine Understood, although I trust you will forgive me for focusing on the Navigation block specifically as it's where my particular focus lies. I want to ensure we're tracking both wider and more localised issues. Moreover, having a specific tracking Issue for the block helps to ensure that a11y continues to be kept front of mind as we move forward - something I'm sure you would support.

I absolutely appreciate that we need to tackle wider problems so it's good to have the context you've provided as to which ones specifically can make the biggest impact not only to the Nav block but to all blocks 👍

I've amended the Issue above to include x2 sections to better capture the approach which we've discussed here.

Please, always involve the Accessibility team.

Absolutely agree 👍. Allow me to provide some context here.

Having read the notes from a previous Core Accessibility chat I understood the team are low on resources. Therefore I felt it would be helpful if I did some of the ground work in advance instead of simply turning up out of the blue and asking for assistance.

I'd be super happy (and grateful) to involve members of the Accessibility team in planning how best we can allocate our time to improve the Nav block and the editor more broadly. Indeed, I was intending to raise this question in the Core Accessibility chat on Friday.

Appreciate your input here and I will look out for the agenda for the upcoming chat. Many thanks.

[alexstine]

@getdave

I absolutely appreciate that we need to tackle wider problems so it's good to have the context you've provided as to which ones specifically can make the biggest impact not only to the Nav block but to all blocks

Yeah, that's why I posted how I did. I don't want a Block by Block approach for a few reasons.

1. That is a whole lot of code to maintain.
2. The Block Editor needs to be accessible for any type of Block that a developer adds, not just our Core Blocks. The least we can do is make sure the Block Editor has the support for basic focus management.
3. Once the big issues are fixed, then we can look Block by Block to fix any issues that might actually be specifically related to a Block or a component used within a Block. E.g. see this PR.
   Ensure placeholder description is read by VoiceOver #38366

Having read the notes from a previous Core Accessibility chat I understood the team are low on resources. Therefore I felt it would be helpful if I did some of the ground work in advance instead of simply turning up out of the blue and asking for assistance.

Oh yes, you are not incorrect by any means. We are low on resources but feel free to always chase us down over Slack. I'd rather you bug me early than wait for the planning to be done only to end up with maybe not a perfect solution. I don't expect anyone to know accessibility like I do just as I do not know design these days.

Thanks for starting the discussion though, it is much appreciated. Together, I am hoping we can make Gutenberg more accessible to all.

[tellthemachines]

Just noting that #20808 is not nav-specific, as explained in this comment.

[tellthemachines]

I just found #39301 which is also Navigation-specific. (Might be caused by the spinner?)

[talldan]

I've added #39044 to the list, as that's another cause of focus loss.