Re: Mapping of HTML select

On 2016-05-09 6:01 PM, Matt King wrote:
> This statement is confusing to me ...
>> >It is mapped as a combobox or popup menu because that's what it is.
> [where "It" is referring to a select with size 1]

Here's another attempt:   It is mapped as a combobox or popup menu
because that's what the browser is creating and putting up on the screen
for the user to interact with.

> The desktop GUI APIs have listbox type objects. Why not use those instead
> since, from an interaction model perspective,  they better represent what is
> actually present on the screen? Those objects are used when size is 2 or
> multiselect is true.

What is on screen depends on the size attribute.  When it's two or
greater, then there is a listbox on screen.  When the size is one then
there is a combobox or popup menu on screen, including the standard
trigger that the users click to popup the set of choices.  Here's a
rationale.  When only one of the choices is displayed on screen, the
popup interface allows users to see all of the choices at once, and to
select the one they want.

> A select with size 1 doesn't have a textbox. Both ARIA 1.0 and 1.1 require a
> textbox to be part of a combobox; it is a required owned element.

Yes, there is problem here in that the kind of desktop combobox used
either doesn't have a textbox, or it has a readonly one.  Historically,
when comboboxes were introduced, they came in two flavours: editable and
non-editable.  In the non-editable case, the text box component of the
combobox is inert.  It is used only to display the current choice of the
combobox.  The user can not type in the textbox like they can with a
fully editable textbox.  In order to change its contents, users pop open
the listbox and select another option, or arrow through the choices. 
Another data point:  I looked into the details of the GTK combobox, and
it provides a configuration where there is no textbox at all.  I'm
fairly certain this is the kind of combobox that is used by FF on GNOME
for this specific <select> case (although I didn't actually look at FF's
source code).  Perhaps ARIA needs to support this case.

Aside:  I cannot find any way in FF to popup the listbox using the
keyboard.  This is different from desktop comboboxes, but it may be
confined to FF.  With Safari and its use of a menu button, it is
possible to open the menu using the space bar.

> And again, it is confusing to change the mapping based on the size attribute
> when the size attribute doesn't seem to effect anything but presentation and
> the interaction model remains the same.

But, the interaction model is not the same.  In one case, there is a
scrollable listbox on screen, whereas, in the other, there is a popup
widget on screen.

>  Similarly, changing the role based
> on single vs multi select is confusing.
> Unless there is something I am completely misunderstanding here, this
> discrepancy between what core ARIA requires for the combobox and listbox
> roles and what browsers are doing with native HTML seems like areally good
> reason to recommend authors never use select with size 1 but instead make
> their own single-select listboxes using ARIA. Then, screen reader users can
> get a more consistent experience. This is troubling too because it flies in
> the face of our most fundamental authoring guidance to always prefer native
> elements.


'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                 - C. Carter -

Received on Thursday, 26 May 2016 14:13:48 UTC