Re: several messages about alt

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:

There is no law of physics or a fundamental result of computer science  
that prevented computers from pushing pixels around without pushing  
around a string at the same time. One group of people (the html4all  
folks) makes a value judgement that people using computers should make  
computers push around a string when they push around pixels in order  
to benefit a second group of people (the blind). A third group of  
people will make a value judgement that pushing pixels around without  
a string is valuable as such and they don't provide the string as  
having to provide a string as well would effectively make their use  
case infeasible (for example, people with camera phones with one- 
button photo taking and immediate uploading to a photo hosting  
service). A fourth group of people (developers of photo hosting  
services) will write software that the third group of people will use.

This fourth group--not the third group--are potential users of  
software I develop: an HTML5 validator. A part of this fourth group  
consists of software engineers who will
  1) write software that is primarily meant for pushing pixels onto  
the Web (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)
  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)

The first group of people wants, based on their value judgment, to  
establish a social norm onto the third group of people against the  
value judgment of this third group. This is a social problem. The norm  
is supposed to benefit the second group of people: the blind. Thus,  
any rational measure of the goodness of the policy should involve  
measuring the actual benefit to this second group.

Now, does the first group take their social norm directly to the  
people whose behavior they want to modify? No.

Instead, they want to masquerade the social norm as a technical norm,  
to use the PFWG as a proxy that tells the HTML WG what to do, so that  
the HTML WG may use the HTML 5 spec as a proxy for influencing the  
behavior HTML5 validators, so that HTML5 validators are turned into  
vehicles of advocacy against the fourth group (developers) in the hope  
that they turn their products into vehicles of advocacy that finally  
reach the people that the first group wants to impose their social  
norm on.

I think that in this process, the relationship between the product I  
develop and its users is harmed, because the product  then is no  
longer a tool working for its users but a vehicle of advocacy for  
someone else. This is one reason why I care. Furthermore, I think  
complaining about missing alt to developers whose software *simply  
doesn't have that data* because the third group of people didn't  
provide it causes developers to either ignore the validator (not what  
I want) or faking the data they don't have (bad for the supposed  
beneficiaries of the policy).

I even agree that it would be nice if all photos had alternative text.  
But I don't think it is realistic, and I don't want to internalize the  
fallout that the first group externalizes by making the product I  
develop part of a long proxy chain instead of taking their issue  
directly to the people they want to influence (the people with camera  
phones in this example).

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. (Consider the examples Julian gave:
http://lists.w3.org/Archives/Public/public-html/2008Apr/0314.html ) If  
the harm in this case defies the obvious, I think the obvious needs to  
be proven wrong by research. Furthermore, the alleged benefits of the  
policy are speculative--that the policy of requiring alt syntactically  
would make more people supply useful alt text than telling people that  
a good alt text is needed for accessibility. With the harm side  
obvious and the benefit side speculative, I think the policy shouldn't  
be adopted without empirical research showing that the benefit exceeds  
the harm as perceived by the supposed beneficiaries. If research shows  
that there indeed would be a net benefit for the blind, then we can  
weigh if that net benefit is so great that it justifies collateral  
damage (e.g. turning some potential users away from validators).

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. 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=1358485200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all&oref=slogin

On Apr 11, 2008, at 13:08, Charles McCathieNevile wrote:
> On Fri, 11 Apr 2008 11:29:20 +0200, Henri Sivonen <hsivonen@iki.fi>  
> wrote:
>> Saying that such products should be
>> programmed to output invalid HTML isn't a viable answer, either.
>
> Why not? Almost *every* tool I know of that produces HTML produces  
> invalid
> HTML, so I am not sure how you determine that there is some  
> existential
> reason why this cannot happen.

We are talking about defining what's valid. The validity definition  
doesn't matter for people who don't even want the tools they write to  
output valid HTML. Therefore, it is only relevant to consider people  
who might care about the validity of the output of their products.

On Apr 11, 2008, at 15:05, Steven Faulkner wrote:
> Two images without explicitly associated text alternatives.
> 1 is an image is decorative that the author has accidently left off
> the alt, the other is "critical content" that the author could not
> provide an alt for whatever reason
> 1 can be safely ignored, the other should be brought to the attention
> of the user.
>
> <img src="abc.jpg">
>
> <img src="xyz.jpg">
>
> How is Assistive Technology  supposed to reliably determine this?
> Given that these two images could be the same, but their meaning
> differ widely depending on the intent of the author in regards to
> their use.

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

On Apr 11, 2008, at 20:34, Dave Singer wrote:
> I gave an anecdote before about an installer program that insisted  
> on text strings to describe optional installs.  Many, many packages  
> came configured offering, say "the frotz option" and if I asked for  
> the "alt" I would get the text "this installs the frotz option".  If  
> the installer *knew* that there was no explanation, it might be able  
> to say "this installs a background process with root privilege, and  
> a plug-in to the mail program" and I might be a little more informed.

Indeed. A software developer with an output spec and insufficient  
input where the input can satisfy the main objective of his/her  
software *will* fake the missing data to match the output spec as far  
a computer can tell. That's how software developers behave.

Here's my earlier example:
"For example, if you are a kernel developer and you are copying files
from a file system that doesn't record the creation dates of files to
another file system that insists that every file *must* have a
creation date, you don't tell your boss/customers/whatever that you
can't copy the files. Instead, you fake the creation date (the
current time from the clock, the start of the epoch, whatever)."

