W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

Re: Mapping of HTML select

From: Richard Schwerdtfeger <richschwer@gmail.com>
Date: Wed, 11 May 2016 15:36:44 -0500
Cc: Matt King <a11ythinker@gmail.com>, Joseph Scheuhammer <clown@alum.mit.edu>, ARIA Working Group <public-aria@w3.org>
Message-Id: <6375EADA-72D5-4CC7-81DE-D1C730BF9DF3@gmail.com>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Bryan, 

Here are the minutes of the last 2 meetings: 

https://www.w3.org/2016/04/28-aria-Here areminutes.html
https://www.w3.org/2016/04/21-aria-minutes.html

Here is the publication:

https://rawgit.com/w3c/aria/master/aria/aria.html#combobox <https://rawgit.com/w3c/aria/master/aria/aria.html#combobox>

Here is the text that covers the exception:

"The ARIA 1.0 specification describes a combobox pattern where a text input element has the combobox role and owns a listbox element. User agents <https://rawgit.com/w3c/aria/master/aria/aria.html#dfn-user-agent> and assistive technologies <https://rawgit.com/w3c/aria/master/aria/aria.html#dfn-assistive-technologies> SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional."

That is what we agreed to have. It is a SHOULD. 

So, essentially, the textbox is a required owned element but we say that user agents SHOULD support that the ARIA 1.0 pattern. It is not a MUST. This is what we agreed to.  

Rich


> On May 10, 2016, at 3:58 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> 
> " We agreed placing a role of combobox on a textbox was not appropriate."
> 
> Actually we agreed that role=combobox was equally supported on a textbox and that ARIA 1.1 would not be used to supplant the implementation that is already utilized all over the web accessibly, and instead that both would be equally supported going forward.
> 
> That stipulation was my only reason for agreeing with this.
> 
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> bryan.garaventa@ssbbartgroup.com
> 415.624.2709 (o)
> www.SSBBartGroup.com
> 
> -----Original Message-----
> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Tuesday, May 10, 2016 1:19 PM
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
> Cc: Matt King <a11ythinker@gmail.com>; Joseph Scheuhammer <clown@alum.mit.edu>; ARIA Working Group <public-aria@w3.org>
> Subject: Re: Mapping of HTML select
> 
> Correct. We require a textbox in ARIA 1.1. We agreed placing a role of combobox on a textbox was not appropriate. 
> 
>> On May 10, 2016, at 1:21 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
>> 
>> 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 Wednesday, 11 May 2016 20:37:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:26 UTC