RE: Mapping of HTML select

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]

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.

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.

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. 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

Matt King

-----Original Message-----
From: Joseph Scheuhammer [] 
Sent: Monday, May 2, 2016 11:14 AM
To: Matt King <>; ARIA Working Group
Subject: Re: Mapping of HTML select

Hi Matt,

On 2016-04-30 3:49 PM, Matt King wrote:
> Does anyone know the rationale behind mapping the HTML select element 
> differently based on its visual presentation?

HTML controls are native controls.  The browsers use the OS GUI toolkit here
and the controls are native desktop widgets in these cases.  They are Cocoa
widgets on OS X; on GNOME, they are GTK widgets, and so on.

As such, the accessibility API is handled by the toolkit, not the browser.
For example, FireFox deploys a GtkCheckButton on GNOME for an <input
type="checkbox">.  GTK uses ATK to implement the accessibility layer.  What
appears in the accessibility tree in this case is what GtkCheckButton
provides via ATK.

For a <select> with a size of one, and a no multiple, the browsers have,
with at least two exceptions, chosen to deploy a combobox.  The two
exceptions I know of are Safari and Chrome on OS X, where a popup menu is
used.  (By comparison, Chrome on GNOME uses a combobox.)  Thus, the actual
widget on screen is a desktop combobox or popup menu, depending on the
browser and OS combination.

It is mapped as a combobox or popup menu because that's what it is.

> According to the HTML AAM[1]:
> * A select (with a multiple attribute or size attribute having value 
> greater than 1) is mapped as listbox.
> * A select (with NO multiple attribute and NO size attribute having 
> value greater than 1) is mapped as combobox.
> I suspect these mappings are a propagation of legacy desktop 
> nomenclature. Nonetheless, even if there is a historical desktop 
> precedence, I do not understand why a single-select list where only 
> one option is visible at a time is a combobox while a single select 
> list where more than one option is visible at a time is a listbox.
> I have long understood that a primary purpose of ARIA roles is to 
> communicate interaction models to assistive technologies so that they 
> may assist users appropriately. In this case, the visual presentation 
> of an element, not its interaction model, is changing its role. A 
> single select with size of 1 and a single select with size of 4 both 
> have a listbox interaction model.
> Telling the user that a select with size of 1 is a combobox when there 
> is no "box" (text field), seems very odd. I do not understand how it 
> helps users.
> The primary reason I am questioning the mapping at this time is 
> because I am trying to figure out how the authoring practices should 
> tell authors when to use the combobox role and when to use the listbox 
> role. We are attempting to make APG guidance consistent with typical 
> native element behaviors across browsers. In this case, however, it 
> seems very confusing to recommend the listbox role with one visual 
> presentation and the combobox role with another presentation when both 
> have the same interaction model and functional behaviors. This is 
> especially confusing when we also refer authors to the definition of 
> combobox, which is the combination of a text input and a popup 
> element. A select with size of 1 does not have a text input or a 
> separate popup element.
> Would there be any downsides to always mapping HTML select to listbox?
> It would certainly make guiding authors much more straight forward and 
> seems that it could also help simplify experiences for screen reader 
> users.
> Matt
> [1]


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

Received on Monday, 9 May 2016 22:10:28 UTC