Re: "Pave The Cowpaths" Design Principle

On May 15, 2007, at 6:07 PM, John Foliot wrote:

> Maciej Stachowiak wrote:
>
>> Sure, it's not a fair standard to say something must already be in
>> use to be added to the standard. But I don't think anyone is
>> requiring that.
>
> I invite you to re-read much of the "Cowpaths" thread.  There is an  
> implied
> undertone that if it's not already being used (or if something is  
> being
> under-used), it should not be considered.

If anyone said that, I would disagree with them. But I don't think  
anyone did.

> A review of one of your IRC logs also leaves that impression...  
> (hint: @profile)

Now we're mixing a bunch of different categories:

1) Things in past HTML standards that are generally not used (which  
can therefore be regarded as failure in the market) - @profile might  
be in this category, as it is seems to be mostly ignored by both  
producers and consumers.

2) Things that build on past HTML standards and are widely used, such  
as semantic use of @class.

3) Proposed brand new mechanisms for HTML, such as @role.

@role hasn't had a chance to fail the way @profile has, so the  
argument against it would be based primarily on needless complexity

>> The question comes up when you have two possible ways
>> to solve a problem, one using an existing mechanism, and one using a
>> new mechanism. I think it's reasonable to give the existing mechanism
>> all due consideration, to avoid bloating the language. But sometimes
>> that doesn't work.
>>
>> Examples in the HTML5 spec where current solutions were not
>> considered good enough (for accessibility and other reasons) and so
>> new features were added include <time> and <video>.
>
> Fair enough.  I do not currently believe that enough research has  
> been put
> forth that qualifies @class over @role in any meaningful way.  "We"  
> keep
> getting asked to prove our assertions, but that must be a two way  
> street.
> Currently it doesn't feel that way.

The main advantages of @class are twofold:

1) It is already part of the language and can't be removed, since it  
has uses besides encoding of semantic information.

2) It is already used to code semantic data on many web sites, in the  
form of microformats. This link will take you to many examples:  
<http://microformats.org/wiki/Special:Search?search=examples+in+the 
+wild&go=Go>

Here are some specific prominent sites using microformats based at  
least partly on @class:

http://upcoming.org/ (hCalendar)
http://facebook.com/ (hCalendar)
http://last.fm/ (hCalendar, hCard)
http://twitter.com/ (hAtom, hCard)
http://local.yahoo.com/ (hCard, hReview)
http://tech.yahoo.com/ (hReview)
http://flickr.com/ (hCard, Geo)
http://wikipedia.org/ (hCard, hCalendar, hAtom, hReview, Geo)
http://journals.aol.com/ (hCard)

These are just a few of the most prominent examples. There are also  
many tools generating or parsing microformats content.

So I think the semantic use of class is well established.

@role has the advantages of starting with a clean slate (so fewer  
possibly noncomforming uses out there) and

>
>> I think you're giving undue weight to only one of the listed design
>> principles. It's all a balancing test. We have to start from the use
>> cases and think about the best solution. Let's say our problem is:
>> "mark elements with one or more out of an extensible set of semantic
>> markers, where some may have a shared predefined meaning."
>>
>> We can solve it in the following ways:
>>
>> 1) Standardize the existing uses of "class" for this purpose,
>> including possibly some predefined values in the spec and
>> extensibility via a microformats-style approach.
>>
>> 2) Forbid the use of "class" for this purpose, and add "role".
>>
>> 3) Standardize on the use of "class" and also add "role".
>>
>> 4) Ignore the problem and allow ad-hoc solutions to develop.
>>
>> I think option #2 would make microformats advocates unhappy, and
>> would be basically ignored. It's unreasonable to ask that already
>> widely deployed semantic markup be changed, and to ask that data
>> extraction tools ignore it. This could only make sense if we
>> discovered major problems with this kind of use of class that we
>> can't readily work around.
>
> Fine, then tell me how you can work around this: <span
> class="copyright">built using a stupid WYSIWYG</span>?  Jukka and  
> others
> have pointed this out in the wild, and it is as much a problem as
> <...title="20070515">.  You had to chuck that out because it's  
> broken, and
> so?...

I don't think "copyright" is the world's best example, since a  
copyright notice can already be identified by trivial textual  
analysis, due to international standards on what form it must take.  
On the other hand, this also makes the cost of false negatives very  
low. I also don't see how we can keep your hypothetical "stupid  
WYSIWYG" from emitting nonconforming uses of "role".

> This may make some unhappy, but if you go this route, others will  
> be unhappy as well.

I'm not sure what you mean here. I think it's clear that the cost of  
forbidding semantic use of class would be very high at this point. We  
would have to destroy existing semantic information on many web  
documents, including some hosted at quite prominent sites, and  
discard many tools for information extraction. So semantic use of  
class is here to stay, whether or not the spec acknowledges it.

