Re: [html4all] HTML5 Alternative Text, and Authoring Tools

On May 12, 2008, at 20:46, Matt Morgan-May wrote:

> On 5/10/08 4:38 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>> On May 5, 2008, at 21:56 , Matt Morgan-May wrote:
>>> Nobody is asking you to make the impossible possible.
>>>
>>> But even in the case where a user with a disability can't work with
>>> a given
>>> URI, there's nothing that says they can't put alt text on an image.
>>> Even if
>>> it's machine-generated, you can at least provide enough context to  
>>> be
>>> somewhat useful.
>>
>> In the case of the Validator.nu image report, what alt text I could
>> provide that added usefulness on top of the other UI text already
>> making it clear that the purpose of the tool is that a human reviews
>> the images?
>
> I hope you appreciate the irony of using the edge case of a tool  
> intended to
> improve the state of alt text as an excuse to make alt text itself  
> optional.

My point is to show that there are legitimate uses of HTML that cannot  
accessible by everyone. Thus, we should not pretend that all uses of  
HTML can be accessible by everyone.

It seems to me that there's a disconnect due to failing to state the  
following explicitly:
For every use case that the HTML WG wishes to support, there must be  
at least one syntactically correct way of addressing the use case.  
Otherwise, by definition, the use case isn't being supported. Thus,  
making things syntactically allowed doesn't require showing that the  
use case for the syntax is *common*. It only requires showing that  
there is at least *one* use case that the HTML WG wishes to support in  
order for the syntax definition having to allow syntax for that use  
case.

Put the other way, if the WG doesn't provide syntax for a use case,  
the WG is saying that the use case should not exist or that the use  
case is so insignificant that the WG isn't bothering to develop  
language features for it.

The irony I'm seeing is that you seem to willing to exclude a tool  
intended to improve the state of alt text from the universe of use  
cases that HTML supports.

If we find that we want to support use cases that aren't accessible  
for everyone, we have to decouple the accessibility evaluation axis  
from the syntactic correctness evaluation axis.

I think making Web resources accessible is a good thing. However, I  
don't agree with defining useful but inaccessible Web resources out of  
existence in order to make a complex thing appear simpler.

