RE: ACTION-1490 updates for March 17 ARIA caucus

Thanks.

“My mapping do you mean the situation where you have a textbook with a role of combobox and an associated listbox?”

Yes, when role=”combobox” is applied to a textbox including all supporting attributes plus aria-activedescendant, you currently get an accessible widget type that is supported both in accessibility APIs and ATs right now. This is provably true.

Moreover, if you apply the same concept using the same technique above to point to role=gridcell or role=treeitem nodes in support of role=grid and role=tree as we’ve been discussing, you also get an accessible widget that works correctly in both accessibility APIs plus ATs right now. This too is provably true.

This is why I don’t understand the desire to reinvent this wheel totally from scratch, and I don’t understand the desire to throw this out in 1.1.

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Thursday, March 17, 2016 12:26 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Matt King <a11ythinker@gmail.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: ACTION-1490 updates for March 17 ARIA caucus

I put a link to this post in action 1490 so that Matt addresses works to address your concern in his proposal:
https://lists.w3.org/Archives/Public/public-aria/2016Mar/0200.html


So, I don’t think the ARIA 1.0 mapping for combobox is something you put in the ARIA 1.1 spec. My mapping do you mean the situation where you have a textbook with a role of combobox and an associated listbox?

I have concerns about Dialog as well. I am waiting to see Matt’s proposal after CSUN.

Rich

Rich Schwerdtfeger



On Mar 17, 2016, at 10:29 AM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

In reading the new text, it also needs to be made explicitly clear somewhere in the section that the ARIA 1.0 mapping for combobox is still valid in 1.1.

This is very important, because checker tools will start flagging it as invalid for ARIA 1.1 otherwise.

If you want one live example why this is needed, go to
http://google.com<http://google.com/>
Type “printers” in the search field, wait a few seconds, then press the Downarrow.

This is a combobox based on 1.0, and though it is missing a couple of attributes that I’ve already mentioned to Dominic, it is provably accessible in the accessibility APIs and within ATs such as on Windows using JAWS and NVDA in IE, FF, and Chrome.

As just one example of this, it is used by hundreds if not millions of people every hour.

It will be a disservice to all companies around the world who are using this accessible widget type to imply through omission that this is somehow no longer valid according to ARIA 1.1.

I am also totally opposed to including role=dialog as a supported child of role=combobox.

The <select> element for example maps to role=combobox on the platform accessibility API on Windows for example, and when encountered on the web by a non-sighted AT user, it sounds exactly like an element marked up with role=combobox, and a <select> element does not and never will open a Dialog, nor can you tunnel into a <select> using the virtual cursor, so it makes no sense to me why this would be expected within a simulated combobox using ARIA.

To be perfectly honest, it is still unclear to me why we are doing all of this, because nobody has explained how this is supposed to improve accessibility over what is already working accessibly right now, though I have asked for a detailed explanation of this repeatedly on this list over the last month, and have been repeatedly ignored.

This is a valid question though, because what I see is years of work to create a new wheel from scratch that has the ultimate goal of trying to equal the accessibility of the current wheel that is already working accessibly.

Can somebody please explain how this new implementation is supposed to be more accessible than the implementations that I have already referenced now and previously?
E.G
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm

To phrase this differently, how is this new implementation supposed to work better and more accessibly than the above implementation?

If this can’t actually be explained, then why are we totally reinventing the same wheel?

Moreover, the support and use of Grid and Tree already works in the 1.0 implementation as I’ve already demonstrated on this list as well using a reproducible code example, both in the accessibility tree as well as within ATs within common AT/browser combinations, so this too is valid.

Why are none of these things being addressed?

I’m not trying to be a bastard, but I see this as a huge expenditure of effort over many years, and nobody can explain why and how this is supposed to be more accessible than what we already have right now.

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Wednesday, March 16, 2016 6:00 PM
To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: ACTION-1490 updates for March 17 ARIA caucus

I posted the following comment in action 1490 describing revisions to the previous proposal for combobox.

Changes made as a result of March 10, 2016 meeting

Note: The revised combobox proposal is now in branch action1490-combobox:
http://rawgit.com/w3c/aria/action1490-combobox/aria/aria.html#combobox


The branch includes the following changes as a result of the Mar 10 discussion.

1. Revised definition so that it does not imply that listbox and grid are classified as popups as opposed to elements that popup.

2. elivated the following normative aria-autocomplete statement from author SHOULD to author MUST:
If the combobox provides autocompletion behavior for the text input as described in aria-autocomplete,
authors MUST set aria-autocomplete on the textbox element to the value that corresponds to the provided behavior.

3. Added an author MUST statement that restricts the role of the popup element to listbox, tree, grid, or dialog.
And, correspondingly added listbox, tree, grid, and dialog as required owned elements.

Matt King