[whatwg] Dynamic content accessibility in HTML today

[James Graham]

Matthew Raymond wrote:
>> Show me a spec that says that in a normative way. It is merely a "best 
>> practice". Class names, in general, are meaningless and meaningful class 
>> names should not be part of the core specification.
> 
>    The reason that semantic class names are "best practice" is because
> class names that are purely for presentational effects are less useful
> when using alternate or user style sheets.

That's a purely "human factor" though. There's no reason you can't use <div 
class="bigredtext"> and style it with an Aural style sheet. Or indeed with a 
visual stylesheet to present the text in small, blue letters. It's just /likely/ 
to make your document harder to understand if you do that.

 > In fact,
> a presentational class name might be applied to elements that have
> different semantics just because the author wanted to use the same style
> for all the elements, giving the impression that elements are related
> even when they're not.

That would be an acceptable use of class. It would probably be poor design 
(because later the author might want to restyle the elements separately) but 
that's not our problem. Indeed a nominal requirement that class names map to 
semantics would be impractical; there exists no 1:1 mapping between the 
semantics of an element and the way it is presented within a particular document 
(e.g. I might want 7 <h2> elements 3 being styled with a left float and red text 
and 4 being styled with a right float and green text).

Any attempt to formalise the class attribute beyond "it takes arbitrary values" 
is imho misguided and doomed to failure.

>> Of course, if you plan to put all the semantics of a document in the 
>> class names, we could do away with many elements. Do you object to <div 
>> class="h1"> as a replacement for <h1>?
> 
>    Your example only makes sense if you assume a mix of presentational
> names and semantics names as class values. For authors that use only
> semantic class names, the example is meaningless.

?

>>>    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.
>> Authors can misuse anything. <h1 style="font-size:12px; 
>> font-weight:normal;">This is the main text of my document put in a 
>> heading so that search bots think that it's really relevant and useful</h1>.
> 
>    What you fail to understand is that user agents will have to have
> means of handling the misuse,

No. I'm pretty sure I do understand that.

> which means that many of the differences
> between |role| and |class| are more conceptual than practical.

Not really (but don't take that as meaning that conceptual differences are 
unimportant! The difference between semantics and presentation is more 
conceptual than practical: a human will get the semantics - what is a header and 
what isn't, for example - from the presentation, not the 'semantics' embedded in 
the markup). Practically, class is an attribute in widespread use without any 
regard for the information required by accessibility tools. That means many 
pages could already be using class="tab" where their role attribute would be 
"tabpanel". Practically the class attribute is valuable in making arbitrary 
groups of elements suitable for selection by CSS or scripts - this has nothing 
to do with semantics of any kind. Practically, the presence of a role attribute 
implies that a group of elements should be interpreted as a particular component 
of a UI widget, significantly altering the interpretation of that subtree - 
justification enough for a new attribute (and, in some cases, for whole new 
/elements/)- and that other attributes on the element will be interpreted as 
ancillary information about that widget.

>>>    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.
>> We use it for it's purpose - to provide hooks to enable presentational 
>> languages to couple to arbitrary groups of elements on a page. This kind 
>> of non-semantic hook is _necessary_ so that the temptation to abuse the 
>> semantic elements is greatly reduced.
> 
>    The use case for such classes will become progressively smaller as
> XBL2 is introduced and CSS improves.

Why do anything today when in several decades you might not have to bother? I 
mean it's just happenstance that no-one is expected to need an assistive 
technology until 2050 or whenever CSS4+XBL2 are maturely implemented and, 
through a programme of extensive brainwashing, authors start doing the correct 
thing rather than the easy thing.

>>>    So what we end up doing is replacing |class| with an attribute named
>>> |role| that has more rules but otherwise does the same thing.
>> No. We add an attribute which conveys specific semantics ("this element 
>> is being used as a UI widget of a particular type). We standardize some
>> well-researched values for that element that are applicable to the needs 
>> of non-visual UAs in the real world.
> 
>    All of this could be done with |class|. The sole purpose for |role|
> is to separate presentational classes from semantic classes. 

No. It. Is. Not. It is to provide a means to indicate that certain collections 
of elements on a page should be interpreted as a particular type of UI widget, 
/not/ as marked-up prose. Class cannot fulfil that role without being 
significantly overburdened with multiple functionalities.

-- 
"You see stars that clear have been dead for years
But the idea just lives on..." -- Bright Eyes