Added Skip to content button + other a11y fixes

[GBKS]

Looking to tackle various accessibility issues with keyboard navigation and voiceover.

• For the "Skip to content", see more info here and here.
• Fixed some issues where JS didn't properly handle aria properties to indicate expanded/collapsed menus (see aria-expanded).
• CSS fixes to use focus-visible so elements are properly highlighted when using keyboard navigation (info and rationale).
• CSS fixes for some hover states.

Keeping this a draft, as I will probably find more issues with testing. Would also appreciate if others could test on various devices and provide feedback.

🧶Check the preview🎩

[mouxdesign]

This is so nice to see! I found a whole checklist for web accessibility standards. It's something that also interests me. Am happy to pull out the main key points from these guidelines and put them into a list form and then look at how from a practical perspective these guidelines can be analyzed on the page. https://www.w3.org/TR/wcag-3.0/

[GBKS]

Let's also add support for prefers-contrast here.

[mouxdesign]

Completed a voice over text on the bitcoin.desig/guide page using NVDA. Here are the test results:
https://docs.google.com/document/d/1P9ofmOyztIfaSMm0dW5fpB6NlVnN1azUuHR99Tnb3Dg/edit?usp=sharing

[jason-me]

This is so nice to see! I found a whole checklist for web accessibility standards. It's something that also interests me. Am happy to pull out the main key points from these guidelines and put them into a list form and then look at how from a practical perspective these guidelines can be analyzed on the page. https://www.w3.org/TR/wcag-3.0/

WCAG 3.0 is an interesting spin and I would definitely keep it in mind, but in the meantime would recommend WCAG 2.1 AA (Which are the current guidelines) or even WCAG 2.2 which should be finalized soon.

Here is an explainer: https://uxdesign.cc/wcag-3-0-what-you-need-to-know-about-the-future-of-accessibility-standards-2e1f6374f2c7

[jason-me]

Looking to tackle various accessibility issues with keyboard navigation and voiceover.

• For the "Skip to content", see more info here and here.
• Fixed some issues where JS didn't properly handle aria properties to indicate expanded/collapsed menus (see aria-expanded).
• CSS fixes to use focus-visible so elements are properly highlighted when using keyboard navigation (info and rationale).
• CSS fixes for some hover states.

Keeping this a draft, as I will probably find more issues with testing. Would also appreciate if others could test on various devices and provide feedback.

yarnCheck the previewtophat

Nice job on the skip link, aria properties, and focus-visible. One thing I would also recommend is making the hidden skip link visible on focus for keyboard-only users so they can also see it when they are tabbing through the page as recommended in your first link from Web AIM.

For the expand/collapse controls it may also be helpful to consider using the accessible design pattern for accordions from WAI-ARIA Authoring Practices 1.2

[GBKS]

@jason-me thanks for the feedback. I just tweaked the "Skip to content" button, it now smoothly slides in from the top when focused.

The expand/collapse interaction is for the mobile navigation, which covers the full screen when expanded. I've been looking at the "menu button" guidelines for this, that's appropriate, right? With the last commit, I added aria-haspopup and keyboard up/down/escape logic to this.

I removed draft status from this PR now. It's ready for more thorough review and input, as I feel like I am not really able to push this much further at the moment without more feedback.

[jason-me]

@GBKS the "Skip to content" button looks great and is now exhibiting the expected behavior.

For the expand/collapse interactions on mobile you could certainly use a menu button, but then you would also need to add a role="menu" to the container for the list of links and add role="menuitem" to each link.

The current implementation is closer to a dicslosure-navigation hybrid which is a bit simpler but probably a better pattern to go with: https://w3c.github.io/aria-practices/examples/disclosure/disclosure-navigation-hybrid.html

In this case, I would just add an aria-current="page" to the currently selected link so that screen reader users know which page is currently selected. Great work so far!

I will try to provide more thorough review soon to address other low hanging fruit, but this is moving in the right direction.

[GBKS]

I was wondering whether role="menu" and role="menuitem" are necessary since the menu already uses the nav tag already?

I just added the aria-current="page" indicators.

[sbddesign]

• Verified the Skip to Content link works when using a screenreader
• Verified I can toggle menus open and closed with keyboard while navigating with a screen reader
• Verified I can tab between links and clickable elements

I am basically just testing the features that you have added in this PR. Is there anything else I should be looking for?

We might want to go page-by-page and check some things with the WAVE tool. That could inform future issues and PRs. For example, I opened #831 because of a WAVE test.

[jason-me]

@sbddesign WAVE is cool, but you should also check out out ARC Toolkit and AXE when you have a chance.

[GBKS]

Thanks for the review. Going to merge this one for now, and we can tackle additional accessibility tweaks in future PRs. With accessibility, I find it difficult to be 100% sure that everything is covered as I don't have the expertise/experience. Step-by-step iteration is the way to go, IMHO.