Re-group, re-focus, reply (RE: "Pave The Cowpaths" Design Principle)

Lachlan Hunt wrote:
> John Foliot wrote:
>> promoting a vision that advocates, "We are against semantics for the
>> sake of semantics." [Lachlan Hunt: http://tinyurl.com/ys7lbo]
>> clearly illustrates how deep this divide is.
> 
> It seems that you taking what I said way out of proportion, so let me
> clarify.  Semantics for the sake of semantics refers things that have
> no real purpose or benefit to anyone, and only exist to appease a few
> semantic purists.  It has nothing to do with rejecting semantics that
> can be shown to have real benefits for accessibility.  But it has to
> be judged on a case-by-case basis, we can't just add all possible
> semantics for the sake of it.

Lachlan, I quoted you verbatim; if it is out of context or incorrect in
anyway, then I will accept your word on it.  But your written word stands on
Roger's Blog.

I have tried, on many different occasions to keep this discussion focused
and on topic, with threads such as "The Semantic Debate" , "@role (was RE:
Cleaning House)" and "Getting beyond the ping pong match (was RE: Cleaning
House)". 

In each of these threads, the overwhelming debate has essentially come down
to the "Cowpath" principle, rejecting suggestions and objections by members
of the accessibility advocates at every turn.

The real problem is, right now, we can't "prove" anything, because a) the
capability to prove or illustrate in the wild does not exist, and b) the
majority on the list do not have the experience or deep understanding of the
community and needs we are discussing.  While the goal of making an
improved, "easier" HTML is laudable, it in itself is no reason to reject
improvements to the usefulness of the language.  Not once has anyone
suggested that the mechanisms be mandated, but as it stands now, even the
appropriate "hooks" needed for richer semantic markup are being dismissed
out of hand.  

We're saying that your paved cowpath needs cut-curbs [*], and you're saying
prove it.  We can't, but we know you need them.

> 
> If there is some semantic feature that you think should be included,
> there needs to be clear use cases and problems to solve.  When a
> feature is proposed, it needs to be explained:

There has been no shortage of attempts to explain why there should be an
appropriate mechanism to add semantic "meanings" to specific content.  There
*HAS* been numerous counter-arguments and rejections of these explanations,
all focusing around the fact that it will be too complicated for the
garden-variety web publisher.  THIS ALONE IS NO REASON TO REJECT THE
CONCEPT.

> 
> * What are the use cases?

Example: There are numerous typographical conventions that employ italicized
text to denote something special about the content.  While often this intent
might be inferred though context, this is not always the case.  Some
examples (already discussed) include the convention of marking ship names in
italics; etymology or genus (definitions) would be another.  Often italics
are used to imply some kind of emphasis, but the emphasis could be of a
pleading nature, a forceful nature, a sarcastic nature, a wry nature, etc.
etc.  

And like link (anchor) text, what happens when the marked-up content is
taken out of context?  We've been some-what successful in making authors
understand the importance of appropriate link text, and it's getting better,
but the same principle applies - and yes, it also means educating the
authors; however, that is another story altogether.

> * What problems it solves and how?

