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.




-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Detlev Fischer
Sent: Sunday, October 11, 2015 10:43 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Combobox sufficiently accessibility-supported?

Thanks to both of you, Patrick and Brian, to pick up this the question and have this instructive discussion.

Brian, I have just opened your example on an iPhone (Safari), turned on VoiceOver, and tried using the Combobox. There are several issues that make it hard to use at least with iOS/ VO on a small screen:
*Default font small, making bigger via browser zoom cuts off content & requires horizontal panning
* Position and width of postbox not adapted to screen width (the native "fruit machine" widget would certainly be easier to use) *Suggestions come unexpected (both visually and as VO output), they cause a jump in scroll status, making me lose the visual context of the input field
* Odd behavior of suggestions - typing "Ch" offers "Butcher" not "Chalker" as first list item voiced
* 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
* 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 Note this is just a quick check by a sighted user who is not a VO expert.
Best, Detlev

Sent from phone

Am 12.10.2015 um 03:13 schrieb Bryan Garaventa < <EMAIL REMOVED> >:

>> I don't think there's any particular need for consensus - all the
>> various ATs don't have to use the same touchscreen gestures (and
>> indeed, they don't for many things), but what they do need is an underlying implementation of the concept of activedescendant, and some means for a user to interact with a widget that uses it. Whether it be an up/down swipe, or a two- or three-finger swipe, or a more complex gesture is really up to each AT to decide.
>
> I agree, and this would be nice if supported. A lot of these issues are coming up as we continue working on the ARIA APG 1.1 update, and touch devices are sort of a hot topic for this across various interactive widgets.
>
> Going back to the original question though:
>
>> Hi list,
>> I did a bit of due diligence searching but the last Webaim entry mentioning the combobox is more than a year old.
>> Would you still consider it best practice to avoid the combobox if favour of native selects?
>
> With this in mind, can you identify any accessibility issues with the demo implementation that I referenced?
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Combob
> oxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.h
> tm
>
> I really would like to know what these are, so I can improve this in the future.
>
> Thanks,
> Bryan
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Patrick H. Lauke
> Sent: Friday, October 09, 2015 6:12 PM
> To: <EMAIL REMOVED>
> Subject: Re: [WebAIM] Combobox sufficiently accessibility-supported?
>
> On 10/10/2015 00:52, Bryan Garaventa wrote:
>>> It is conceivable that this could be made to work though, with the
>>> focus nominally remaining on the combobox' input, but
>>> VoiceOver/TalkBack allowing the user to swipe up/down (same as cursor up/down) to cycle through the results/suggestions, while swiping left/right would take the user to previous/next item in the sequential focus order.
>>
>> That is true, and would be helpful if implemented. It doesn't say anything about this in the spec though, so achieving consensus on how it should work is debatable.
>
> I don't believe the spec authoritively defines any user agent behavior http://www.w3.org/TR/wai-aria/ - and while we do have the best practices http://www.w3.org/TR/wai-aria-practices/ these are aimed at web content developers, and are not meant as a guide for user agent developers.
>
> I don't think there's any particular need for consensus - all the various ATs don't have to use the same touchscreen gestures (and indeed, they don't for many things), but what they do need is an underlying implementation of the concept of activedescendant, and some means for a user to interact with a widget that uses it. Whether it be an up/down swipe, or a two- or three-finger swipe, or a more complex gesture is really up to each AT to decide.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
>