[html4all] the alt attribute debate
hsivonen at iki.fi
Tue Sep 25 04:36:38 PDT 2007
On Sep 24, 2007, at 15:40, Philip TAYLOR wrote:
> Henri Sivonen wrote:
>> By decoupling syntactic correctness from simplistic machine-
>> assessable accessibility testing, an incentive to pollute the non-
>> visual user experience with bogus alt text is removed.
> Henri, your assertion may well be true, but even as a native
> speaker I find it hard to work out what you are trying
> to say here : could you possibly re-cast your assertion
> into more straightforward language, so that the slower
> amongst us might be able to follow your argument ?
There are two things to check:
1) Is a document syntactically correct?
2) Is a document accessible?
The exact definitions of "syntactically correct" and "accessible" do
not need to be specified for now except for the alt issue.
"Does this image have a textual alternative?" is part of the test "Is
this document accessible?". Merely checking for the presence of the
alt attribute (even with the empty string as the value) is a
simplistic machine-assessable accessibility test. It doesn't tell,
for example, if the alt text is any good. Also, if someone cares
about passing the check but not about actually making pages
accessible, it is easy to fool the machine check by using a bogus
value--any value will do. Hence, "simplistic".
Those who advocate that the check for syntactic correctness should
also contain the test "Does this image have an alt attribute?" want
to couple (simplistic) accessibility testing with syntactic correctness.
For people other than accessibility advocates, #1 and #2 are seen as
different things. Moreover, experience shows that there are people
who want address #1 doing whatever collateral damage it takes. (I
doesn't really matter if you think that other people should see #1
and #2 as the same. They don't, so your strategy should adjust to that.)
Insisting on coupling #1 and #2 makes people who only consider #1 put
in bogus values for the alt attribute. Not coupling #1 and #2 removes
the reason to put in the bogus values.
When a software developer wants to move some bits from one pipe to
another and the second pipe wants something the first pipe doesn't
provide, the software developer *will* fake it with bogus data if (s)
he don't have the required additional data. Every time you insist on
getting some data that the provider doesn't have, you should expect
to get bogus data. Insisting that datum A cannot be communicated
unless it comes together with datum B fails to always leads to datum
B getting faked some of the time if there's value in communicating
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).
Likewise, if one pipe (e.g. digital camera) gives you bitmaps without
textual alternatives and another pipe (the Web) insists on textual
alternatives being present, you can be 100% sure that the person
writing the piece of software that stuffs images from the camera to
the Web will fake the textual alternatives by emitting bogus data.
hsivonen at iki.fi
More information about the List_HTML4all.org