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] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
>


-- 
;;;;joseph.

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

Received on Monday, 2 May 2016 18:13:55 UTC