why did you change the Hint trigger to an link with empty href? # is not a valid value for href. When developers use # it usually indicates that they should be using a button element (buttons do something and links go somewhere.) If you just need an element to put a JS listener on, button is the right choice.
Also, focus is not being properly managed in this new design. In the previous design, pressing the Hints button revealed the sibling container so that the tab order remained logical (focus remained on the button, subsequent TAB or arrow keypresses progressed through the Hints). In this design, the container is no longer a sibling, which breaks the logical tab order. You will have to manually manage focus so that it remains logical.
We are going to revert this PR. Let's put it through a formal accessibility review after the work above has been completed.
I don't remember the exact reason now, I should've perhaps documented it in the code. Anyway, it was closer to what was already in the fixture file, and it worked fine so it made sense to do so.
I'll give it a try with a button and let you know.
As for the tab access, I was only aware of making the hint button/link accessible through a tab, and made sure it it.
The solution that comes to my mind is to add tabindex to the elements manually in a way that reflects their logical order.
However, I'm not sure which number should I start with? Of course, it can't be 1 since this is a global attribute and will be the first element in the page that gets focus, right?
, thanks for pointing that out. The fixture is out of date. This code was updated to improve accessibility and the update did not make it into the fixture. It looks like that work was done with the work on Annotations:
I have created a ticket to update the fixture:
Regarding your work:
It has to be a button rather than a link with href="#". It will work just fine.
Creating a logical TAB order is critical for keyboard and screen reader users. When they invoke a control that exposes a dialog box, like this help region, they should expect that focus is at the top of this region so that their next keystrokes will interact with this region, and not some other region on the screen. The current design places the exposed region directly after the button in the DOM so that no special focus management is necessary. Keyboard interactions will progress as expected, through the new region, top to bottom. If you move the location of the region in the DOM so that it is not an immediate sibling or ancestor of the control (button) then you must manually move focus. Additionally, you must move focus BACK to the control that opened it when the region is closed. This is a lot of work, which is why we liked the original design.
Let me know if you have any questions. I'm not entirely aware of the problem you are trying to solve, but if it can be solved by keeping these elements where they are in the DOM, then that would be the best approach.