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.fihttp://hsivonen.iki.fi/