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

On May 5, 2008, at 21:56 , Matt Morgan-May wrote:

> On 5/3/08 2:31 PM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>> An aside on the topic of WCAG 2.0 (not a response to what you said):
>>
>> With WCAG 2.0 the W3C offers a notion of conformance on the
>> accessibility evaluation axis. I'm curious why accessibility  
>> advocates
>> want to bake some of that into the notion of conformance on the axis
>> of machine-checkable HTML5 syntax instead of promoting conformance on
>> the accessibility evaluation axis on its own right.
>
> You're hung up on machine validation.

Am I? I've been telling people that as a developer of machine  
validation I recognize that checking the quality of the alt text is  
not something my product can do and we shouldn't pretend that checking  
for its presence means checking that there's something with positive  
usefulness.

> 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?

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?

>> As a practical matter, at this
>> point the market-leading HTML5 validator is addressing the
>> *accessibility* issue, so the need to make it into a *syntax* issue  
>> is
>> greatly reduced if not completely removed.
>
> I think you're confusing the map with the territory.
>
> What you say is true _if_ all of the web uses validator.nu. But  
> let's be
> realistic. What percentage of all static HTML documents on the web  
> do you
> suppose have gone through the current HTML validator? I think 2%  
> would be a
> very generous guess. And that's only a fraction of all web content.

The part of the Web that is authored without using any validator is  
completely irrelevant to the discussion of what validators should do.

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?

>> Compared to making it into a syntax issue, the UI of the Image Report
>> is carefully designed to avoid the downsides of making it a syntax
>> issue: The Image Report always lists *all* <img> elements of the  
>> input
>> page. There is no way to make the list shorter (without removing
>> images). This means that there's no bogus value that an author could
>> include in order to make the report look shorter/cleaner.
>>
>> I don't want to even add warnings to the *syntax* check report,
>> because it would reintroduce the problem of authors seeking to make
>> the report look shorter by including bogus data.
>
> I have to object to this line of reasoning. You're trying to solve a  
> problem
> that I don't believe the accessibility community has asked you to  
> solve, or
> even stated as a significant problem. Has there been a surge in  
> requests
> that I'm not aware of, asking the HTML WG to deliver people from  
> bogus alt
> text? If not, could you kindly stop using it as a rationale?

It's indeed very annoying when people seek to solve a problem they  
think you have for you. For example, it's annoying when armchair  
semanticists seek to solve problems that can search engine developers  
are already solving better in other ways.

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.

I don't want my product to induce ill effects. I'm honest about how  
I've reacted and seen others react to previous validators that put the  
presence of alt in the validation function, and with that experience,  
I've designed Validator.nu not to create the bad effects of that  
situation. As for whether there is such a thing as bad alt text, when  
you look at what accessibility advocates write outside this thread, it  
reveals that they think there is such a thing as bad alt text to the  
point of them finding it worthwhile to write guides of how to write  
alt text that isn't bad.

>>> You are leaving out the authors who don't care about accessibility
>>> before
>>> they are nagged, but yet do the right thing when nagged.
>>>
>>> Not everyone who discovers @alt via a conformance check stuffs
>>> garbage in the
>>> attribute.
>>
>> That's what I was referring to when I said "In all likelihood, it  
>> will
>> also lop off *some* of the good effects."
>
> That's the thing. You're talking about one of the _primary_ positive
> effects.
>
> Most books on HTML don't talk about any of a number of optional  
> attributes.
> Or anything about accessible HTML, _except_ @alt. But most of them do
> reasonably well describing what @alt is good for, because it's a  
> required
> part of the syntax of img. We don't get very many wins in  
> accessibility that
> have been as helpful as a required @alt.

I don't buy the book argument at all. Books cover attributes that are  
not syntactically required in all cases. I also strongly disagree that  
the common uses of my product should be deteriorated in order to  
remind book authors about stuff that could be communicated to them in  
other ways (like through notes in the spec assuming the book authors  
aren't complete quacks and at least skim the spec).

>> I am putting forward an argument that the net effect will be on the
>> positive side even if we don't seek to gain some unknown magnitude of
>> incremental positiveness in a way that is known to incur an unknown
>> magnitude of collateral negativeness.
>
> 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). The  
negative side is when the alt makes the user experience worse. The  
positive side is when the alt makes the user experience better.

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

Received on Saturday, 10 May 2008 11:38:55 UTC