Re: HTML 5 Accessibility Mappings

David,

The point being that today you need an ARIA role to be able to apply aria 
attributes. Yet, HTML 5 defines default ARIA semantics for many of the 
elements removing the need for the author to define an aria role to apply 
the aria attributes that are applicable to that role. If the author 
overrides the role using role="foo" then that replaces the role. So there 
is no reason for the author to expose roles separately if for all HTML 
elements that don't have a pre-defined ARIA semantic we simply pass the 
role value as the tag name. 

I don't see the value for providing the DOM element tag name and the role 
attribute. Perhaps I am missing something. Are you asking the AT to 
correct an author error?

What I am proposing would actually reduce the number of object attributes 
as you don't need to pass the tag name and the role - just the role.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:   David Bolter <david.bolter@gmail.com>
To:     Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:     Steve Faulkner <faulkner.steve@gmail.com>, wai-xtech@w3.org
Date:   01/25/2011 03:12 PM
Subject:        Re: HTML 5 Accessibility Mappings



Hi Rich,

Thanks for posting this.

Note gecko exposes a 'tag', 'element-name' pair already so the (corrected) 
#3 would imply duplicated object attributes. I think I would like to 
expose the role and the element name separately so that AT can decide on 
its own workarounds. I'm open for debate on that.

I'm not how "What this does for the author is it allows the author to 
supply ARIA states and properties to elements that do not have a role 
supplied but depend on the native ARIA semantics as defined by the HTML 5 
specification." is strictly dependent on what we expose via the object 
attribute. It seems like a separate issue.

Note for number 4, gecko almost always overrides the element->desktop role 
mapping and trusts the author. We don't really validate the role attribute 
against the element name. Having both the role and tag object attributes 
allows the AT to decide what is best. I realize there are pros and cons to 
this design.

The proposal seems to be heading towards using object attributes as the 
new defacto API (why bother with our existing enumerated MSAA/IA2 roles) 
for browsers. I like the idea of having a more flexible extensible API. 
Overall I have had push back from devs like Jamie (NVDA) about overusing 
the object attributes, so I'm interested to hear his feedback on this 
thread.

Cheers,
David

On 25/01/11 3:45 PM, Richard Schwerdtfeger wrote: 
Yes Steve. Thank you for the correction.


Rich Schwerdtfeger
CTO Accessibility Software Group

Steve Faulkner ---01/25/2011 10:50:13 AM---Hi Rich, you wrote:

From: Steve Faulkner <faulkner.steve@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: wai-xtech@w3.org, david.bolter@gmail.com
Date: 01/25/2011 10:50 AM
Subject: Re: HTML 5 Accessibility Mappings



Hi Rich, 

you wrote:

3. For HTML elements that have default ARIA role semantic we pass the HTML 
element name as the role in the name value pair passed in the object 
attributes sent to the AT

shouldn't this be? 

"For HTML elements that have NO default ARIA role semantic..." 

regards
stevef

On 25 January 2011 16:40, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: 

In HTML 5 we introduce the concept of native host language semantics in 
terms of ARIA roles for all HTML elements. I would like to propose the 
following

1. All HTML elements should provide a role attribute in the corresponding 
accessible object through the object attributes (such as in IAccessible2)
2. For HTML elements that have an ARIA equivalent role that role should be 
passed as the role name/value pair in the object attributes unless the 
author overrides the default elements role in the object attribute
3. For HTML elements that have default ARIA role semantic we pass the HTML 
element name as the role in the name value pair passed in the object 
attributes sent to the AT
4. For HTML elements with an allowable ARIA role attribute that is 
provided by the author we pass that role as the role attribute in the 
object attributes

What this does for the author is it allows the author to supply ARIA 
states and properties to elements that do not have a role supplied but 
depend on the native ARIA semantics as defined by the HTML 5 
specification.

A case in point:

<table tabindex="0" role="grid" aria-activedescendant="idx">
<tr>
<th>vegetables</th><th>fruits</th> ...
</tr>
<td id="idx" role="gridcell">broccoli</td><td role="gridcell>apple</td> 
...
</tr>
</table> 


TR has a native host language ARIA semantic of "row" but no role is 
needed.
<TH> defeaults to columnheader and so on.

Feedback?

Rich Schwerdtfeger
CTO Accessibility Software Group 




-- 
with regards

Steve Faulkner
Technical Director - TPG

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