Review ARIA 1.1 Combobox with Listbox Popup Examples

[mcking65]

The ARIA 1.1 Combobox with Listbox Popup Examples page
is ready for task force review.

Known Issue

NOTE: There is one open issue that will be fixed during the week of October 30.

Currently, in examples 1 and 2, if an option is selected in the listbox, tabbing or clicking out does not set the value of the textbox to the selected option as expected. This is issue #495.

Reviews Requested as of October 25, 2017

• Review by Ann (@annabbott)
• Review by Bryan (@accdc)
• Review by Jemma (@a11ydoer)
• Review by James (@jnurthen)

[annabbott]

ARIA 1.1 Combobox with Listbox Popup Examples > second paragraph > second sentence:
"the list becomes available..."
Typo: capitalize the first letter of the first word of that sentence.

[annabbott]

Role, Property, State, and Tabindex Attributes > Textbox:
Visual formatting of table is different than for Combobox Container and Listbox Popup.

[annabbott]

Role, Property, State, and Tabindex Attributes > Textbox:
Combobox role is missing.
The following are also missing:
aria-expanded="false"
aria-owns="ex2-listbox"
aria-haspopup="listbox"

This needs to be further checked by a code warrior!

[accdc]

Hi Ann, the reason for this is because there is really no relation between the 1.0 and 1.1 design patterns, since the roles and supporting attributes go in different places depending on which one is being implemented. Unfortunately this will likely cause a lot of confusion in the future as people try and mix and match both incorrectly.

Matt, this looks like it fits the design pattern the way we have it documented in the spec, though testing it is somewhat tricky since it doesn't actually work accessibly using screen readers reliably as yet. E.G you need to disable the virtual cursor in JAWS to be able to set focus to the edit field in order to type anything into it. However as a prototype to point screen reader venders to, this does indeed appear to be programmed correctly as documented in the 1.1 spec.

[mcking65]

@accdc, thank you for the review.

what version of JAWS are you using? For me, with the shipping version of 18 (18.0.4321) it works almost identically to a 1.0 combo style. It is definitely a bit better than the prior version of 18 where it didn't even recognize the combo. Using FF 56 with JAWS.

However, in Chrome 62, it seems that aria-activedescendant is not working at all with either JAWS or NVDA, so that is probably a Chrome bug.

With NVDA, these only work in focus mode in Firefox. In document reading mode, only the combobox label is visible; the combobox itself does not exist.

We have a ways to go to get screen readers to exploit the advantages of the new structure so that users can see both the textbox and the popup as well as correctly read the popups.

[mcking65]

annabbott commented:

Role, Property, State, and Tabindex Attributes > Textbox:
Visual formatting of table is different than for Combobox Container and Listbox Popup.

I don't understand why. I have the same classes on both tables and don't see any other classes that could mess it up.

@jnurthen, can you help with this??

[mcking65]

@annabbott commented:

Role, Property, State, and Tabindex Attributes > Textbox:
Combobox role is missing.
The following are also missing:
aria-expanded="false"
aria-owns="ex2-listbox"
aria-haspopup="listbox"

Ann, as Bryan pointed out, these are differences between 1.0 and 1.1 form of the design pattern. I am thinking of adding a subsection to the design pattern that summarizes the differences between the two structures more clearly. Then, we would add a link to there. Not sure I see that getting done right now though.

[sh0ji]

This might make sense as a separate issue since it might pop up for other patterns, but I noticed it while reviewing this: the label elements need a for reference for their inputs.

I see that they're using aria-describedby since the labels are labelling more than just the inputs, but the aria-describedby pattern is not functionally equivalent to the native label[for] or nesting pattern on form elements. Those two patterns allow mouse users to click the label to focus the input, but aria-describedby alone does not.

[jnurthen]

Using label for would make sense here IMO as the input is indeed the element which actually takes browser focus. I don't see why it would do any harm in this example.

[a11ydoer]

Spec and examples look good to me.

[mcking65]

Thank you all for the great feedback! I am going to tie a bow on this one now.