- From: Aaron Leventhal - Code <aaronlevbugs@gmail.com>
- Date: Fri, 16 Mar 2012 15:29:27 -0400
- To: public-pfwg-comments <public-pfwg-comments@w3.org>
- Message-ID: <CAJVXSMougy-rUyyw58KCWWvf64iKOQdWqJwxJ+9VXehREsXS8Q@mail.gmail.com>
This is similar to a comment I sent to wai-xtech on the same topic. This affects: - The ARIA implementation guide - Browser implementations of the ARIA role attribute and platform accessibility APIs - Flexibility in where ARIA landmarks can be used in content - Forward/backward compatibility of content with updates to the ARIA spec and/or browsers Firefox and WebKit-based browsers handle landmarks differently. WebKit implements the current ARIA implementation guide at http://www.w3.org/TR/wai-aria-implementation/#mapping_role -- "For the standard role mechanism of the accessibility API, the user agent * MUST* use the first token in the sequence of tokens in the role attribute<http://www.w3.org/TR/wai-aria-implementation/#def_attribute> value <http://www.w3.org/TR/wai-aria-implementation/#def_value> which matches, on comparison, the name of any non-abstract WAI-ARIA role." Firefox/Gecko implements an older version of the implementation guide at http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_role "The first role token with a known mapping to accessibility APIs SHOULD be used when mapping to the accessibility API via the standard role mechanism of the accessibility API. Use the role table below and apply any special case rules that are specified." In other words, when processing role="far bar baz", we used to map the first role corresponding to a platform API role. Now we stop at the first non-abstract role, and go no further. As I see it, there are two advantages to keeping the original role processing, as currently used implemented Firefox: 1. The landmark role can complement native semantics without clobbering them, e.g. <input type="text" role="search"> <table role="complementary"> <ul role="navigation"> Currently in WebKit, and according to the implementation guide, the text field widget, table, and list roles would not be exposed via native accessibility APIs, even though there are no native landmark roles. The user of an ARIA-enabled browser may in fact get reduced accessibility as this information is erased in the final mapping. 2. The old role processing enables forward compatibility of ARIA-enabled content with future browsers and platforms, as fallback roles can be used. For example, <div role="calendar grid"> or <table role="calendar grid"> allows newer platforms who understand a "calendar" role to map directly to that, but previous versions which did not know about "calendar", would fall back on "grid", still a valid, usable role for an AT user, even if not as optimized for the use case. This is important because the current set of ARIA roles is unlikely to be the final set. New UI patterns are continually emerging, and it will be very difficult to add new roles if backward I'd like to help sync the browser implementations on this issue. My (opinion) is that the older role processing is better for the reasons given above. I would love to hear other opinions. Thanks as always, Aaron
Received on Sunday, 18 March 2012 10:30:43 UTC