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

On 5/13/08 12:47 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
> On May 12, 2008, at 20:46, Matt Morgan-May wrote:
> 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.

And later:
> 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.

Ah. I think this is one misunderstanding. _No_ content, HTML or other, can
be perceived, operated, and understood by every person everywhere. (Human
consumers of HTML content remain frustratingly analog in this respect.)
There is no bright line where this is Accessible with a capital A, and that
is not. We don't assume otherwise. What we do aim for in each situation is a
case where the largest number of users possible can access the greatest
amount of content most easily.

Under no circumstances, however, is it acceptable to throw up one's hands
and say, oh well, they can't make this HTML accessible anyway. _Especially_
not at the language level.

In the case of @alt, we recognize that many applications of alt text are
degradations from the original image. But we don't expect an expert analysis
of Mona Lisa's intriguing smile whenever someone puts up a photo of the Mona
Lisa. We require enough information to make sense of the semantics provided
by the image, in the context of its surrounding document. For all content on
the web, such information is available, and however degraded it may be, it
still improves the overall accessibility of the document. I strongly
disagree with the line of reasoning that there are use cases where @alt is
in some way unnecessary or damaging to the extent that it should be
optional.

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

I've already offered two solutions to this: one in the form of how it's done
today, which is at worst redundant but still inoffensive; the other in the
form of @noalt.  

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

Since when is parsing semantic code "guessing"?

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

The image report _should_ pull up all images with @noalt in order for a
human user to determine whether the images marked that way are in fact
impossible to produce @alt for. It's not a get out of jail free pass.

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

Whether the UA is defined with or without AT is immaterial. AT regards
missing @alt as damaged content.

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

Why the focus on VoiceOver? Because it comes with every Mac? The vast
majority of people who require screen readers are using one of a handful of
Windows-based screen readers (JAWS, HAL, Window-Eyes, etc.), each of which
is years ahead of VO as far as HTML is concerned. (Yes, I have all of them
installed, including VO.) Those users expect and receive better information
than VO provides. When @alt is missing, they go scrounging for repair data,
as they should -- as the "agent" of the "user".

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

As I said before, this is only the most egregious example of accessibility
taking a back seat in HTML5. And I have no idea where you get the idea I'd
throw the rest of WCAG 2 under the bus just to get @alt back. That doesn't
mean any accessibility-related feature brought on by WCAG 2 would need to be
mandatory. But of the features that aren't already required for other
reasons in HTML, @alt is the only one I can think of that is always
potentially beneficial when present, and always damaging to accessibility
when missing.

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

That's a little hyperbolic, don't you think? We're bringing this up because
it's a substantial issue, not simply to annoy you. Anyway, I trust that
nobody would even suggest banning @alt, because the resulting backlash would
make this thread look like a New Year's Eve party.

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

My argument is about why @alt must be required. My problem right now is with
the letter of the law, not how you propose to police it.

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

At the atomic level, no. But you cannot argue that requiring @alt per spec
in HTML has not resulted in more useful alt text on the web than there would
have been had it been optional. Which is directly in line with my stated
goal at the top of making more content more accessible to more people.

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

That's precisely my point. And I didn't suggest that, at all. Quite the
opposite, in fact. The problem is that your approach is fundamentally no
different from Bobby's, and given the relatively low success rate of casual
Bobby users to make arbitrary HTML content more accessible, the idea of
taking the constraint out of the spec and relying on your image report for
conformance does not comfort me in the least.

-
m

Received on Tuesday, 13 May 2008 17:53:38 UTC