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

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. The problem is that while being
parsable is of course important, the payload of an HTML document is intended
for human readers, and no manner of machine-generated or -parsed code will
change that. In light of this fact, it is necessary for HTML5 to ensure that
semantics communicated to one group of users (or one class of UAs) can be
understood by all of them. It's graceful degradation.

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

We are not trying to ride HTML5's coattails. What we _are_ trying to do is
to protect a feature of HTML which directly improves the experience of users
with disabilities, today.

To the extent that validity is a useful carrot to hold out in order to gain
accessibility, and that in the default case it does in fact help, and given
that this has no impact on user agent implementation, where it is already
universal, or on current practice, I see no logical purpose to removing it.

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

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.

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

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

-
m

Received on Monday, 5 May 2008 18:57:09 UTC