- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 15 Aug 2006 17:53:53 -0400
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.
Received on Tuesday, 15 August 2006 14:53:53 UTC