Improve accessibility semantics for Toolbar buttons with trays

Adding this to the parent plan for improving toolbar accessibility. This improvement was already listed there, but it didn't have it's own issue until now. Thanks for filing this @bnjmnm.

There's another benefit to using aria-expanded: we can ditch one of the Drupal.announce() calls, because it's conveyed programmatically in the a11y tree for the button itself. There is widespread support for this in browsers and AT.

This would be a good one to work on at the Drupal Accessibility Bug Bash duing DrupalCon Global 2020.

Oddly, this issue does not show up when I search for "aria-expanded". Maybe that is because it appears inside a code tag.

If so, then it should show up now in the search.

Update: another theory is that "aria-expanded" gets tokenized as two words. I can find this issue by searching for "aria expanded".

When Javascript is disabled and those items behave as links, they still have role="button" and (currently) aria-pressed="false".

In this case, they may be wrongly announced to AT as buttons instead of as links. Attached a screencast of this in VoiceOver.

Based on a Slack discussion with @cwilcox808, I suggest:

1. Rendering these items as plain links without any HTML button properties (aria-role, aria-expanded, aria-controls, etc).
2. Adding those button properties in Javascript as part of the progressive-enhancement.
3. Adding CSS based on aria-role="button" that will style these as buttons instead of links when the progressive-enhancement has happened (both for full-color and forced-colors cases).

@cwilcox808 said this about the full-color styling and aria-controls:

I think that's a good idea independent of the forced-colors state, something like:

.toolbar a[role="button"] {
  text-decoration: none;
}

Instead of .toolbar .toolbar-item including text-decoration: none.

That does open up the use of adding the underline on :hover and :focus. I really like strongly associating underlines with links (behaving as links) so I'd like to see something else used when they have [role="button"]. Without JS, the line thickness could be changed, e.g.

.toolbar a[href]:not([role="button"]):is(:focus, :hover) {
  text-decoration-thickness: 0.1875em;
}

Note that only a single assistive technology, JAWS, makes use of aria-controls so it's not very useful. The better practice is to instead have the associated element immediately follow the control so users don't have to navigate through other content from the control.

@cwilcox808 said this RE forced-colors styling for the "pressed" state of the buttons:

For aria-pressed="true", you could maybe set border-color: Highlight;, buttons in that state wouldn't have a visual change on hover but focused buttons would still have the addition of the outline.

Removed Global2020 because it's outdated.

Added SC 4.1.2 because this issue is related to the role and state of UI components and the notification of changes to assistive technologies.

Added progressive enhancement for all "faux button" properties to the Proposed resolution and changed to Bug report because it's a failure of SC 4.1.2 when javascript is disabled.

Added forced-colors CSS to Proposed resolution because it's probably just a color change, but left out the suggestion of changing the full-color styling to present as buttons because that's a bigger design change and should apply to all buttons in the toolbar. #3097905: Add visual indicator to show which toolbar buttons have trays associated with them is probably a good place to address that because it already requires related design.

Forgot to add SC 4.1.2.

Also adding Needs change record because of the UI / UX changes.

Based on @cwilcox808's comments and another related Slack discussion, I'm moving aria-controls to a separate issue.

I'm moving the suggestion for forced-colors proper button coloring to another issue because it's pretty involved after all.

Actually, needs better STR.

Added STR

For the UI changes can we get before/after screenshots added to the IS please, helps the review. Also possible to get one of the accessibility maintainers to sign off on it.