Review examples of listboxes with rearrangeable options

[mcking65]

The Examples of listboxes with rearrangeable options are ready for review.

Task Force Member Reviews Requested as of Nov 21, 2017

• Review by Ann (@annabbott)
• Review by Siri (@shirsha)
• Review by James (@jnurthen)

[annabbott]

No issues noted.

[shirsha]

1. Can you keep the buttons in middle of the unimportant and important features, in that way it is easy for the users to view from left to right instead of top to bottom.

2. User can access buttons only by tabbing to first button (Up) and then have to arrow to access the next buttons (down and unimportant).

3. I see element in the code and also tabindex is added it.

In IE:
I am not able to move the selected list item to unimportant features list via keyboard or mouse.

[mcking65]

@shirsha commented:

1. Can you keep the buttons in middle of the unimportant and important features, in that way it is easy for the users to view from left to right instead of top to bottom.

Siri, I don't understand what you mean. I thought the buttons are already between the two lists. They appear layed out that way when I look with the JAWS cursor.

2. User can access buttons only by tabbing to first button (Up) and then have to arrow to access the next buttons (down and unimportant).

Correct, this is by design; it is a toolbar.

3. I see element in the code and also tabindex is added it.

Please clarify; I do not understand.

[bwoolnough]

I tested the examples with the Axe accessibility extension and it seems that listboxes are required to have at least one option. This means the examples fail the WCAG 2.0 criteria (1.3.1 - Info and Relationships).

[malcalevak]

I wanted to suggest the addition of two things (technically, across the board, but I'll start with this one):

• If a pattern is providing an alternative means of doing something a native element already does (e.g. a listbox frequently mimics a select box), I think it would be incredibly beneficial if we included:
  -- What that native element is
  -- A non-comprehensive list of some of the reasons for using the patterns vs using the native elements
• Other common ways of implementing a pattern (e.g. in the case of things like this listbox, not using aria-activedescendant, etc)
• A list of known issues with the pattern
  -- Browser issues
  -- Screen reader issues
  -- Browser/screen reader combination issues
  -- Versions of the above that recreate the issue
  -- Versions of the above that resolve the issue (once one is found)
  -- List of issue tickets relating to these issues, for people to track progress, etc

In line with the last of those, I wanted to share the following, which I believe is actually a bug with WebKit or Safari (I'm going to look for/file a ticket with them later):

The Multi-Select Listbox example doesn't work in Safari 13.0.3 (15608.3.10.4) w/ VoiceOver 10.

There are no issues when nothing is selected, but once you've selected something, when you attempt to navigate to other items you'll get some unusual messages, like "Privacy cloque added to selection 2 items selected" when only "Front sun roof" has been selected. Attempting to continue navigating through the options seems to only read "selection replaced 2 items selected", though if you return to an option that's actually been selected, it will then read along the lines of "Privacy cloque removed from selection 1 item selected"

As best I can gather, it seems to be counting the "focused" item as selected, but not reading it out or setting it selected (that last part is expected). If you remove the selection, it goes back to normal.

There's a similar issue with the single select, when not implementing "selection follows focus", but I'll save that for its ticket, or the one I file with WebKit.

[JAWS-test]

I tested the examples with the Axe accessibility extension and it seems that listboxes are required to have at least one option. This means the examples fail the WCAG 2.0 criteria (1.3.1 - Info and Relationships).

I don't know why this is a violation of SC 1.3.1, but it is a violation of the ARIA specification. The question is whether the specification or the example should be adapted here, i.e. the question is whether empty selection lists are allowed. In HTML they are allowed, <select></select> is valid HTML code (content of select: "Zero or more option, optgroup, and script-supporting elements."). Shouldn't it be possible to create an empty list with ARIA? If yes, the ARIA specification must be adapted...