WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Combobox sufficiently accessibility-supported?

for

From: Bryan Garaventa
Date: Oct 12, 2015 9:39AM

Thanks, that helps a lot actually :)
Luckily most of the things you mentioned are styling and content based, and not related to the functionality of the Combobox widget.

For example, the font sizing, plus content widths relative to small screen devices, which are also relative to portrait to landscape device modes, will add complications for any UI. There are options that may help with styling this type of layout better for small devices, such as using CSS Media Queries
https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#orientation

In this case too, I've added a lot of content within the dropdown, which isn't really typical for most auto suggests, thus accounting for the wider than usual horizontal display. I'll experiment with the media queries and see if it's possible to conditionally display this better and look into cutting down the extra verbiage within the listbox options as well.

> * Odd behavior of suggestions - typing "Ch" offers "Butcher" not "Chalker" as first list item voiced

This gets more into the functionality of the Combobox widget. The widget supports three modes, first letter matching, substring matching, and whole word matching. In this case, substring matching is set so that the letter combinations that are typed will match any substring within the Option nodes. This is configurable though. Also, the widget distinguishes between 'editable' and 'readonly' Comboboxes as well.

You can see the more traditional use of editable and readonly Combobox dropdowns here, where State is editable and Country is readonly.
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm
(This has first letter matching enabled.)

And here is an example of whole word matching:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Word%20Match)/demo.htm
(Which matches any combination of these words within each Option)

And here is an example of a readonly simulated Combobox:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm
(Which matches the first letter typed for each Option)

All of these use the same Combobox widget, which converts a standard HTML select element into the associated dropdown including requisite ARIA attributes, even though all of the content, modality types, and styling are variable.

> * After selecting an option that is placed into the input, I seem to lose VO focus, I.e. I think it is no longer on the input so that the next focus point would be submit. The focus is instead on your text instruction at the physical position where the list box focus was before selecting the item

This is a difference with touch devices, where focus doesn't necessarily match programmatic focus. The Combobox widget for example always sets programmatic focus back to the input or focusable triggering element in the case of a readonly simulated Combobox, but when you interact with the screen via touch, focus is always where you touch irrespective of where programmatic focus was initially set.

> * Deleting content in the select makes the page immediately scroll to the list box top so the input where deletion takes place is no longer visible

This likely goes back to the CSS styling issue where the content and sizing are too large for a small screen like this, because the widget uses optionNode.scrollIntoView() when a new suggested item is displayed in order to account for default options that are set within the HTML select element, such as when 'United States' is selected by default within the readonly simulated Combobox. This will cause the default selection to automatically scroll into view when the listbox is rendered. The same thing happens when typing a letter like 'p' in such cases to automatically scroll the option that starts with that letter into view. So if the screen is too small, and the content is too wide, it scrolls the item into view and moves other things like the input offscreen.

This will likely be fixed when I get the UI to change on smaller device sizes using the CSS Media Query or something equivalent for styling. Being blind sucks for stuff like this since I can't verify what I'm doing visually, so it may take me a bit to work out the calculations.