Problem/Motivation
The MediaLibraryWidget has a "show/hide media item weights" button at the start of the fieldset. This is a special case of a multi-value field widget, which normally use tabledrag.
The numeric weights method was retained as an accessibility fallback for users who don't use a pointer device - primarily screen reader users, and speech control users. And currently in D8, sighted keyboard users need the numeric weights too, due to #2725259: [regression] Table Drag handles no longer respond to up/down arrow keys.
With tabledrag the show/hide weights button comes before the draggable rows, both visually and in the keyboard tabbing order. A keyboard user who wants to reorder items can swap to the weights method as soon as they arrive at the table.
In the MediaLibrary widget, we have a different draggable items implementation, but it also offers a numeric weights method. However the tabbing order in this fieldset is visually confusing:
- The set of media items. Visually, focus appears to have bypassed the show weights button. Then it follows a zig-zag path through the media items...
- The media item title
- The remove button (up, above the title)
- The weight field, if shown (down, below the title).
- The show/hide weights button. Visually, this is a jump UP to the top of the fieldset, before the media items. This is an unexpected direction.
- The add media button. Here the focus jumps back down below the media items.
This is a WCAG level-A issue, see Focus Order: Understanding SC 2.4.3. The visual tabbing order should match the visual reading order.
As well as being visually confusing for sighted keyboard users, it also creates extra effort for all keyboard users. In order to use the numeric weights, the user first has to tab past all of the current media items, to reach the show-weights button, then tab backwards to the items they want to move, then forward again to the form submit button. Compared to tabledrag, this can easily involve twice the effort (in keypresses) and probably extra cognitive load too.
While working on this issue, seanb discovered the "remove" buttons all had identical accessible names. They have different outcomes though; so they need to say which item they remove. See comment #5.
Proposed resolution
Make the tabbing order match the visual reading order:
- Move the show/hide weights button, so it comes before the
.media-library-selection
container element in the DOM order. We can reduce the confusion and keypress effort, while making it more consistent with the existing tabledrag. - In each media item card, swap the DOM order of the rendered entity and the remove button, so the button is first in the tabbing order, and the visual focus order matches the reading order inside each card.
- Disambiguate the "remove" buttons, so they are clear for screen reader users about which media item they remove.
The desired tabbing order, upon reaching the MediaLibraryWidget fieldset, is:
- The show/hide weights button
- The set of media items already selected
- The remove button
- The media item title
- The weight field, if shown
- The add media button
Remaining tasks
- DONE. Update the form order in MediaLibraryWidget::formElement().
- Done. Added aria label to the remove button.
- Done. CSS fixes so the remove buttons don't jump on hover/focus.
User interface changes
- Fixes the tabbing position of the show/hide weights button, so it matches the visual reading order, making it more predictable for sighted keyboard users.
- Greatly reduces the effort required by a keyboard user, when they actually make use of the numeric weights to re-order media items.
- Disambiguates the accessible name of the "remove" buttons. This is invisible, screen reader users benefit from it.
- No visual design changes.