[whatwg] Dynamic content accessibility in HTML today

[Matthew Raymond]

James Graham wrote:
> 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.

   If you have a class name that's purely presentational and has no real
meaning, why would anyone go out of their way to change its
presentation? It's more likely that the class name has at least some
marginal semantic meaning and that the author merely chose a poor name
for the class. How often do you go in and tweak your user style sheet
just to make red text blue?

   (Granted, there may be reasons if you're color blind, but it would
make more sense for user agents to have special features for color blind
individuals, like changing red text to blue automatically. Any
presentational name will likely be be fairly unique to the document or
author, so just using the user style sheet will mean adding at least one
selector per website.)

>> 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.

   In actuality, it's probably poor selector design as well. It may be
possible to style those specific elements without using the
presentational class name at all.

> 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

   There is no 1-to-1 mapping between a class name and its presentation...

| p.classname { /* One style. */ }
| h1.classname { /* Another style. */ }

   How a style sheet author chooses to style content, whether in a
|class| attribute or not, is irrelevant with regards to whether or not
that content has semantic meaning.

> (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).

   Random changes the styling of elements within the document is a bad
idea for presentation, let alone for semantics. If you have such a shift
in the presentation of the document content, it's probably because the
content has changed context in some way, such as it being in a new
section of the document, and not because the author just felt like
making something green and float right. In the situation above, the
author could have just as easily used a selector containing the ID of
the parent section instead of creating a class.

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

   The fact that we can't completely eliminate non-semantic class names
doesn't mean that we can't require that class names _should_ be
semantic. Furthermore, even when classes are intended purely for
presentation, the presentation itself may be an unconscious indication
of semantic meaning. By allowing semantic predefined class names and
encouraging their use, authors need replace their
less-semantically-named-but-nevertheless-semantic classes.

>>> 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>?
[ Snipped my nonsensical initial reply. ]

   How is |role| any different?...

| <div role="html:h1">...</div>

   This is a false argument. We have to define what should be a role and
what should be in markup whether we use |class| to declare them or
|role|. It's orthogonal to the topic at hand.

>>>>    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.

   You give no such indication. Some of the arguments you make against
|class|, for instance, apply equally to |role|.

>> 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).

   Then we agree that some "presentational" class names may actually
have semantic meaning...

> 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".

   The |role| specification requires that all roles not immediately
defined in the draft have name spaces, so if we use the same convention
with class, this is a irrelevant. There's no motivation for authors to
associate a namespace with a correct namespace URL, then use that
namespace for presentational class names. It's insane.

   As for the non-namespaced values in the spec, most are covered by
markup in Web Applications 1.0.

> 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.

   Scripting is a means of implementing roles, and there's nothing in
the HTML specification preventing user agents from performing "general
purpose processing" in a script-independent manner.

> 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.

   The language of the |role| specification is actually unclear. The
intro indicates that |role| can be used to "describe the semantic
meaning" of elements, while Section 3 says the following:

   "It is used by applications and assistive technologies to determine
the purpose of UI widgets."

   It does not, however, specify that it cannot be used for purposes
unrelated to widgets. I think the working draft needs to be clarified if
the attribute is only intended to provide widget-related semantics.
Also, I don't think just "role" properly communicates that it's for
widget purposes. Considering the way it's being used in Firefox, I'd say
 something like "wairole" makes more sense. Besides, how many different
namespaces do you need for widget behavior???

| <span tabindex="0"
|       wairole="checkbox"
|       waistate="checked"
|       onkeydown="return checkBoxEvent(event);"
|       onclick="return checkBoxEvent(event);">
|   Any checkbox label
| </span>

   Something that bothers me about the wairole stuff, though, is that it
assumes specific widgets with specific properties. It's beginning to
look a lot like we're defining specific widgets and behaviors rather
than specifying semantics. One could look at this like a canned widget
binding rather than actual semantics. One has to wonder if this isn't
simply a way of improving DHTML widgets until XBL 2.0 arrives.

   So perhaps the "semantic meaning" talked about in the |role| working
draft intro really is just hot air. Is role is just a way of turning this...

| <wai:sitemap>
|   <nav>
|     <ul> ... </ul>
|   </nav>
| </wai:sitemap>

...into this...

| <ul role="navigations wai:sitemap"> ... </ul>

   ...thus allowing you to overload an element without all that pesky
nesting and such?

   I'm not really in favor of this kind of overloading. My instincts
tell me that mapping multiple elements from multiple namespaces onto one
element would be a real nightmare.

>>>>    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.

   Your argument isn't valid. You suggest that I wish to do nothing,
when in fact I'm offering an alternative that recycles existing role
definitions. The code for searching a |class| string for specific role
names can't be any different than the code for |role|. The |class| and
|role| elements have nearly identical problems when used for the same
purpose. The code burden for roles is essentially the same regardless of
which attribute you use, accept that with |role| you have to add an
attribute.

   Besides, you're arguing that we should implement an attribute that
effectively deprecates the |class| attribute because |class| will
continue to be used in the immediate future. This is not unlike arguing
that <font> will continue to be used after the introduction of CSS,
except that in this case I don't feel you've demonstrated a clear
advantage for the new technology like you could with CSS.

>>>>    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.

   As I have stated, I think the working draft needs clarification on
this point.

> Class cannot fulfil that role without being
> significantly overburdened with multiple functionalities.

   It's already "overburdened" with those functionalities. Take a look
at just about _ANY_ microformat. I'm not trying to overburden class. Nor
will |role| unburden |class| if its sole use is for UI widget roles.