> Similarly, a web agent given an image with no alt might be able to  
> indicate the size of the picture, and there is plenty of evidence to  
> suggest that in time it could do image analysis and work out that  
> there is a person, it's a landscape, and so on.  If the alt text is  
> provided but worthless, it would obscure this capability.


Indeed.

On Apr 11, 2008, at 23:07, Matt Morgan-May wrote:
> We know from over 10 years of experience that authors are going to  
> lie.

Does inducing authors to lie benefit the stated beneficiaries of your  
policy?

> You cannot turn one of the most common validity and accessibility  
> failures
> on its head simply because an empty alt attribute is unattractive.

The empty string as the value and the absence of the attribute signal  
different things. Making both cases the same is information loss.

On Apr 11, 2008, at 23:15, John Foliot wrote:
> I need
> only quote one of the HTML5 Working Groups' personal blogs to  
> illustrate
> this fear:
>
> 	"I am currently following HTML5 (omitting alt) as it wasn't really
> clear to me what would be a better solution given the single  
> constrain I
> have: not finding it necessary to provide replacement text for all  
> those
> images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not  
> "find
> it necessary" - not that he could not, nor that the image was an Ink  
> blot
> test that providing alternative text to would invalidate (the two  
> scenarios
> suggested in the draft spec), but simply that he did not find it  
> necessary.
> The fear is very real!

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

> Henri Sivonen wrote:
>> A piece of software gets images from somewhere and puts them
>> automatically out on the Web. What should the developer of that piece
>> of software program it to do when an image arrives from whatever pipe
>> they arrive from without alternative text? How do you require a
>> program to emit something it simply doesn't have without faking it
>> with junk?
>
> If sewage passes through a conduit, should the conduit do nothing,  
> or at the
> very least attempt to filter out the larger pieces of sewage?

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?

> Henri S. used the word "fake", but that is undefined.  This once again
> points to the need (IMHO) for one or more reserved values that user  
> agents
> can "standardize" on (remember, this *IS* about standards) that  
> address
> possible scenarios when content authors fail to, or cannot, provide
> appropriate alternative text.  "_notsupplied"

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

> and "_decorative" are two that
> instantly come to mind.

How is alt='_decorative' better than defining alt='' to mean exactly  
what you would define alt='_decorative' to mean?

> "_notsupplied" has the added benefit
> (IMHO) of also applying a subtle but real social pressure on content
> contributors to do something, but if they choose to ignore that  
> pressure,
> then the default of "_notsupplied" still allows compliancy, whilst  
> still
> retaining the mandated need for alt values for all non-textual  
> content.

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

Thus you want someone other than you to apply the pressure to someone  
other than whom you seek to apply the pressure to. And you want to do  
it by making the syntax cruftier.

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.

On Apr 11, 2008, at 23:18, Bonner, Matt (IPG) wrote:
> Are there any usability studies or tests done by screen
> reader software companies that could help resolve this
> debate?

Excellent point!

On Apr 11, 2008, at 23:54, Katie Haritos-Shea wrote:
> People will continue to commit crimes and break the law........but  
> it that a reason not to have them?


First, HTML 5 is not law, and I don't want an HTML5 validator to have  
anything to do with legal proceedings.

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.

On Apr 12, 2008, at 01:24, Matt Morgan-May wrote:
> If you allow alt to become optional in order to satisfy user-uploaded
> content requirements, then accessibility evaluation and repair tools  
> have no
> way of knowing whether you omitted it purposely, or out of ignorance.

We are talking about what HTML5 validators are to say. We aren't  
talking about accessibility evaluation tools. WCAG is free to be  
normative about those.

However, I think accessibility evaluation tools make people write for  
the tools instead writing for accessibility. That's why accessibility  
should be evaluated by people.

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.

> You can define the exception case that warrants a missing alt  
> attribute as
> narrowly as you like in the spec, but you know as well as I do that  
> people
> aren't going to read the spec for guidance at that level, if they  
> read it at
> all.

FWIW, Validator.nu doesn't flag PUA characters as errors even though  
they are prohibited most of the time, since there's also a narrow  
legitimate use. It does give a one-time warning, though.

> Further, I think that while user-generated content is a popular  
> category of
> web content, it's just one such category, and since there are any  
> number of
> other kinds of content for which no such exception should exist,  
> there's no
> justification to turn the rules around on alt solely for the benefit  
> of
> those sites.

The syntax rules need to be lax enough for all kinds of sites to be  
able to comply. If all sites can't be accessible, too, then  
accessibility and syntactic correctness are different evaluation axes.

On Apr 13, 2008, at 03:35, Leif Halvard Silli wrote:
> In this regard, I proposed [1] - as an replacement for the current  
> "WYSIWYG made" stamp - a new "unready" stamp, which all authors -  
> couples, and blind - and all editing tools - could use, when they  
> need to offer HTML which they consider technically unready.

Alternatively, we could call "unready" valid HTML5 and "better than  
unready" valid HTML5 with WCAG compliance. We don't have to conflate  
accessibility evaluation with the syntactic correctness.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 13 April 2008 08:55:53 UTC