[whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

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

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? Otherwise, both authors and machine processors 
will be easily confused by it.

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?

- Aaron

Matthew Raymond wrote:
> James Graham wrote:
>   
>> Matthew Raymond wrote:
>>
>>     
>>>>> [...] where a proper CSS presentation for the users primary media is
>>>>> not available [...]
>>>>>           
>>>> This is almost always the case on the real web.
>>>>         
>>>    Yeah, the web masters are so lazy that they can't be bothered to add
>>> accessibility via CSS, but they'll be working overtime putting in |role|
>>> attributes using the correct predefined values.
>>>
>>> /me rolls eyes.
>>>       
>> Roll your eyes all you want but when you get bored, perhaps you'd like 
>> to try thinking about the relative difficulty of the two tasks instead
>>     
>
> HTML + Role:
> | <span tabindex="0"
> |       role="wairole:checkbox"
> |       property:checked="true"
> |       onkeydown="return checkBoxEvent(event);"
> |       onclick="return checkBoxEvent(event);">
> |   Any checkbox label
> | </span>
>
> HTML + CSS3-UI:
> | <span tabindex="0"
> |       style="appearance: checkbox"
> |       property:checked="true"
> |       onkeydown="return checkBoxEvent(event);"
> |       onclick="return checkBoxEvent(event);">
> |   Any checkbox label
> | </span>
>
>    But this is really just a distraction, since I generally support
> using class instead, which itself can be used to style an element using
> the "appearance" property.
>
>   
>> :-) For many widgets it is entirely obvious what their role attribute 
>> should be (if it walks like a duck and quacks like a duck it's a duck). 
>>     
>
>    How is that? What other W3C approved values are there other than
> those in the |role| working draft?
>
>   
>> So adding this information to the semantic layer (i.e. not CSS) is easy. 
>> Furthermore, people who make common widget toolkits can add 
>> accessibility information at the toolkit layer (see e.g. [1]) so authors 
>> don't need to work very hard.
>>     
>
>   Correct, although I would point out that toolkits can be redesigned to
> support whatever becomes a standard.
>
>   
>>>>>    I don't see a significant difference between |role| and predefined
>>>>> values for |class|.
>>>>>           
>>>> Oh and I'm allergic to predefined class values :)
>>>>         
>>>    I would suggest a strong antihistamine whenever you use a microformat.
>>>       
>> Indeed there are, I believe, a number of problems with microformats 
>> associated with their use of the class attribute (e.g. I remember a 
>> discussion some time ago in which it turned out that microformats must 
>> use globally unique classnames)
>>     
>
>    I see nothing in the HTML 4.01 spec that prohibits class names from
> having colons, nor does it explicitly forbid the use of namespaces, so
> nothing stops us from using namespaces in class names. (You could argue
> that the namespace URL has to be declared, but I don't see how |role|
> avoids this problem.)
>
>    Meanwhile, the spec for |role| _REQUIRES_ name spaces for anything
> that isn't directly defined in the working draft. Therefore, it is
> actually more restrictive for microformats than using |class|. So I
> really don't understand your argument.
>
>    Yes, there are those who oppose the use of namespaces for
> microformats, but near as I can tell, they oppose namespaces in all
> circumstances, including in XML. The |role| attribute would not escape
> their wrath, due to its namespace requirement.
>
>