default role values for HTML elements and built-in accessibility

In an Earlier thread, we discussed the ways HTML5 could build-in  
accessibility by providing commonly used widgets and UI controls that  
UAss could then map to  the accessibility hooks provided by the UA or  
by the UAs host operating system. That idea had led me to propose  
doing this with the @role attribute by having a a sensible default  
@role value set for each element.

On Jun 27, 2007, at 1:36 PM, Robert Burns wrote:
> One idea that comes to mind from this discussion is that the new AT  
> related elements (like <progress>) might be defined in terms of  
> @role by indicating what the @role value would be by default (and  
> cautioning that it should not be changed except in rare  
> circumstances etc.). I think this would raise awareness about @role  
> and demonstrate its proper use. Its this type of default usage that  
> helps authors understand and properly extend these facilities.

The great advantage of this approach is it still allows simple  
authoring techniques to accomplish decent accessibility, but it also  
serves as a pedagogical device by demonstrating how to use the @role  
attribute for other custom extensions of HTML's semantics. This  
brings together many of our design principles: accessibility,  
extensibility, backwards compatibility, etc.

Just to try to provide a more concrete example, consider the HTML5  
progress element.  By simply adding the @role attribute as a global  
attribute[1], we would then specify a default value for each element.  
The <progress> element would have a default value of "progressbar". A  
UA running on Mac OS X (as just an example), would then  map any  
object created with a role of "progressbar" to the Mac OS X  
accessibility API's[2] role of "kAXProgressIndicatorRole". Since the   
<progress> element would have this default value for role, it too  
would be mapped to this.

Summary:
HTML5 Element:     <progress> with a default @role value of  
"progressbar"
WAIrole:     progressbar
Mac OS X Accessibility Services:      kAXProgressIndicatorRole CFSTR 
("AXProgressIndicator")

In this way, the use of role would be there and implemented by UAs  
without authors doing anything. Authors would not require any  
knowledge of @role it would simply "just work" behind their backs.  
However, as a pedagogical device, some authors would notice these  
@role attributes. As authors made new innovations and created new UI  
from HTML markup, they could also make use of the WAI role values on  
their new widgets. UAs would simply need to comprehensively map the  
WAI role values to their own internal (OS) role values. If HTML5  
identified any other roles missing from the WAI vocabulary, we would  
simply add those to the available repertoire. The @role attribute,  
all of the WAI role values, and any other role values we felt  
necessary would all exist in the HTML namespace so there would be no  
namespace headaches to deal with. Therefore when using role would not  
require the explicit use of namespaces at all. However, in the xml  
serialization authors would be free to use other role-value  
namespaces so long as the targeted UAs support those namespaces.

This to me seems like a big win. This is one of those instances where  
its hard to think of any disadvantages. To many authors the role  
attribute would just be there doing its work behind the authors back.  
Even those authors wanting to make use of role would do so without  
the need to incorporate namespace declarations. More advanced use in  
the xml serialization would permit the more advanced approach of  
incorporating roles from other namespace.

Any thoughts? Any disadvantages, I'm missing here?

Take care,
Rob


[1]: <http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060221.html>

[2]: <http://developer.apple.com/documentation/Accessibility/ 
Reference/AccessibilityLowlevel/index.html>

Received on Thursday, 19 July 2007 02:42:37 UTC