- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Wed, 11 May 2016 22:13:52 +0000
- To: Rich Schwerdtfeger <richschwer@gmail.com>, ARIA <public-aria@w3.org>
- Message-ID: <SN1PR0301MB1981241A92908D6DE8BECBEC98720@SN1PR0301MB1981.namprd03.prod.outlook.>
Hello,
Since it’s become clear to me that this is still an issue regarding role=combobox, I would like to request that this issue please be put on the agenda to clarify it.
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Wednesday, May 11, 2016 2:22 PM
To: Richard Schwerdtfeger <richschwer@gmail.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
Then this is a problem that I will need to raise an official objection against.
The reason being that, we at SSB have been advising clients to utilize the provably accessible widget design pattern based on the accessibility API supported method documented in the ARIA 1.0 specification literally for years, and this pattern has been implemented within sites all across the web.
Since there is literally no reason for this paradigm shift that is based on a provable lack of accessibility to account for retiring or telling people not to use this pattern in accordance with the ARIA 1.1 specification, there is no reason why this should not be a must to account for the continued support of this design pattern in the future.
It is not reasonable to give AT vendors the impression that it is okay to drop support for a design pattern that is provably accessible right now, and nobody here can state a viable reason why this should be the case. This type of change will act in destabilizing the integrety of the ARIA specification, not secure it. Saying that user agents ‘should’ implies that they don’t have to keep it when they are in the process of remapping the new design pattern, and they can point to this statement in the spec to validate this.
This is not an unreasonable stance. The original proposal for improving role=combobox was specifically to add support for aria-controls and to support the Tree and Grid constructs as popups, not to throw out the old model and reinvent the wheel like this.
I’m sorry if I sound frustrated, but I have been trying to get an answer to this for months and nobody can explain why the old pattern is unviable when I can prove that it is accessible and has been so for years.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://www.SSBBartGroup.com>
From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Wednesday, May 11, 2016 1:37 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Cc: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Mapping of HTML select
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
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<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://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<mailto:bryan.garaventa@ssbbartgroup.com>>
Cc: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>; ARIA Working Group <public-aria@w3.org<mailto: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<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://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<mailto:clown@alum.mit.edu>>; 'ARIA Working Group'
<public-aria@w3.org<mailto: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<mailto:a11ythinker@gmail.com>>; ARIA Working Group
<public-aria@w3.org<mailto: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 -
From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Monday, May 09, 2016 9:55 AM
To: ARIA <public-aria@w3.org>
Subject: Agenda: May 5, 2016 WAI-ARIA Working Group
Agenda: May 5, 2016 WAI-ARIA Working Group
Time of meeting is 12:30PM EST, 9:30AM PST, 16:30 UTC, duration is 1.5 hours
Webex: https://mit.webex.com/mit/j.php?MTID=m5d67b552441a72bd1f52d696ad273d2e
US Toll Number: +1-617-324-0000 Access code:640 582 571 (Mobile Auto Dial: +1-617-324-0000,,,640582571#)
IRC: server: irc.w3.org<http://irc.w3.org> http://irc.w3.org/ , port: 6665, channel: #aria.
Agenda:
1. Chair: Next week’s call
2. 48 Hour CFC Result
- Host Conflict Call for Consensus: https://lists.w3.org/Archives/Public/public-aria-admin/2016May/0001.html
3. aria-keyshortcuts Progress? (Matt)
4. Action 1743: aria-activedescendant on application (20 minutes *max* discussion) Matt
- https://www.w3.org/WAI/ARIA/track/actions/1743
- Proposal: https://rawgit.com/w3c/aria/action-1743/aria/aria.html#aria-activedescendant
- Proposal: https://rawgit.com/w3c/aria/action-1743/aria/aria.html#application
5. Action 2059: Add aria-posinset and aria-setsize to roles menuitem, menitemcheckbox, and menuitemradio (Joanie)
- https://www.w3.org/WAI/ARIA/track/issues/1023
- https://www.w3.org/WAI/ARIA/track/actions/2059
6. Action 1489: Propose spec text to limit what aria attributes can be overriden by strong native semantics (Michael)
- https://www.w3.org/WAI/ARIA/track/actions/1489
- Proposal: https://rawgit.com/w3c/aria/ACTION-1489/aria/aria.html#host_general_conflict
7. Action 1513: Setup ARIA 1.1 Requirements draft
- https://www.w3.org/WAI/ARIA/track/actions/1513
- http://w3c.github.io/aria/requirements/aria-requirements.html
8. Action 2040: Modify section 7.4 to include role values as native host language semantics in paragraph 2 (Michael)
- https://www.w3.org/WAI/ARIA/track/actions/2040
- https://www.w3.org/WAI/ARIA/track/issues/648
9. Action 1624 Develop publication strategy and solution that would exclude abstract roles for authors (Michael, Shane)
- https://www.w3.org/WAI/ARIA/track/actions/1624
10. Action 1560 Email list with discussion of on/off value labels (maybe value text) and extending value descriptions to other controls (Stefan)
- https://www.w3.org/WAI/ARIA/track/actions/1560
11. Review Open Action Items and Issues (Many overdue items - need to get new dates and determine if must reassign)
- http://www.w3.org/WAI/ARIA/track/products/17
References:
ARIA Test Plan Action Items:
http://www.w3.org/WAI/PF/Group/track/products/5
ARIA Implementation Guide:
http://www.w3.org/WAI/ARIA/track/products/23
ARIA Name Computation Issues and Actions:
http://www.w3.org/WAI/ARIA/track/products/26
ARIA Test Report:
https://www.w3.org/WAI/PF/testharness/testreport?testsuite_id=1
ARIA 1.1 Test Plan Issues and Actions:
http://www.w3.org/WAI/ARIA/track/products/25
ARIA 1.1 Test Harness:
https://www.w3.org/WAI/PF/testharness/testcases?testsuite_id=4
WAI-ARIA Extension Process:
https://www.w3.org/WAI/PF/wiki/ARIAExtensions
ARIA Working Group Decision Policy
https://www.w3.org/WAI/ARIA/decision-policy
Minutes Last Meeting:
https://www.w3.org/2016/05/05-aria-minutes.html
Rich Schwerdtfeger
Received on Wednesday, 11 May 2016 22:14:24 UTC