[html4all] several messages about alt
hsivonen at iki.fi
Sun Apr 13 01:55:05 PDT 2008
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
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:
On Apr 11, 2008, at 13:08, Charles McCathieNevile wrote:
> On Fri, 11 Apr 2008 11:29:20 +0200, Henri Sivonen <hsivonen at iki.fi>
>> 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
> HTML, so I am not sure how you determine that there is some
> 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.
On Apr 11, 2008, at 23:07, Matt Morgan-May wrote:
> We know from over 10 years of experience that authors are going to
Does inducing authors to lie benefit the stated beneficiaries of your
> You cannot turn one of the most common validity and accessibility
> 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
> 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
> images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not
> it necessary" - not that he could not, nor that the image was an Ink
> test that providing alternative text to would invalidate (the two
> suggested in the draft spec), but simply that he did not find it
> 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
> can "standardize" on (remember, this *IS* about standards) that
> 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
> 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
> then the default of "_notsupplied" still allows compliancy, whilst
> retaining the mandated need for alt values for all non-textual
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
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
> 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
> aren't going to read the spec for guidance at that level, if they
> read it at
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
> 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  - 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.
hsivonen at iki.fi
More information about the List_HTML4all.org