[whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

There are a lot more roles than what you listed, and they are all mapped 
via desktop accessibility APIs such as MSAA and ATK to the assistive 
technologies. So we already have truly accessible DHTML widgets that are 
key navigable and usable with 3rd party tools such as screen readers.

If you're interested in what roles are supported, check out the docs:
http://developer.mozilla.org/en/docs/Accessible_DHTML#Simple_and_complex_examples

You have to do something like <div role="wairole:alert">....</div> or 
<span role="wairole:tab">
There is no other standards-based way to make these types of widgets 
accessible in a web page today. I don't think it's a narrow use case. 
Look at the huge numbers of websites that are trying to become more like 
desktop applications.

- Aaron



Matthew Raymond wrote:
> Aaron Leventhal wrote:
>   
>> Firefox has support for making dynamic web applications with custom JS 
>> widgets accessible, via support for xhtml:role and aaa: properties. If 
>> anyone would be interested in taking a look, I would welcome feedback.
>>     
>
>    What Firefox is doing for DHTML accessibility has a very narrow use
> case. It applies to DHTML widgets, that are not bound to fallback markup
> using XBL, where a proper CSS presentation for the users primary media
> is not available, and where the CSS3-UI "appearance" property doesn't
> provide a proper value. I suspect that many DHTML widgets, however,
> won't necessarily have a corresponding predefined |role| value, which
> means |role| essentially becomes just another vector for microformats.
>
>    I don't see a significant difference between |role| and predefined
> values for |class|. For instance, I believe Dublin Core specifies
> predefined |class| values, so it's not like there's no precedence for
> it. The only difference is that |class| doesn't explicitly state that it
> can be used for such purposes.
>
>   
>> I have a specific question: what about adding the role attribute to 
>> whatwg specs?
>>     
>
>    I don't see any sufficient benefit from it. I'd rather see a
> clarification of how |class| can be used.
>
>   
>> However, I thought I'd ask anyway because the role attribute does fill 
>> some niches:
>>
>> 1) [accessibility] in SVG
>>     
>
>    I don't understand. Could you provide a use case? BTW, how would this
> even apply for HTML, which has no namespaces?
>
>   
>> 2) roles that no specs today have, which provide important accessibility 
>> functions, such as liveregion for AJAX accessibility (perhaps we should 
>> try to synchronize the 2 sometime)
>>     
>
>    I'm not following you here. This sounds a lot like microformats.
>
>   
>> 3) ability to fix [accessibility] in JS apps that exist today
>>     
>
>    There are only a small number of supported values for the |role|
> attribute. Most of those are covered by tags in HTML5:
>
> <article> <--> "main"
> <section> <--> "secondary"???
> <aside>   <--> "note"
> <nav>     <--> "navigations"
> <header>  <--> "banner"???
> <footer>  <--> "contentinfo"
>
>    So, the only things really missing are tags for "seealso" and
> "search". Note that <footer> may cover "seealso". It might be that
> "seealso" doesn't have a sufficient use case to give it an element
> separate from <footer>. I think we probably need some way to
> semantically identify searches, though.
>
>    I can't really understand "banner". Is it a header or an ad? If it's
> for ads, I suspect it won't be used. Why tell people something is an ad?
> They can just make and extension to filter the ads out.
>
>    Secondary is another think that's hard to understand. It seems to be
> in between <aside> and "note".
>
>    So, generally, I don't see |role| providing significant improvements
> over existing markup in the HTML5 spec, especially since you'd have to
> have less semantic elements to act as the parents for each |role|
> attribute...
>
> HTML5:
> | <footer>[...]</footer>
>
> HTML + |role|:
> | <div role="contentinfo">[...]</div>
>
>    Now, which is more readable? Clearly the first example, especially in
> a complicated web design when you're looking for the _CLOSING_ tag.
> Elements are clearly smaller and better, and since namespaces are
> required for user-defined |role| values, the actual number of |role|
> values that can be used in HTML is limited to those listed in the spec.
>
>   
>> 4) ability to create new custom roles -- this is still under development 
>> (at the moment it uses RDF, but I believe the group will consider XBL 
>> moving forward)
>>     
>
>    How does this differ from using XBL with |class| and other existing
> HTML attributes to implement microformats???
>
>   
>> 5) The role attribute allows us to specify additional semantics without 
>> conflicting with older browsers
>>     
>
>    So would using classes with predefined semantics, and styling with
> classes is very well supported on CSS-enabled user agents.
>
>    I agree that there are some styling issues with the new HTML5 markup,
> seeing as they're all block-level elements, and my understanding is that
> unknown elements are treated as inline by default. Perhaps some test
> cases are in order.
>
>    The question becomes when should we use elements and when should we
> use predefined class names. I think that if the semantics are structural
> in nature, such as headers, footers, et cetera, then an element is
> preferred. If the semantics are just a narrowing of an existing
> element's semantics, class would be better.
>
>