RE: Handling of landmark roles on native markup

Steve,

if I get that right:

then the actual FF implementation is non-conformant
with respect to http://www.w3.org/TR/wai-aria-implementation/#mapping_role (because it exposes both roles).

Okay but this looks like a more fundamental topic for discussion: is the "democratic" exposing of multiple (native+ARIA) roles beneficial, and if so,
can this appropriately been mapped to all existing Accessibility API's? And won't this cause diversity in implementations one should avoid for the sake of clarity and simplicity?


-         Stefan

From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
Sent: Montag, 19. März 2012 12:14
To: Schnabel, Stefan
Cc: Aaron Leventhal - Code; wai-xtech@w3.org
Subject: Re: Handling of landmark roles on native markup

Hi Stefan,

>should be explicitly declared as allowed overrides for a selected number of elements in the HTML5 spec to justify the FF system in the long run, if FF >won't change its implementation/support.

this is the current situation, what is proposed and what currently works in Firefox is that

<table role="complementary">

results in BOTH roles 'table' and 'complementary' being exposed.

regards
steve

On 19 March 2012 11:10, Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:
IMHO, all landmark override cases like

 <table role="complementary">

should be explicitly declared as allowed overrides for a selected number of elements in the HTML5 spec to justify the FF system in the long run, if FF won't change its implementation/support.

Otherwise, the code

 <div role="complementary">
   <table> ...
 </div>

could be misunderstood as a permanent required "bypass" technique to avoid native role conflicts.

Regards
Stefan



From: Steve Faulkner [mailto:faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>]
Sent: Montag, 19. März 2012 11:29
To: Aaron Leventhal - Code
Cc: wai-xtech@w3.org<mailto:wai-xtech@w3.org>
Subject: Re: Handling of landmark roles on native markup

Hi Aaron,
I would also point out that adoption of this behaviour would result in a need to lodify the HTML5 conformance rules, which are currently predicated on ARIA roles always overriding native semantics.

While not a reason not to make the change, it is a factor that needs to be taken into account in the introduction of the changes. As getting ANY changes in to HTML5 is not a trivial task.

regards
steve
On 16 March 2012 18:24, Aaron Leventhal - Code <aaronlevbugs@gmail.com<mailto:aaronlevbugs@gmail.com>> wrote:
I recently discovered that 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."

As I see it, there are two advantages to the older system:
1. The landmark role can complement native semantics without clobbering them, e.g.
 <input type="text" role="search">
 <table role="complementary">
 <ul role="navigation">
2. It enables forward compatibility of ARIA-enabled content with future browsers and platforms, as fallback roles can be used. For example, <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.

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




--
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com<http://www.paciellogroup.com> | www.HTML5accessibility.com<http://www.HTML5accessibility.com> | www.twitter.com/stevefaulkner<http://www.twitter.com/stevefaulkner>
HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/<http://dev.w3.org/html5/alt-techniques/>
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
<http://www.paciellogroup.com/resources/wat-ie-about.html>



--
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com<http://www.paciellogroup.com> | www.HTML5accessibility.com<http://www.HTML5accessibility.com> | www.twitter.com/stevefaulkner<http://www.twitter.com/stevefaulkner>
HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/<http://dev.w3.org/html5/alt-techniques/>
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
<http://www.paciellogroup.com/resources/wat-ie-about.html>