Re: [html4all] the alt attribute debate

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.



Epilog:
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  
datum A.

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.

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

Received on Tuesday, 25 September 2007 11:36:53 UTC