RE: Clarification regarding ARIA Combobox

Thanks, James. This makes sense.


From: James Craig [mailto:jcraig@apple.com]
Sent: Friday, October 29, 2010 4:32 PM
To: Victor Tsaran
Cc: Todd Kloots; wai-xtech@w3.org
Subject: Re: Clarification regarding ARIA Combobox

Victor,

Perhaps I phrased something poorly, or perhaps you misread. I never meant to imply that ARIA wouldn't take precedence over the implicit role.

I implied that ARIA does not override behavior, so if you put the combobox role on an element that does not natively support text input (e.g. a container div instead of an input[type="text"]), then the author has to maintain JavaScript events for text entry.

In other words, if you have a <div role="combobox" tabindex="0"></div>, then the screenreader will happily tell you that it's a combo box, but typing in it will not behave as expected unless the author handles all the key events.

On the other hand <input type="text" role="combobox"> will accept be text input natively, and the screenreader will tell the user it's a combo box. This appears to be the best approach, even though the Authoring Practices document does not mention it yet.

And finally, the other example Todd mentioned:

            <div role="combobox">
                        <input type="text" role="textbox">
                        ... listbox also ...
            </div>

In this case, the keyboard focus lands on the text box, so the user doesn't understand that it's a combo box, unless the rendering engine knew that this was a text box inside a combo box, which is more difficult, because the combo box role could be way up in the ancestor hierarchy, and because most AX APIs don't work this way, so the rendering engine would either need to misrepresent the accessibility tree, or it would need to flatten a lot of the DOM hierarchy in order to convey that this a combo box, not a text box.

The author could work around this problem by taking the approach I mentioned in the first email, but it's a pain, because it ends up being equivalent to  <div role="combobox" tabindex="0"></div>, and the author has to maintain everything related to text input.

Is that any more clear? Sorry for the confusion.

James


On Oct 29, 2010, at 3:54 PM, Victor Tsaran wrote:


James,
Doesn't this contradict with the statement where an ARIA role should take precedence over the HTML tag to which it is applied? I remember the discussion we had where it was suggested that the landmark role, for example, should overwrite the tag to which it is applied.

From: wai-xtech-request@w3.org<mailto:wai-xtech-request@w3.org> [mailto:wai-xtech-request@w3.org] On Behalf Of James Craig
Sent: Friday, October 29, 2010 10:55 AM
To: Todd Kloots
Cc: wai-xtech@w3.org<mailto:wai-xtech@w3.org>
Subject: Re: Clarification regarding ARIA Combobox

In theory, either should work, but as you've noticed, applying the combobox role directly to the text field works better in most rendering engines. This is partially due to the fact that the rendering engine has to work harder to determine the other pattern, and the author has to work harder to implement it. If you apply the combobox role to the container surrounding the textbox, you need to make the container focusable with tabindex="0" and make the textbox non-focusable with tabindex="-1"; you then have to register for key events and manage updating the value of the textbox instead of letting the browser do that natively, which is near impossible to do well once you consider localization and alternate input methods. Hence the reason the spec recommends the approach of applying the combobox role directly to the element with focus and native text entry behavior.

Thank you for bringing the discrepancy. As with anything created by fallible humans, there will be discrepancies or errors, and many of the authoring practices examples were written while the spec was in a state of frequent change. The spec is mostly stable in it's second Last Call state, while the authoring practices is an informative document that will likely see many more rounds of revisions. Getting that example synced back with the spec is likely to be one of those revisions.


On Oct 28, 2010, at 9:55 PM, Todd Kloots wrote:



Having just re-read the latest drafts of the ARIA spec and corresponding authoring practices document, I noticed they were out of sync regarding definitions and recommend markup patterns for comboboxes.  Was wondering if this was intentional (perhaps to illustrate that there isn't a single way of doing things?), or if the two documents are just presently slightly out of sync.

The combobox role definition from the ARIA spec defines a combobox as "the combined presentation of a single line textfield with a listbox popup".  And the HTML example that immediately follows that definition shows the "combobox" role applied directly to a text field, with an listbox as its sibling.

Contrast that with the ARIA Authoring Practices document that defines a combobox as "combination of text field, which may be editable, a drop button to choose an item to place in the combo box, and a displayable list of items".  So, this definition includes a button and indicates that the "combobox" role should be applied to a parent element that contains all three controls that the compose the combox (the textfield, button and listbox).

Before the current version of the ARIA spec, I've only seen the pattern as recommended in the Authoring Practices document.  However, in practice we've found the combobox pattern in the current version of the ARIA spec (applying the combobox role directly to the textfield) seems to work best across browsers and screen readers.

I am curious about the differences between the spec and the Authoring Practices document.  Will there eventually be a consolidated definition and single recommended pattern?  Or is the idea to present a range of patterns, all of which are supposed to be supported equally well for maximum developer flexibility?

Todd Kloots
Accessibility Engineer
Yahoo!, Inc.