RE: Updated combobox examples for APG

Jon, Bryan,

So we have finite and complete consensus now that for combos

<input type="text" role="combobox" ...

the role is and will be always as *default design pattern* on the input and *NOT* on its container?

If so, this would be straight with the examples according to 1.0 and 1.1 specs for  https://www.w3.org/TR/wai-aria/complete#combobox example.

And less confusing. Just asking.

And if so, may I ask if the first pattern in http://w3c.github.io/aria/practices/aria-practices.html#combobox will become obsolete?
If not, then we may keep the examples as examples for the first pattern.

- Stefan

-----Original Message-----
From: Gunderson, Jon R [mailto:jongund@illinois.edu] 
Sent: Montag, 7. März 2016 21:53
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; ARIA Working Group <public-aria@w3.org>
Subject: RE: Updated combobox examples for APG

I will update the combobox examples to follow the ARIA spec, which appears to be the same right now in 1.0 and 1.1.

Jon


-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Monday, March 07, 2016 2:09 PM
To: Gunderson, Jon R <jongund@illinois.edu>; ARIA Working Group <public-aria@w3.org>
Subject: RE: Updated combobox examples for APG

Sorry I missed this email earlier, I'm glad Matt fielded the question during the meeting.

I've been aware of the APG versus spec disconnect for a long time, and this has caused many problems over the years, because the APG advises something that actually has no accessibility API support according to the spec, which leads to the proliferation of inaccessible widgets through misinformation.

Just to clarify this for everybody, neither the original APG nor the new one is normative, and there is no requirement that developers are required as a MUST to do what it says.

The spec however is a normative document, and developers are required to follow the guidance documented there to ensure the correct role and supporting attribute usages in order to guarantee that it synchronizes properly with the UAIG so that user agents can correctly reflect these roles in the accessibility tree.

So as we work on APG 1.1, in all design pattern cases it is vitally important that we make absolutely certain that the guidance in the APG specifically reflects what is documented in the ARIA 1.1 specification, because this will directly map into the accessibility APIs.


-----Original Message-----
From: Gunderson, Jon R [mailto:jongund@illinois.edu]
Sent: Monday, March 07, 2016 9:34 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; ARIA Working Group <public-aria@w3.org>
Subject: RE: Updated combobox examples for APG

Bryan,

It looks like there is a disconnect between the authoring practices and the ARIA spec.  
So maybe we can discuss briefly on the call today.
I can update the examples to put combobox on the INPUT element that is defined in the ARIA spec
The authoring practices guide uses the word container with the INPUT element as the first child element.   
So the ARIA 1.1 specs says one thing and the ARIA Authoring Practices 1.1 say another.

ARIA Authoring Practices:
http://w3c.github.io/aria/practices/aria-practices.html#combobox 

ARIA Spec:
http://w3c.github.io/aria/aria/aria.html#combobox


Jon
  

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Monday, March 07, 2016 9:55 AM
To: Gunderson, Jon R <jongund@illinois.edu>; ARIA Working Group <public-aria@w3.org>
Subject: RE: Updated combobox examples for APG

I understand your point about having alternative examples, but the problem I'm having is that the word 'support' is a relative and entirely subjective statement.

So when you say it is supported in Firefox, that isn't because the accessibility APIs support this markup structure, because the authoring spec has been saying the opposite for many years.
https://www.w3.org/TR/wai-aria/roles#combobox

The normative authoring spec is quite explicit about how to construct a combobox, and if done as the spec says, it results in a very accessible combobox that is supported across all of the accessibility APIs today.

So I do think it is very dangerous to mix alternative markup examples into the APG that can be proven are not accessible, because developers will never know which are which, and these examples are going to be around for many years and be plaguing us for years to come with bad markup combinations.

This is why I think we need to be careful not to include alternative examples in the APG that have not yet achieved consensus, because developers are going to start using these materials long before accessibility APIs can catch up with these alternative structures that go against what the 1.0 spec actually says developers should be doing.



-----Original Message-----
From: Gunderson, Jon R [mailto:jongund@illinois.edu]
Sent: Saturday, March 05, 2016 9:12 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Updated combobox examples for APG

Bryan,

I think we can have examples in the APG that represent the alternatives, and when things are finalized we delete the examples that don¹t implement the specification.
This is especially useful for people who are not as familiar with the issue,  seeing alternatives in code helps people not tracking the issues as closely. 
These examples do work in other browsers like Firefox with JAWS and NVDA, so common examples are important for people can use to test and understand the issues.
We can make additional examples putting combobox on the input element.

Jon


On 3/4/16, 7:37 PM, "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com>
wrote:

>Hi,
>In testing the markup, focus is bounced out of the combobox when using 
>JAWS in IE11, and neither is accessible.
>
>The reason is because JAWS doesn't support the use of role="combobox" 
>on the parent container of a focusable editable element, so the 
>role="combobox" attribute needs to be on the HTML input for this to 
>work accessibly, including all associated attributes, which matches the 
>spec text in 1.0.
>
>Currently we don't have agreement how or if putting role="combobox" on 
>an ancestor element in the markup is supposed to work, so putting this 
>in the APG is premature because nothing in the spec says this, so too 
>is adding the guidance that the combobox will open a Dialog because 
>nothing has been mapped to support this on any platform.
>
>We are scheduled to talk about the ancestor issue next Thursday when 
>Cynthia can attend the Caucus call.
>
>I recommend that we not put things in the APG that haven't achieved 
>consensus, otherwise we will have an obsolete document before it's even 
>finished.
>
>-----Original Message-----
>From: Gunderson, Jon R [mailto:jongund@illinois.edu]
>Sent: Friday, March 04, 2016 1:23 PM
>To: Gunderson, Jon R <jongund@illinois.edu>; ARIA Working Group 
><public-aria@w3.org>
>Subject: RE: Updated combobox examples for APG
>
>Better links:
>https://rawgit.com/jongund/aria/master/practices/examples/combobox/comb
>obo
>x-1.html
>https://rawgit.com/jongund/aria/master/practices/examples/combobox/comb
>obo
>x-2.html
>https://rawgit.com/jongund/aria/master/practices/examples/combobox/comb
>obo
>x-3.html
>
>Jon
>
>-----Original Message-----
>From: Gunderson, Jon R [mailto:jongund@illinois.edu]
>Sent: Friday, March 04, 2016 3:21 PM
>To: ARIA Working Group <public-aria@w3.org>
>Subject: Updated combobox examples for APG
>
>We have also updated the combo box examples to use aria-selected and 
>created an additional example using aria-activedescendant.
>
>https://rawgit.com/jongund/aria/master/practices/examples/combobox/comb
>obo
>x
>-1.html
>https://rawgit.com/jongund/aria/master/practices/examples/combobox/comb
>obo
>x
>-2.html
>https://rawgit.com/jongund/aria/master/practices/examples/combobox/comb
>obo
>x
>-3.html
>
>
>Please review, test and comment.
>
>Jon
>
>
>

Received on Tuesday, 8 March 2016 08:26:02 UTC