W3C home > Mailing lists > Public > wai-xtech@w3.org > October 2010

RE: Clarification regarding ARIA Combobox

From: Victor Tsaran <vtsaran@yahoo-inc.com>
Date: Fri, 29 Oct 2010 15:54:07 -0700
To: James Craig <jcraig@apple.com>, Todd Kloots <kloots@yahoo-inc.com>
CC: "wai-xtech@w3.org" <wai-xtech@w3.org>
Message-ID: <03D67237123001448E3C58D3B562D545665F5852@SP2-EX07VS04.ds.corp.yahoo.com>
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] On Behalf Of James Craig
Sent: Friday, October 29, 2010 10:55 AM
To: Todd Kloots
Cc: 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.
Received on Friday, 29 October 2010 22:55:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:43 UTC