RE: Mapping of HTML select

Just to clarify one thing in the statement:

" Both ARIA 1.0 and 1.1 require a textbox to be part of a combobox; it is a required owned element."

That's not entirely true, because in accordance with ARIA 1.0 you can do the following:

<div aria-label="States" role="combobox" contenteditable tabindex="0" aria-expanded="false"></div>

Then when the Down arrow is pressed and it browses a listbox, aria-expanded is set to "true" and aria-activedescendant is used to reference the highlighted role=option node. This already works accessibly even though there is no textbox descendant.

I agree though that the dual API mapping of both combobox and listbox on a native select element is confusing at times.

Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com


-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Monday, May 09, 2016 3:02 PM
To: 'Joseph Scheuhammer' <clown@alum.mit.edu>; 'ARIA Working Group' <public-aria@w3.org>
Subject: 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 elements.

Matt King

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu]
Sent: Monday, May 2, 2016 11:14 AM
To: Matt King <a11ythinker@gmail.com>; ARIA Working Group <public-aria@w3.org>
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] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
>


--
;;;;joseph.

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

Received on Tuesday, 10 May 2016 18:22:02 UTC