There's just no way we can make people stop using class for  
semantics, and I don't see why we would want to. So we may as well  
standardize it.

> As you said, it is a balancing act, but ensuring accessibility  
> *must* trump a bit of extra work and some developer unhappiness.

This is where I disagree with you. Accessibility is important, but  
it's not the only important thing. Making web documents and  
applications that work well for all users means also paying attention  
to the majority of users who do not have special accessibility needs;  
if supporting accessibility is a lot of work, someone is bound to  
lose out.

I think our goal should be to provide quite good accessibility with  
little or no extra work for web developers, and even better  
accessibility with a little extra work. We should not make it  
mandatory to do a lot of work for only a small incremental  
improvement in accessibility.

> As for accessibility requirements being ignored - perhaps in some  
> circles, but
> certainly not in others.  There are already laws in place that will  
> put that
> problem to rest.

As far as I know, legal requirements are to enable access, not to  
mandate specific technology choices in how to do this. If you think  
encoding deep semantics will legally required then I think such laws  
would ban most existing software and most existing document formats.  
We will then have much bigger problems than the class and role  
attributes. So please let's not use the law as a stick to argue for  
our favorite technical solutions.

We all agree that accessibility must be addressed, but there is still  
room to discuss the best way to do it.

> The problem boils down to this - some knowledgeable developers  
> *did* use and
> respect meaningful semantic class names, but many, many didn't.   
> And CSS
> @class selectors have been much more widely deployed than  
> microformats -
> hell Brian Suda and Tantek Celik are still out giving "microformats  
> 101"
> talks weekly (it seems).  So, rightly or wrongly, class="" has  
> morphed into
> a display selector due to poor user knowledge.  This, in and of  
> itself,
> isn't bad, but it puts the accessibility consideration into a tight  
> spot; if
> you are stating that class="" also conveys a semantic construct,  
> but half
> the time it doesn't, then it's broken before it even gets a chance  
> to get
> started.  So while the knowledgeable developers might have been  
> doing the
> right thing, the evolutionary process of @class sidetracked this,  
> and has
> polluted the ideal.

But actually, semantic use of class="" is now seeing a great  
renaissance thanks to the microformats and POSH movements, so things  
are actually moving in the right direction. I think it is wiser to  
ride this wave than to try to fight it.

>> Option #4 would be problematic as well - clearly there is a great
>> demand for this kind of capability, given that there are at least two
>> independently invented solutions.
>>
>> So basically we're down to #1 or #3 - which is a choice between
>> having one mechanism and having two mechanisms to solve the same
>> basic problem. I hope you can see why there is a pretty high bar for
>> @role then - it has to provide strong enough advantages to justify
>> adding a second mechanism to solve basically the same problem.
>
> But we (I!) continue to argue that the @class solution is already  
> broken, so
> you really can't count on that.

It may be that not all @class values are available for semantic  
encoding. In particular, depending on intended use, "copyright" may  
not be available. But I think the idea that @class is entirely  
"broken" for this purpose is clearly wrong, given the sheer number of  
producers and consumers of semantic information encoded in the class  
attribute.

> There has been suggestions that adding a prefix or other qualifier  
> to the
> @class attribute could solve this problem, but it does not take into
> consideration any kind of scalable solution - currently @class  
> names can be
> made up by anyone, for any reason.  This isn't bad, but it removes  
> any form
> of standardization - heck it reminds me of my old accesskeys battles -
> anyone could declare any old key to do any old thing, that was one  
> of the
> biggest problems - there was no standardization, and further, no  
> way to
> define your non-standard choices.  And while the spec may in fact  
> emerge
> with a fixed list, what if that list is lacking?  This to me is a  
> major
> shortcoming, and one that @role has already addressed (I do not  
> believe that
> a microformats type approach is strong enough to handle the task,  
> but I am
> willing to listen).

Which approach seems better depends on which you consider more harmful:

- Missing semantic information because the way to encode it is too  
hard and doesn't match existing author practices.
- Incorrect semantic information due to "false positives" from a more  
evolutionary approach.

>> I actually understand why the name "role" is somewhat comforting to
>> accessibility advocates, based on how Apple's VoiceOver screen reader
>> works and how it hooks into Safari. It is often desirable to express
>> the purpose of a UI element in a succinct way, relying heavily on
>> predefined values, to allow indirect control to visually impaired
>> users. However, at least for VoiceOver purposes, what is desired is
>> exactly one role, and it should be very strongly biased towards using
>> a predefined value for best effectiveness.
>
> Well, "role" is also a pretty semantic name for what it is supposed  
> to do,
> which makes it easier for the accessibility advocates and trainers to
> deploy.

