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

On May 3, 2008, at 22:43 , Al Gilman wrote:

> On 3 May 2008, at 5:37 AM, Henri Sivonen wrote:
>
>> On May 2, 2008, at 17:42 , Julian Reschke wrote:
>>
>>> In doubt, the default should be not to change HTML4.
>>
>>
>> FWIW, I have a different view of what to do when in doubt:
>>
>> When in doubt, do what doesn't cause harm.
>>
>> I think experience (yes, not written down quantitatively) with  
>> HTML4 validation shows that casting an *accessibility* requirement  
>> into a simplistic presence/absence *syntax* requirement does both  
>> good (reminds some people to provide useful alt who somehow  
>> wouldn't otherwise) and harm (induces people to pollute non- 
>> graphical presentation with duplicate data, useless data like  
>> "image" or make the context less understandable by concealing the  
>> presence of images).
>
> Can you take the following re-statements as a 'yes'?
>
>> Syntactic presence of @alt on <img> is not a sufficient technique  
>> for meeting
>> WCAG 2.0 Success Criterion 1.1.1.
>
>
>> Approximating the accessibility requirements for a text alternate  
>> with a syntactic
>> requirement for @alt to be present can lead to erroneous practice.

I think I agree with those statements.


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.

So far, I've come up with two possible explanations:

  1) It's about assuming that a notion of "Valid HTML5" is more  
appealing/marketable than a notion of "A[A][A] level conformance to  
WCAG 2.0". If this is it and such assumption were correct, wouldn't it  
mean that there'd be people who'd seek to satisfy a validator without  
necessarily doing good to accessibility in the process (and,  
therefore, we should be careful to avoid inducing that kind of  
behavior)?

  2) The notion that a document could be deemed "correct" on *some*  
evaluation axis without *also* being accessible is somehow offensive.  
If this is it, I think it isn't productive to deny non-accessibility  
evaluation axes to use cases that aren't accessible to everyone, since  
there are legitimate use cases in the universe of possible Web pages  
that aren't accessible to everyone. For example, the Image Report  
feature of Validator.nu is by its very nature itself not accessible to  
a person who can't compare images and text.

Is either of these on the mark or is there something else that I'm not  
realizing?

>> I believe the current design in HTML 5 and Validator.nu's Image  
>> Report feature will pretty much remove the bad effects of requiring  
>> alt for validation.
>
> Two ideas:
>
> 1) Are you suggesting that HTML5 adopt some sort of a requirement or  
> other
> endorsement of Validator.nu's Image Report feature?

I'm not suggesting that. I am, however, suggesting that having the  
feature in the market-leading HTML5 validator should alleviate the  
concern that not making alt presence a machine-checkable *syntax*  
requirement somehow made the *accessibility* issue lose prominence. In  
fact, Validator.nu gives the alt issue more prominence than HTML 4  
validators ever have.

As a matter of *principle*, I think HTML 5 shouldn't *require* HTML5  
validators to have particular additional features in addition to the  
HTML 5 validation function (i.e. deciding if the input meet machine- 
checkable syntax requirements), since the additional features beyond  
strict interoperability of the validation function should be an area  
where implementations are allowed to innovate and compete.

As a practical matter, though, I wouldn't object to HTML 5 requiring  
or recommending HTML5 validators to have features that I've already  
implemented. Also, I wouldn't object to accessibility advocates  
objecting to any product or service that tried to compete with  
Validator.nu without having a similar feature. :-)

> This is expressly
> excluded from the job of a conformance checker in the current TR draft
> of HTML5.
>
> http://www.w3.org/TR/html5/#conformance

Indeed, in Validator.nu, the Image Report is not part of the HTML5  
validation function. The outcome of the validation function is  
computable. The Image Report doesn't give a computed yay or nay.  
Instead, it presents information to help a human make assessments.

> 2) It would seem to me that the value added by Validator.nu's Image  
> Report
> feature is insensitive to whether @alt is required or not required.
> It reduces the criticality of the question, but does not bias the  
> answer
> one way or the other.

I think it is sensitive to the issue. 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.

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.

>> Thus, if we consider some kind of indifferent zero level of  
>> aggregate goodness/badness, it removes the negative side, so other  
>> things can only leave the aggregate positive or to the zero level.
>>
>> In all likelihood, it will also lop off *some* of the good effects.  
>> Still, it seems totally implausible that people who provide alt  
>> because they care about accessibility would suddenly stop if it  
>> weren't a machine-checkable *syntax* requirement. Hence, it seems  
>> plausible that the aggregate effect will remain on the positive side.
>
> 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."

To mitigate the problem of lopping off some good effects, Validator.nu  
gives the alt issue more prominence than HTML 4 validators ever have:  
The HTML5 facet of Validator.nu gives one third of its UI input real  
estate to the image report feature (one out of three changeable input  
widgets) and the report about alt values is way more thorough than  
just flagging absence.

>> Taking a course of action that has both good and bad effects on top  
>> of a net-positive aggregate baseline means seeking to do some good  
>> while accepting collateral damage of the bad side. I think a course  
>> of action with collateral damage should be based on data about the  
>> aggregate delta effect of the course of action remaining positive.
>>
>> We don't have data about that, so defaulting to removing the  
>> negative side without knowing the magnitude of either makes sense.
>
> Except that your argument that we are removing only negative is  
> debatable,
> not prima_facie convincing.

I am not putting forward an argument claiming to remove only the  
negative. ("In all likelihood, it will also lop off *some* of the good  
effects.")

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.

> What seems to be broadly agreeable is that Validator.nu's Image  
> Report adds significant
> value to the authoring process.  But the HTML5 draft currently  
> disowns this value.

I think the practical value isn't removed even if HTML 5 "disowns" it,  
but I'd be OK with the spec acknowledging it.

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

Received on Saturday, 3 May 2008 21:31:53 UTC