[whatwg] Dynamic content accessibility in HTML today

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.

Received on Monday, 14 August 2006 04:18:01 UTC