But even better to have a 90% solution that doesn't require any  
accessibility-specific training, in my opinion.

> For this to work will require not just the means, but the education  
> on how,
> why, when, etc.  The accessibility community is used to this need for
> outreach and education, we spend a lot of time at it already, and  
> so an
> easy-to-grasp conceptual name like "role" makes this task easier  
> for us to
> accomplish.  It's a whole new "thing" to learn, as opposed to re- 
> learning
> about @class - too many under-informed designers will think they  
> already get
> it, and do it wrong.  I realize that this has nothing to do with  
> "code", but
> it is a significant consideration in the larger context.

Again, here I have to speak from Apple's experience. While we do have  
specific accessibility hooks that apps can use, we went to great  
pains to make Carbon and Cocoa apps work to a reasonable quality  
level even completely unmodified. I urge you to consider the great  
benefits of such an approach, if it turns out to be feasible for HTML.

>> I actually think this kind of accessibility mechanism can be built
>> based on elements and class names. For example, some common roles
>> used in Apple's screen reader are "Button" "Checkbox", "StaticText"
>> and "Link". Now, clearly, "Button" can be inferred from the <button>,
>> <input type="button"> and <input type="submit"> controls. But for
>> <input type="image"> it's less clear; and sometimes you have just a
>> random element with an "onclick" handler that acts like a command
>> button. For cases like this, it would be really great to have a
>> mechanism where the common cases work with no extra markup, but the
>> markup options exist. Things become somewhat more complex when you
>> have higher-order UI elements, such as navigation links or calendars.
>
> <snip of some pretty reasoned and reasonable use-case studies>
>
> The thing is, currently @role is being used (tentatively) for UI  
> elements,
> and in the context of accessibility.  This is why I suggest that  
> @role can
> continue to be the "carrier" of other accessibility solutions - it  
> has not
> suffered the same fate of mis-use that @class has.  How much over- 
> loading of
> @class do you think is going to happen?  If examples from the wild  
> are any
> indication, probably not very much, and more often than not possibly
> wrongly.

My rough proposal is meant to work reasonably even when authors use  
*no* specific carrier of accessibility solutions, by mostly making  
use of the predefined semantics of existing element. The carriers are  
meant to be used to refine this baseline accessibility experience,  
and for that purpose, I think class would work just fine.

>> I'm definitely going to try to learn more about accessibility and
>> assistive technologies from the accessibility experts at Apple. Since
>> Apple ships both a browser and a screen reader, the intersection of
>> the two areas is of great interest to us.
>
> This is probably the best news I've heard on this list for some time.

The fact that it seems like news is, I think, based on  
misunderstanding the intent of many with a relatively Descriptivist  
bent. We agree largely on practical goals (after all, Universal  
Access is also listed in the Design Principles document, written by  
many of the same people), just not necessarily on how best to achieve  
them.

> Remember however that the semantic issues under discussion  
> transcend simple
> AT solutions - there is also the cognitive impairment impacts that  
> good
> semantic conveyance will address - a huge boon for one user-group  
> that for
> so long have continued to miss out on much of what the web can offer.

Now I think you are going beyond well-established accessibility  
solutions into the realm of the deeply speculative. See more below.

>> In exchange, however, I wish accessibility advocates would engage
>> with the process with a focus on use cases and how we can best
>> address them, rather than just the particular mechanisms invented
>> partly for accessibility. It's unhelpful to assume that anyone who
>> dislikes your proposed feature is against accessibility. They may
>> simply have a different view on the best way to address them.
>>
>
> Maciej, this is a fair request.  It would be helpful if members of the
> working group refrain from incendiary and dismissive remarks, and  
> try and
> understand that the rules of engagement are shifting here.  It  
> would also be
> helpful to realize that when numerous accessibility advocates with  
> long and
> established precedence and pedigree are all saying the same things,  
> that
> maybe, just maybe, we *do* know better, as this is our area of  
> expertise. I
> by no means wish to become spokesperson for any group - everything  
> I have
> written has been my perspective and opinion, but the emails of  
> support I
> have received lead me to believe I am saying what a lot of others are
> thinking.   Trust is a two-way street, and if we say we know you  
> need curb
> cuts, you have to trust  that we know what we are talking about.

I do think that accessibility experts know enough about  
accessibility. But I don't think that makes you automatically right  
on all questions pertaining to accessibility. Similarly, I don't  
think security experts are necessarily the best people to design  
security features by themselves, since they often give insufficient  
weight to other factors such as usability.

