RE: [html4all] several messages about alt

Henri Sivonen wrote:
> First, why do I even care to touch this rathole topic? It affects
> directly how the product I develop is expected to behave, and that
> affects its relationship with its users.
> 
> Here's how I see this discussion:
> 
> ...no matter how you try to spin it, in the real world, pushing
> the pixels to the Web is the primary function--getting the alt text
> out there is not the primary function

And herein lies the flaw in your reasoning.  Let's quote the "inventor" of
the web as we have it today:

	"The power of the Web is in its universality. Access by everyone
regardless of disability is an essential aspect."

Yes, I know, over-quoted to the point of cliché.  

Here's some better ones though [source:
http://www.brainyquote.com/quotes/authors/t/tim_bernerslee.html]:

	"I think IT projects are about supporting social systems-about
communications between people and machines. They tend to fail due to
cultural issues." 

	"IT professionals have a responsibility to understand the use of
standards and the importance of making Web applications that work with any
kind of device."

	"The original idea of the Web was about supporting the way people
already work socially, but this doesn't happen with a lot of IT projects."
(maybe because the "social" aspect is missing? - JF)

	"The Web is now philosophical engineering. Physics and the Web are
both about the relationship between the small and the large."

	"Whatever the device you use for getting your information out, it
should be the same information."

With all due respect Henri, I think I'll listen to TBL over you when it
comes to understanding the web. 

Pushing pixels is the "how" part, but pushing information is the "what"
part, and this is where the engineer driven opposition to a mandatory @alt
comes from.  It is analogous to saying that because not everyone uses
seat-belts, car manufacturers should be allowed to make seat-belts optional
on some cars.  While on the surface that certainly stands up to a logic
test, the reality is that it is not "right", which is why all cars today are
sold with seatbelts.  Whether or not *YOU* Henri wish to be part of a social
engineering movement is not the point - it is incumbent on the next
generation authoring language to accept that responsibility, warranted or
wanted (or not).

>   2) want (either directly themselves or as a client requirement) the
> output of their software to be valid HTML (whatever that means)
>   3) realize that there's no fundamental computer science barrier to
> pushing around pixels without an accompanying string (hence the string
> can be faked to accomplish #1 and #2 simultaneously)
>

Right, and still today many people refuse to wear their seatbelt, so
car-makers should be able to argue that mandating seatbelts in all
automobiles has not succeeded in the goal that it was set to accomplish?
Thus, seatbelts should not be mandatory in automobiles... After all, cars
still drive even if the seatbelt is not worn.

Taking the analogy one step forward, I for one am not arguing that images
without @alt not render... Heck there are enough broken web pages out there
already, but what I do want is that @alt remain required, and if you don't
provide it that glaring stupid blinking light on the dashboard that reminds
me to buckle up continue to flash.  Ignore it or not, that is the author's
prerogative, but disabling the blinking dashboard light does absolutely
nothing for anyone save the person who cannot be bothered to buckle up -
blinking or not, the car still drives, but the blinking has an effect...
Maybe someone will start to wear their seatbelt.

> 
> Now, does the policy benefit the intended beneficiaries? It is clear
> that the policy will lead to information loss or bogus information in
> a non-trivial proportion of cases. This means that user agents have
> less information to work with to benefit users. The harm part is
> obvious on the surface given what we know about the consequences of
> faking data when it is missing instead of signaling that it is
> missing. 

This is why I continue to advocate for reserved values.  They aren't
"faked", they're known.  Their real value remains minimal to users who
require appropriate alternative text (not just the blind as Steven F has
pointed out), however unlike "faked" values, reserved values can be
accounted for by all class of users, and dealt with accordingly.  Your
checker can sniff the reserved values and know that the author has thought
about the image (or not, but at least it conforms) whereas alt="" or no alt
attribute at all is flagged as an error/warning.  I would think that this
would be a good thing for a testing tool (but I don't make testing tools - I
work professionally in the field of web accessibility).

> 
> As for "sending a strong message" while actually not benefitting the
> supposed beneficiaries, I have no interest in becoming (through the
> product I develop) a stooge for such a policy.

Your personal views and desires should not count one iota in the development
of both International specification and policy.  The fact that you see
advocating for a more accessible web ("sending a strong message") as being a
"stooge" does little to instill confidence in your commitment to
accessibility.

> This is another reason
> I care. Sending a strong message doesn't necessarily translate into
> better accessibility. Consider:
>
http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=13584
85200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all
&oref=slogin
> 

This can be read two ways: consider the final line of your article -
"Because if there is any law more powerful than the ones constructed in a
place like Washington, it is the law of unintended consequences."  It is the
unintended consequences of making @alt optional that has not been fully
thought through by those who seek only a technical purity, despite the
obvious (to some) "social" need of the continued requirement of @alt
_all-the-time_.  

Making @alt optional "some of the time" is akin to the article's reference
to 'heter mechira':
	"This allowed for a Jew to temporarily “sell” his land to a non-Jew
and to continue farming it during the sabbatical year and then “buy” it back
immediately afterward — a solution that helped the modern state of Israel
keep its agricultural economy humming. ...And so this year, which happens to
be a sabbatical year, the poorest Jews in Israel who wish to eat only food
grown on non-Jewish land are left to buy imported goods at double or triple
the regular price — all in order to uphold a law meant to help feed the
poorest Jews in Israel."

The article actually defends the need to maintain the requirement of @alt
(rather than the rare, 7th year-like instance of the photo upload site that
users send 3,000 holiday pictures to)


> 
> That question is a red herring. The right question is: What do you
> expect a content management system to do when its user uploaded an
> image but did not provide alternative text? And the follow-up: How is
> your answer better that letting the CMS signal to the UA that it
> doesn't have alternative text? (The simplest definition for such
> signaling is the omission of the alt attribute.)

