RE: Mandatory and Important

Boris Zbarsky wrote:
> John Foliot wrote:
>> so in the end we have a
>> situation where the only real "loser" is the claim of conformance.
> 
> Well, and the credibility of a standards organization that writes
> standards that are impossible to follow in certain cases that the
> standard covers.

This is an opinion and not a fact.  All of the reasons and justifications
for not including a text alternative are human error based - there is not a
technical or physical reason why this cannot happen, only one of poor
planning, non-conformant authoring tools and/or author
ignorance/apathy/inability.  While all of these factors must be accounted
for, to say that it is "impossible" is patently false.

> 
> Not that this is a big problem, apparently, since some standards
> organizations do produce such standards with regularity.

And, it should be noted, large institutions and other entities routinely
ignore standards in the pursuit of the holy dollar, and could give a
tinker's toss [http://tinyurl.com/5wo4uf, which, BTW, you should try viewing
with images off...] about standards in the first place.  Google still does
not use a DTD, despite it being a conformance requirement since HTML 3.2,
and your institutions web site [www.mit.edu], while being very good, still
has a number of conformance errors to the HTML 4.01 Transitional doctype it
declares.

So again I pose the question, if it boils down to a choice between lowering
the bar to aid in conformance to entities that generally do not care about
conformance even today, or writing a specification that ensures that with
conformance you also get completeness, which should we codify?

U cn rite grbge wrds n stl b unerstood - jest dnt call it propr gramer.

> 
> Why are we privileging some kinds of incompleteness over others?
> Because they're easier to detect by machine?  A document with every
> other word removed is pretty much "incomplete" in the sense of
> coneying the information, but conformant....  Of course a validator
> can't check this, just like it can't check correctness of the alt
> value (for now). I can see the "easy win" argument here: checking for
> existence of @alt is easy, and adding it is likely to improve
> completeness in many cases. Is that basically the argument for
> making it required? 

One of many put forth.  Putting forth edge-cases when this should not be a
requirement opens the door for abuse - Never is unequivocal in it's
position.  It adheres to Specification writing norms such as using RFC2119
[http://www.ietf.org/rfc/rfc2119.txt] to define requirements and places @alt
in the "must" column, without a back-door that says "...except when..." .
One thing that the Web Accessibility community learned the hard way was the
problems introduced with wiggle room states just like that (with the
frustrating "Until user agents.." clause(s) of WCAG 1). If you want good,
robust, clean and clear standards, start with RFC2119, and respect the
states that this document puts forth.  I do not want to privilege any part
of the specification.

As well, do not confuse the "art" of the contributor (be it Chaucer, the
rapper 50 Cent, or the ramblings of a 6 year old) with technical
requirements.  If you choose to write incomplete sentences, or use slang or
poor-to-non-existent grammar in your prose, that is a completely separate
issue from what we are asking for - insisting that when non-textual content
is provided on screen, that a means to directly link that object to a text
equivalent be present to be conformant.  Why is that so hard?  How is this
"impossible"?  What can we do to make it easier for all - both author and
consumer?

A number of alternative suggestions have emerged from both sides of the
debate which should be discussed between both sides - the latest proposal
(of using the curly braces to denote some form of semantic meaning) emerged
from the HTML working group with absolutely no input from the WAI PFWG (as
far as I can tell, and trust me I have been following this closely for a
very long time) - a community of experts *CHARTERED* by the W3C to advise on
accessibility issues.  So another reason for the backlash is that the HTML
WG is apparently making decisions independent of the very groups who should
be guiding these decisions.

Boris, let's be perfectly clear: I acknowledge that @alt alone does not
solve all problems, and that @alt can be and is often today "gamed". The
current proposed "solutions" to this very real problem are non-solutions
that the expert community is advising the Working Group not adopt.  The
working group cannot accept that the experts have no quantative data on this
subject (nor does the Working Group, BTW) and that the expert community
bases it's recommendations on nothing more than years of experience, empathy
and understanding of our constituents. But isn't that what experts are known
for?

> 
> P.S.  Still no opinion on making alt required, by the way.

Well, for what it's worth I do.  I could live with @alt being "optional" as
long as an alternative to @alt was present. I even said so as early as this
spring - my suggestion is noted in the ESW wiki - the supposed place to
contain such suggestions and ideas, although apparently never really
reviewed by the spec author or his immediate circle of friends [see:
http://tinyurl.com/63dq3r]

For example, currently within the Accessibility community there is some
renewed discussion on the validity and usefulness of attaching @role to
image assets (and other <objects> too) that could double in for @alt when no
author supplied value is present. 

We have 2 ways of thinking of an image, however both ways can be expressed
as the question "what is it?", and this is where @alt often fails.  For
while it might be a) "...the fifth of 300 vacation photos taken last summer
in Florida..." it can also be b) "...my daughter Susie making a sandcastle
at the beach..."  So we need two ways of informing consumers about the
image, yet currently we only have @alt.  So the proposal then would be/could
be that *if* either information stream were present (@alt *OR* @role) then
there would at least be some information available to the end user beyond
alt="", or worse, no @alt at all and at that point the image could be
considered conformant.  Neither present? - Non-conformance. It is not a
perfect solution, but one that can be and (IMHO) *is* a pragmatic proposal
and possible solution.  

Other ideas such as finding a means of *directly* linking <legend> to an
<object> should be provided - currently my read is that this linking is by
inference only:  why not something similar to form inputs and labels (which
make use of the "for" and "id" attributes).  Yet other proposal speaks to
using ARIA attributes such as labeledby and/or describedby to attach some
contextual information to an image.  It should be noted that none of these
ideas have been publicly aired or tested - instead after the last round of
shouting back and forth across the aisles, Mr. Hickson and cronies went off,
did some private wood-shedding and returned with alt="{photo}". Yech!

Respectfully,

JF

Received on Monday, 25 August 2008 16:06:30 UTC