In any case, based on an understanding that we're all in favor of  
improved accessibility, I hope we can productively discuss how best  
to achieve that, in balance with other goals for HTML.

>> Anyway, if this kind of approach seems like a good idea, I'd be happy
>> to work up a more detailed version that also covers state (checked
>> vs. unchecked, slider position, text contents and caret position of a
>> text control or contentEditable area) and other such things.
>>
>
> This might be helpful, but much of what has come before has focused on
> "semantic" intent.  A lot of this came from the discussion of <i>  
> vs. <em>.
> I personally think that <em> has more semantic weight, but either  
> are poor
> carriers of real meaning: they both essentially create a visual  
> rendering, a
> point T.V. Raman made about a week ago.  A more useful exercise  
> would be to
> figure out how to convey emotional intent, or differences in  
> typographic
> norms, etc.  Building upon your examples:
>
> 1) <p>Do you <em role="ax:tone:suggestive_playfulness">really</em>  
> want to
> hurt me?</p> (Boy George)
>     (this might also be a conveyance of irony... it's tricky.)
>
> 2) <p>Do you <em role="ax:tone:forceful_enquiry">really</em> want  
> to hurt
> me?</p> (Movie Script)
> 3) <p>Do you <em role="ax:tone:shocked_surprise">really</em> want  
> to hurt
> me?</p> (Movie Script)
>    (granted 2 and 3 are very nuanced, but reach for the stars,  
> settle for
> the moon)
>
> 4) <p>His insurance covered everything except <dfn="" lang="fr"
> role="ax:legal_term" class="italics">force majure</dfn>  
> occurrences</p>
> (and yes, I've seen class="italics" in the wild -
> http://b00mb0x.org/front/001161.html - broken no less...)
>
> 5) <p>The California poppy (<i lang="lt"
> role="ax:genus:botanical">Eschscholzia californica</i>) is native  
> to grassy
> and open areas...</p>

This seems like a research project to me, not a technology ripe for  
standardization.

1) There's no evidence that it is practical to mark up emotional tone  
and fine shades of meaning ion a large scale. Not even semantically  
rich markup languages like DocBook go this far, and DocBook is aimed  
at specialist technical writers, not general authors.

2) You did this markup only for words or phrases that would be  
rendered in italics, but surely to be really useful you'd have to do  
this for every word that has multiple interpretations that exist in  
different contexts. Or at least, I know of no evidence that users  
with cognitive impairments have a harder time with italicized words  
than non-italicized words.

3) I don't know of any tool that can use this kind of rich semantic  
encoding to improve accessibility for cognitively impaired users.

4) Keep in mind that the web isn't a centralized broadcast medium, it  
is a read-write space. Users with accessibility needs have to be able  
to generate content as well as consume it. It even harder to imagine  
congitively impaired users generating this kind of rich semantic  
encoding than users of average mental abilities -- which is already  
quite a stretch.

5) It seems to me that users who have a hard time with complex  
language or the use of irony would be better served by alternate  
content than an attempt at semantic markup.

Given all these, I think this idea is too speculative to become part  
of HTML, the lingua franca of the web, at this time.

> Not saying that this is right, or the right way, but this is one of  
> the real
> needs that I see, that is currently lacking.  I honestly can't see  
> how this
> can be done with a fixed dictionary, unless it is a very large one,  
> but I'm
> willing to listen.

I draw the opposite conclusion - *without* an agreed-upon fixed  
dictionary, the semantic information represented is useless to  
general-purpose tools. How is a tool going to make use of your "tone"  
values unless it already knows what they mean? Adding the ability to  
define your own ontology just punts the problem of knowledge transfer  
down one level - it does not solve it.

I would prefer not to tie solving well-understood accessibility  
problems to this kind of cutting-edge research topic.

> I am doubly curious to hear how a microformats type
> mechanism can address this, as I don't think it can completely - and
> half-fast is no good

I don't think it can, but I am not sure anything can solve this problem?

>> I'd really prefer if we could focus on designing a good technical
>> solution rather than the name of the attribute. After all that is
>> what matters ultimately - providing the right kind of info to
>> accessibility tools.
>>
>
> Uhm... Providing the right kind of info to THE USER, regardless of the
> tool(s) they may choose to use.

That's a pretty different requirement, and I'm not sure I agree.

We have to expect that conveyance of information that exists to serve  
accessibility needs will be mediated by some assistive technology,  
and that we can make reasonable requirements on how that technology,  
just as we can on browser vendors and content authors. Similarly, we  
can't expect to provide the right kind of info to the user regardless  
of who the content author is, since the content author may not have  
followed good practices.

This is why I phrased it as I did.

Regards,
Maciej

Received on Wednesday, 16 May 2007 02:50:39 UTC