But that only sends half a signal.  Why or why not?  With a reserved value
of _notsupplied, you at least know why/why not, whereas with alt="" or even
no alt value period, the user has *no* information, with no reasonable way
of even attempting to find out.

> 
> Suppose Anne hadn't written his CMS himself and I'm selling Anne a CMS
> that I develop. What should I program the system to do when Anne
> doesn't supply alternative text? (Also suppose that I still want to
> extract a licensing or consulting fee from him.)

Default to a reserved value.  "_not supplied" might not be attractive, but
it is accurate, and given that you are a smart fellow, your CMS will make it
very simple for Anne or anyone else to provide better alternative text
anyway.  How "good" it will be may be open to debate, but at least you as a
software developer have provided the means - the seatbelt of earlier - and
most likely the blinking dashboard light too.  Remember, it won't just be
*your* CMS that needs to deal with this issue, it will be *ALL* CMSes, as
the mandate to provide @alt is neither user-agent nor authoring tool
specific - it cuts across all.

> 
> What incentive does the developer of the conduit have to block what
> you call sewage? Is that incentive stronger than whatever incentive
> there is to let the "sewage" pass through?

OK, Henri, I'll just toss my garbage out the window of my car... I mean, why
not - there already is a ton of garbage on the roadside anyway.  To quote
Arlo Guthrie:

"...we had never heard of a dump closed on Thanksgiving before, and with
tears in our eyes we drove off into the sunset looking for another place to
put the garbage.

We didn't find one. Until we came to a side road, and off the side of the
side road there was another fifteen foot cliff and at the bottom of the
cliff there was another pile of garbage. And we decided that one big pile is
better than two little piles, and rather than bring that one up we decided
to throw our's down."

(Great logic huh? For those unfamiliar with this ode, Arlo gets arrested for
doing this)

The "incentive" is doing the right thing, of building a better mouse-trap,
of being both clever and smart (not always mutual)

> 
> How is alt='_notsupplied' better than defining the absence of the
> attribute to mean exactly what you would define alt='_notsupplied' to
> mean?
> 
> How is alt='_decorative' better than defining alt='' to mean exactly
> what you would define alt='_decorative' to mean?

