[whatwg] Dynamic content accessibility in HTML today

[Matthew Raymond]

Aaron Leventhal wrote:
> So you are saying this should be mapped to assistive technologies via 
> the CSS3 "appearance" property or via special values in the class attribute?

   No, actually, I believe I made it clear in the last post that I
prefer predefined class names as the best way to address assistive
technologies.

> The role attribute currently describes behavior, and is added so that 
> users with disabilities know what the behavior for a given element is, 
> according to well-known semantics. CSS is supposed to be for 
> presentational. In your scenarior, will there be any way to easily know 
> whether one of the items in the class attribute describes the behavior 
> is purely presentational?

   Well, authors are not supposed to put in purely presentational class
names to begin with, but I fail to see how |role| avoids this. The
bottom line it that |role| has to be able to handle unidentified values,
and so does |class| with predefined class names. I have yet to hear an
argument with regards to why |class| can perform the same functions that
|role| can, especially given the allowance in the HTML 4.01 spec for
"general purpose processing".

> Otherwise, both authors and machine processors 
> will be easily confused by it.

   Machine processors can simply treat unidentified values as
non-semantic. Those it identifies it should process.

   The values for |role| are nothing more than a new set of class names,
and there is nothing preventing the user from putting in unidentified
|role| values for presentational purposes and then styling them via CSS
using attribute selectors. So aside from being mildly harder to select
from CSS, |role| values are potentially no more semantic than |class|
values.

   However, let's assume that people would only use semantic values in
|role|. What becomes of |class|? We use it only for styling? That won't
work, because HTML is supposed to be semantic. Do we use it for
author-defined classes? Even if that were the standard, there's no way
to prevent the use of author-defined classes in |role| because the
author could simply define a namespace and the user agent would have no
way of knowing the difference between author-defined roles and a true
standard that simply isn't supported by the user agent.

   So what we end up doing is replacing |class| with an attribute named
|role| that has more rules but otherwise does the same thing.

> I like the role attribute because it's already usable in Mozilla, to 
> make accessible web applications. What's the advantage of using 
> class/appearance instead, if there is no browser already mapping this 
> information to assistive technologies?

   The |class| attribute contains names in a string separated by
whitespace. The |role| attribute contains names in a string separated by
whitespace. The difference is that nearly all browsers support the CSS
class selection and DOM interfaces associated with |class|. Take one
good look at the CSS to style |class| versus |role|:

| .classname { property: value }
| [role~="classname"] { property: value }

   The latter is not just more complicated, it also depends CSS 2.1
attribute selectors. By contrast, a |class| value can be selected by any
browser with a CSS implementation.

   The bottom line is that in order to support |role|-style values with
|class|, all you'd have to do is implement code to check for the
supported names. In fact, there is a draft regarding the use of role
values in |class|...

http://www.w3.org/WAI/PF/adaptable/HTML4/embedding-20060318.html

   ...I do, however, disagree with the idea that namespaces can't be
used inside the |class| attribute. It's only the declaration of the
namespace in HTML that's tricky.