[whatwg] Dynamic content accessibility in HTML today

James Graham wrote:
> OK, I think I hadn't appreciated just how vague the W3C document is. I propose 
> we [standardize] the following:
> 
> A role attribute which may appear on (only non-semantic?) elements to indicate 
> that that element is part of a DHTML widget and not marked-up prose. The role 
> attribute would not be namespaced (in HTML5, in XHTML5... well who knows). The 
> role attribute would take certain predefined values (not those on the W3C page 
> which are largely useless, e.g. banner, or otherwise covered in HTML5, e.g. 
> navlist) corresponding to the various types of UI widgets understood by the 
> accessibility toolkits. As far as possible we would stick to whatever Firefox 
> currently implements, but we would simplify the syntax where necessary (e.g. 
> avoid qnames wherever possible). Values outside the predefined list would make 
> the document non-conforming.

   So long as it's clear that the UI roles are for DHTML widget
accessibility, then that's fine. UI roles feel mildly presentational to
me, but they're essential enough for accessibility that they can't
really be left to the style sheet, which is an optional technology.
Also, I suppose there may be situations where you'd want to use them
within an XBL binding, so I can't be certain the two aren't orthogonal
in specific use cases. (We should probably create use cases for using
the two in tandem to be sure.)

   Should the attribute only apply to <span> and <div> elements???

   Values that are not in the user agent's predefined list should be
treated just like unknown values in attributes like |rel|.
Vendor-specific values could probably have the same naming convention
that CSS uses: "-vendor-uirolename". Namespaces should either be
ignored, or we should use the Dublin Core dot convention
("namespace.subnamespace.role").

   Now that I look at that, the two don't seem compatible, so better to
use the second: "vendornamespace.subnamespace.role".

   The actual name "role" is too broad. Something like "widgetrole", or
"uirole" (which I prefer) would probably better communicate the
semantics of the attribute. (I proposed "wairole" earlier, but that's to
specific to a namespace.)

   Also, we need a way to allow accessibility for the UI state, so we
possibly need an attribute for that. Example...

| <span tabindex="0"
|       uirole="wairole.checkbox"
|       uistate="waistate.checked.indeterminant"
|       onkeydown="return checkBoxEvent(event);"
|       onclick="return checkBoxEvent(event);">
|   Any checkbox label
| </span>

   Thought: Should labels be able to treat elements with |uirole| as if
they were controls and pass focus to them when the underlying platform
permits focus passing to the specific UI role?

| <span id="mycheckbox" uirole="wairole.checkbox" [...]>
| </span>
|
| <label for="mycheckbox">A checkbox label</label>

> Does that sound reasonable or have I totally missed the point?

   Well, this allows us to avoid creating predefined class names for
|class| without simultaneously preventing class names from having
semantic meaning in the document. I'm still not completely convinced
this isn't just a means of communicating a media-specific presentation,
and it might just be giving ammo to supporters of the |onbeforeprint|
and |onafterprint| attributes, as they make a similar case for the print
media in situations where styling is optional/unavailable. But, then, I
suppose if we're going to have a UI state, we need the roles as well for
balance...

Received on Friday, 25 August 2006 11:24:49 UTC