Do I really need to explain reserved values to you?  The whole point is that
as "reserved" values, the *USER* can consistently define and have their
user-agent announce/process it as whatever they want it to mean, and it will
be consistent.  Decorative is pretty self explanatory, whereas ' ' means
what, exactly?

Because _notsupplied means something, whereas _________ means just that -
nothing - and further, no-one save the author him/herself has any idea of
the intent of the image.  With a common "" (null value) there is *NO*
information supplied, whereas with reserved values there is some information
provided.

> 
> Ah. This is how it is supposed to be better.

Agreed it is marginally better, but yes, in fact.  Providing *NO
INFORMATION* is the worst of any/all possibilities.

> 
> Frankly, I think you are now at the point where you are vehemently
> clinging onto a bad policy and amending it with worse and worse
> additional rules in order to avoid re-examining whether the need of
> the amendments should be taken as an indication that the base policy
> needs adjustment. I don't know a name for this phenomenon, but others
> shouldn't play along to save you from re-examining the policy.

Well Henri, you are entitled to your opinion, but the fact of the matter is
that others *are* chiming in and arguing against a bad decision (in our
opinions) re @alt being optional.  Some even support my idea:

Christophe Strobbe wrote:
> 
> If HTML 5 were to specify certain values (e.g. "_notsupplied" and
> "_decorative") that would need to be used when real text alternative
> cannot be provided (as John Foliot proposed at
> <http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0094.html> and
> <http://lists.w3.org/Archives/Public/public-html/2008Apr/0289.html>),
> these values could be a technique to meet the last item of success
> criterion 1.1 of WCAG 2.0
> (<http://www.w3.org/TR/2007/WD-WCAG20-20071211/#text-equiv-all> in
> the current draft):
> "If it [= non-text content] is pure decoration, or used only for
> visual formatting, or if it is not presented to users, then it is
> implemented in a way that it can be ignored by assistive technology."
> 
> This would not "require the impossible". It would allow us to keep
> the alt attribute as a required attribute in HTML 5, and allow sites
> with file upload functions to meet success criterion 1.1 of WCAG 2.0.

... while others are seeking guidance from other W3C working groups:

[conf] wrote:
> I think that the AUWG and UAWG folks are the experts in this area who
> could provide real insight to this possible solution or another like
> it. We need to ask them for their advice.

Now I don't claim to have a lock on the right answer, however I have put
forward proposals (that I believe are constructive in nature) that
potentially enhance @alt at the same time allowing to continue to insist
that @alt be mandatory.  You just keep arguing that we are wrong.


> 
> As for making laws that people break, it is corrosive (to use Lessig's
> vocabulary) to society to have laws that normal people are in
> violation of in their daily lives. This is why prohibition and laws
> like the DMCA/EUCD are bad as they turn normal people into law-
> breakers and makes them really cynical about law in general thereby
> devaluing laws in general.
> 
> Likewise, a validity rule that normal Web developers would game in
> their daily development activities devalues validator messages.

But what exactly are you trying to test for?  Pixel pushing or information
conveyance?  If all you want to do is push pixels, you are missing so much
of the big picture as to be frightening.


> 
> An HTML5 validator isn't an accessibility evaluation tool--or at least
> I think it shouldn't be. An HTML5 validator is just a spell checker
> for the benefit of markup writers so that they can identify typos and
> typo-like mistakes instead of having to figure out why a counter-
> intuitive error handling mechanism kicks in when they test in
> browsers. A spell checker doesn't tell you if your fiction writing is
> entertaining or non-fiction actually factual. Those are different
> evaluation axes.

Most good spell checkers also offer proposed alternative spellings - they
aren't just reactive, they are proactive.  So an evaluator that sniffs a
graphic with no alt value should suggest some form of repair (just like most
spell checkers), rather than just say oops, you made a mistake (or the even
easier - hey, it's allowed).  It has nothing to do with fiction or
non-fiction, but rather to do with rite/write/right.

JF

Received on Monday, 14 April 2008 23:24:33 UTC