Toolbar Example: Bugs with keyboard support, aria-disabled, and aria-label

[mcking65]

As noted in issue #539, the toolbar example has the following bugs:

• Missing aria-label="Example Toolbar" on div with role="toolbar"`
• Missing aria-disabled="true" and appropriate greyed out styling on one of the button elements (add to second button element in toolbar). As documented in accessibility features section, the disabled button should remain focusable.
• Home key does not move focus to first element.
• End key does not move focus to last element.
• Right Arrow key does not wrap focus from last to first element.
• Left Arrow key does not wrap focus from first to last element.
• Elements in toolbar do not implement their respective patterns, e.g., enter and space do not activate buttons. Each element should execute an action, e.g., buttons and links open alert dialog. This let's users know the element was activated and prevents default action, e.g., scrolling with space.

[mcking65]

@tatermelon is planning to submit a PR for this issue.

[jongund]

I am planning on submitting a pull request on an updated toolbar example later this week. See the following link:
https://rawgit.com/jongund/aria-practices/toolbar/examples/toolbar/toolbar.html

Mostly need to clean up some CSS best practices and focus styling issues with my student.

[mcking65]

@jongund, the WIP you have looks like a more realistic toolbar. I didn't know you were working on that. With a few changes, it could resolve issue #541. That is something we should discuss. In fact, that would be a good way to frame the PR.

For project management reasons, I don't want this issue closed until we have the resolution committed. So, I am re-opening it.

The contract with Bocoup referenced the current toolbar; this one is significantly more complex. The tests for the current toolbar are merged into the Bocoup branch, The tests that fail due to the bugs in the current example are commented out. This example would drive rework on that set of tests, which @spectranaut may not be able to contain.

Timing will also be a factor. I see quite a few issues that need resolution and possibly discussion in this new example. So, I am not completely confident it can be done before the Bocoup contract ends. The current target completion date for test development is sep 24.

If you are confident you will have the resources to complete this toolbar along with necessary test revisions (if needed) before December as well as the other stuff we already have in the release 3 plan, I'm OK with adopting issue #541 as the resolution plan for this issue. I'll take it off @tatermelon's plate for now, and we can discuss the plan in the september 10 meeting.

Some challenges I see in the current implementation of the new toolbar are ...

It has toggle buttons that do not follow the toggle button pattern; once pressed, they cannot be unpressed. This is because they are toggles pretending to be radios. I am not sure how to best resolve that. This is a fairly common type of design, and one that is not easily resolved without tweaking existing ARIA patterns.

I do not think we want toggles that cannot be toggled. Yes, you could add aria-disabled="true" to the button after pressed, but I feel like that is a potentially confusing paradigm. The user will here "Aligned left button pressed disabled". will the typical user really understand that pressed means that the text is aligned left? Or, will they wonder if it is not aligned because they hear "disabled"? Will they wonder how to enable the option? The more ways of expressing the exact same concept, the radio concept, the more confused users can get. It is better to minimize the number of ways of expressing the same semantic whenever possible.

The only real barrier to using the existing radio group pattern in a toolbar is that the checked state cannot follow focus like in normal radio groups because the arrow keys are needed to navigate to other elements in the toolbar. That means requiring the user to press space to check the radio. Maybe that is OK. I'd recommend implementing that approach and bringing it to the group for review.

I noticed that the toolbar label is "toolbar" ... It should probably be "Text format". Remember, never use the role name in the label.

The buttons and button groups are not labeled.

The font menu button says it is a font menu before a font is chosen, but does not say that it is the font menu after a font is chosen; it does tell the name of the current font, but the label should be something like "Font FONT_NAME". Even on page load, the label should probably reflect the current font.

I'm putting this feedback here for now in response to your most recent comment. For follow-on discussion of work on an enhanced toolbar, however, we should do it in a new PR or a different issue. Issue #541 would be more appropriate since that is the issue that calls for enhancements to make the existing toolbar more illustrative and realistic.

[mcking65]

With commit 599d2de from pr #887, the issue541-toolbar-redesign feature branch now contains all changes needed to resolve this issue. Further review will be managed in issue #539.