An attribute that can be universally applied to visual rendering conventions
allows the semantic meaning to be associated to the visual rendering - which
today we cannot do.  This attribute ideally would be scalable, so that
multiple ontologies [http://www.w3.org/2001/sw/] could be defined and
applied: a small fixed list might be useful in a general context, but other,
more specialized libraries/definitions could be envisioned and should be
accounted for.

> * Who benefits and how?

- The visually impaired: future UA/AT could assign inflections of
synthesized voice to more naturally "speak" the italicized text. (pleading
vs. sarcastic)

- cognitively impaired: since the author's intent is associated to the
transcript locally, it would be trivial to have a look-up mechanism to
convey this information to those that need it.

- archivist, librarians, educational intuitions and other realms of
"officialdom":  imagine for an instance being able to mark up all instances
of Shakespeare use of irony.  Search tools could then parse documents
searching for this "mark-up".

- machines: in effect, we are creating "micro-meta-data"; like microformats
it is small "bits" of data that can be both human readable as well as
machine readable (the real power of microformats is the ability to use the
marked data in a machine context: add my vCard, add an iCal event, etc.,
etc.)

> * The incentive that authors will have to actually use it.

The benefits above could/would be incentive enough for some (many?) authors.
Government and institutional mandates could/would be another.  While
understanding the *why* should be a major consideration of the working
group, when it comes to some issues... I will now play the human right's
trump card; when it comes to accessibility, often it is the force of law
that provides the final incentive.  Sometimes the answer early on is just
"because".

As an illustration, look to automobile seat-belts.  It reached a point where
trying to "convince" people got little traction.  So first the laws were
passed that mandated the manufacturers to include them into cars; never mind
that there was no "proof" - the experts knew that if they got them out
there, they would work.  Then there were early seat-belt laws, which
initially met with over-whelming resistance.  However, coupled with the laws
came awareness campaigns and education, which combined eventually saw more
adoption.

Do some people today still not use seat-belts?  Of course, however, many,
many do use them today, and society is better off for it.  

The key however, is that first cars were made with seat-belts: they had to
start somewhere, and that somewhere was providing the means.  *THIS* is what
we are discussing now: HTML moving forward needs a semantic tool such as
being proposed - give it to the accessibility advocates, and leave the sales
job to us.

> * How it could be implemented.

I have suggested @role.  @role is/was envisioned primarily as an
accessibility enhancement anyway - early work on this attribute has been
associated to the ARIA suite [http://www.w3.org/WAI/intro/aria], which seeks
to make AJAX/DHTML functionality accessible to Adaptive Technology, so an
early precedent has already been established tying the two together.  @role
already has a means to link or associate multiple ontologies or definitions
to specific terms, so there is no need to re-invent a wheel (isn't this also
a goal of the HTML5 WG?).  Actual specifics may still need to be better
defined and applied (we are talking about something new here), however it is
work that could easily be done and incorporated into the new spec, building
upon pre-existing work already done.

Others have argued for using the @class attribute, but many from the
accessibility community (lead in part by Jukka Korpela [see:
http://lists.w3.org/Archives/Public/public-html/2007May/0719.html]) have
provided specific evidence on how this is a wrong direction: the whole
discussion around <...class="copyright"> should be convincing enough
evidence; the current problem with microformats date-stamping issue also
serves to prove how sometimes "repurposing" existing mark-up conventions has
un-anticipated problems.  This, I believe is the best reason to not use
@class; as well, I do not see a mechanism to make this method scale out,
where-as @role suggests a means already.

At some point then, do we get to ask you to prove-it to us?  Prove that
@class is better than @role?  Lachlan, you ventured an *opinion* about @role
on Roger Johansson's Blog, but where is the proof?  And if @role is not
appropriate, then we need to go back and start over, and discuss this
through.  I believe however that enough evidence has been presented against
using @class to support it's rejection as the right candidate for this
mechanism/tool.

> * The incentive that UA vendors have to implement it.

Firefox already has some support for @role; the ARIA suite work is being
funded in essence by the Mozilla Foundation and IBM.  If an accessibility
enhancement like this is provided for, Human Rights legislation, good-will,
market forces, etc. etc, will drive it's adoption.  This unfortunately is a
chicken-and-egg discussion in many ways, but like the seat-belt analogy
above, we need to start somewhere, and I believe that it starts by providing
the means in the spec: UA vendors, with a clear and well articulated
specification, have something to work towards.  Those of us who've been
around long enough remember the push by WaSP for standards compliant
browsers: we still don't have 100% perfection (to spec), but we've come a
long way, and with community based monitoring (WaSP Acid2 Test for example
[http://www.webstandards.org/action/acid2/]), it's getting better.

> 
> Any semantic feature that can't provide satisfactory answers to any of
> those questions, doesn't deserve to be included in the spec.

OK, so I've tried to answer your specific questions.  I have provided URLs
to back up some of the points, and I have tried to keep this reasoned,
un-emotional and fact based.

I now ask that the Working Group respond with fact-based replies.  Saying
that it will be "too hard", or that many authors won't use the mechanism is
here-say: you asked us for some answers and proof, we're asking for the same
back:

 * Prove to us that it's too hard.  
 * Prove to us that authors won't use the mechanism (provided we get it
right). 
 * Prove to us that UA vendors (as well as AT vendors) won't support such an
imitative. 
 * Prove to us that "...we can't just add all possible semantics" using a
mark-up language. 
 * Prove to us that a limited semantic mechanism using @class is better than
a robust, scalable mechanism using something like @role. 

Follow your own rules.

JF




[*] Initially provided to assist users in wheel-chairs, cut curbs today also
benefit people on roller-blades and skate boards, cyclists and mothers with
baby strollers; user-groups never originally envisioned when cut-curbs were
first mandated. And while retro-fitting older sidewalk intersections was a
time consuming and expensive undertaking, today the inclusion of cut-curbs
in new sidewalk construction is a matter of course, and adds little to
nothing to the overall cost of sidewalk construction or repair.

Received on Monday, 14 May 2007 16:52:36 UTC