> To answer your question, if the image has @alt, there's no reason  
> not to use
> the @alt that it has. (After all, the alt text printed alongside the  
> image
> is actually an alternate rendering for the benefit of people whose UA
> doesn't read it to them by default.)

How would that be beneficial when the data is already juxtaposed with  
the image? How would a person who cannot compare the images and the  
text but who for some reason is using a non-graphical rendering to  
navigate through the Image Report be helped by having to wade through  
redundant data?

> If the @alt is missing, "no alt text found" would be sufficient.

This would be redundant with the nearest heading.

> If you want to improve the state of accessibility overall in HTML5,  
> you
> should add an attribute to img for the case you're describing. That  
> way,
> evaluation tools would know whether the omission was intentional or
> accidental,

How would you address the issue of markup generators just throwing  
that attribute in there to silence validators? I think you are now  
hung up on evaluation *tools* being able to guess intent.

> and we could easily spot bad actors by pulling up all the images
> on a page marked with that attribute and determining whether they
> communicate meaningful information.

The Image Report already pulls all images up for determining whether  
they communicate useful information. If there were a class of images  
that it didn't pull up, wouldn't you expect the problems to  
concentrate into the class of images it was known not to pull up?

>> If a user cannot review the images but still enabled the report (e.g.
>> out of curiosity or by following a link from elsewhere), what alt  
>> text
>> could make the user experience better than the UA's own image  
>> presence
>> indicator?
>
> The UA's own image presence indicator on an image missing @alt is  
> overridden
> by assistive technology, which looks for any other metadata it can  
> find
> about the image, since it regards missing @alt as damage. QED.

Here, I meant the whole thing the user uses to interact with Web  
content when I said "UA". Whether it is browser plus AT or e.g. a  
directly talking browser is an implementation detail.

For example, in the case of Safari+VO on Leopard, the image presence  
indicator is the UA speaking the word "image".

>> Currently, there's one HTML5 validator, so what HTML 5 says about
>> validation is currently only relevant to the behavior of one product.
>> Are you afraid that a new product came along and was worse on the alt
>> point but that authors would use it anyway in preference to
>> Validator.nu for its other qualities?
>
> No, I'm afraid that people who are tired of HTML 4.01 requiring @alt  
> will
> flock to HTML5 since it gives them the freedom to ignore accessibility
> wholesale. And that they'll take those bad practices back with them,  
> and
> further pollute the already murky (X)HTML world.

So you feel not ignoring accessibility hinges on making alt a  
syntactic requirement. What about the rest of WCAG 2.0? Are you  
already giving up on promoting the other issues covered by WCAG 2.0  
while taking what you feel is the most important bit and masquerading  
it as something else?

>> It's also very annoying when people seek to design your product for
>> you when you believe your own design is already superior. For  
>> example,
>> when accessibility advocates keep wanting to move the alt issue into
>> the validation function when I've already implemented the Image  
>> Report.
>
> Or, say, when standards developers strip a critical accessibility  
> feature,
> then suggest -- incredibly -- that users with disabilities rely on
> technology that isn't even close to existing, and demand to know why  
> those
> users should have the old feature back.

You (and others) are writing as if HTML 5 banned the alt attribute. It  
did not ban it.

> Frankly, your validator and its feature aren't the issue, at least  
> as far as
> this thread is concerned. They will do little if anything to improve  
> the
> state of @alt relative to the alt text lost by being optional.

That seems confusing.

It seems to me that your advocacy point is that you want to make the  
presence of the alt attribute a machine-checkable syntax requirement.  
Isn't what you want validators to do precisely the issue then?

If you aren't arguing that my validator should flag the absence of the  
alt attribute as a syntax error, what *are* you arguing?

> We have years of experience to base this on. If you look at any
> accessibility evaluation tool, you'll see that they all emit  
> warnings that
> are ultimately judgment calls on the part of the author. But many if  
> not
> most of those authors drive quickly through those yellow lights,  
> rather than
> stop to evaluate them -- and those are the "good" authors.

The fundamental problem you have is that those authors don't have  
making their Web resources accessible as their goal. They have another  
goal such as:
  * Convincing a government purchaser who him/herself doesn't have a  
relevant disability that a product or service is OK to buy.
  * Convincing management that enough accessibility theater is taking  
place that the risk of a lawsuit or damages in the case of a suit are  
diminished.
  * Seeking to get a PR benefit from Bobby badges among users who  
don't really need the accessibility features but feel good about  
believing that they are there.

Until you can get authors to make accessibility their actual goal,  
it's really hard to help you. However, I think it is crucial that when  
trying to help you in this situation, the interaction of the less  
noble motivations with different validator designs are carefully  
considered.

> An advisory
> message in a validator, however helpful, is not a forcing function  
> in the
> same way a validity constraint is.

A mere presence check doesn't force the value of the attribute to be  
on the better side.

> Anybody who's evaluated a site that's "Bobby-approved" knows that.

If there's anything to learn from Bobby, I think it is that a piece of  
software can't tell if a page is accessible. Furthermore, I think it  
is hurting your cause to suggest to people that software could tell if  
a page is accessible.

>>> So far, I have seen nothing in this thread to convince me that this
>>> path has
>>> any positive outcome for people with disabilities, much less a net-
>>> positive
>>> one.
>>
>> The zero-level is when the author takes no action (no alt).
>
> Unless you have vision problems or certain learning disabilities, in  
> which
> case missing alt is a negative. Do you not understand this? Missing  
> alt
> means missing semantics, which in all cases is a negative outcome  
> for users
> with disabilities.

I said where I placed the zero level in my previous email. I think it  
is natural to place *zero* at "*no* action". Furthermore, placing it  
elsewhere would have been non-sensical in the context where I used  
"positive" and "negative".

You seem to be placing the zero level context-dependently at  
sufficiently accessible for a given person.

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

Received on Tuesday, 13 May 2008 07:48:21 UTC