[whatwg] Dynamic content accessibility in HTML today

[Matthew Raymond]

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.