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

It should be abundantly clear though that we are talking about an attribute 
"alt", which has wide implications beyond disability.

----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: "Matt Morgan-May" <mattmay@adobe.com>
Cc: "HTML Working Group" <public-html@w3.org>; "W3C WAI-XTECH" 
<wai-xtech@w3.org>
Sent: Wednesday, May 14, 2008 10:22 AM
Subject: Re: [html4all] HTML5 Alternative Text, and Authoring Tools



On May 13, 2008, at 20:52, Matt Morgan-May wrote:

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

Right. So if we agree that accessibility in some cases fail, let's not
define those cases out of syntactically correct existence and let's
not incite those cases to fail harder than necessary.

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

I thought you just said that there are going to be cases that aren't
going to be accessible for everyone. To me that suggests that it's
part of the universe of HTML use cases anyway.

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

Sure, in pretty much every case an alt text *could* be written if
there were someone willing to write it. But in reality, there are
cases where alt text *won't* be written, and we should consider how to
avoid making those cases even worse than leaving alt unwritten.

As a contrived scenario, Validator.nu *could* defer its responses for
a couple of days and delegate alt writing (or checking at that point)
to Amazon's Mechanical Turk during that time. Of course, I'm not going
to do that, because I *value* and expect my users to value an
expedient and inexpensive response over a more accessible and
expensive one. (Oh, and BTW, Mechanical Turk seems like a case where
images are embedded in HTML without the software knowing what they
are...)

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

To me, it seems obvious from non-contrived cases that it's possible to
have alt text that is worse than not having alt text *if* UAs handle
altless images reasonably gracefully (i.e. don't render the file name
when it's unwieldy). Examples:
  * Putting a numeric file name, or worse path, into alt. (Ironically,
the most persuasive reason for putting alt="image" or alt="" or
something like that in the Validator.nu Image Report is to suppress
file name rendering in *some* UAs that use the file name as an awful
alt surrogate!)
  * Putting an empty-string alt on an image whose presence is
important for comprehending surrounding text.
  * Putting alt="image" on an image when the UA would by itself render
the word "image" or "graphic" as chrome.

You are saying than none of these are damaging to the *extent* that we
should seek to avoid these. What I don't understand, however, is why
wouldn't we try to eliminate these cases if they are *damaging* to
*some* extent--especially if we find we can do the elimination without
causing worse damage.

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

Why shouldn't we remove the redundant stuff if we find we can?

> the other in the form of @noalt.

It seems to me that the @noalt proposal doesn't solve any
accessibility problem: there's still no alt when there's no alt. All
it seems to do is to create more syntactic error situations.
Accessibility advocates seem to be really keen to create error
situations in this area, but I'm not convinced that creating more
syntactic error situations is helpful, since markup generators can
paper over those cases without actually addressing the accessibility
issue. Instead, I do think that offering text alternatives for review
like the Image Report does is helpful.

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

Markup generators written by people who think the way software
developers tend to think will produce syntactically correct data
streams even when the user did not cooperate. In such a case, any
omission will be flagged as intentional if you that's the only
syntactically correct way to flag an omission.

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

So if all the images need to appear in the report anyway, what
usefulness would @noalt add?

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

It's an example of real software that fits the assumptions the HTML 5
draft makes about what non-visual browsers should be like and that I
happen to have readily available for testing.

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

I strongly disagree with the notion of accessibility taking a back
seat in HTML5. The approach HTML5 takes is to avoid accessibility
features that require dual authoring for different content consumption
modes (e.g. visual and aural). The best accessibility features are
ones that enable accessibility without requiring authors to take a
specific accessibility action. (For example, <progress> is designed to
work for all content consumption modes when authored once whereas the
ARIA approach requires building the widget from lower-level parts
twice.)

In the case of images, we are stuck with dual authoring, because
making images accessible without dual authoring is an unsolved problem.

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

I get it from the notion that alt not being syntactically required in
HTML 5 would give 'freedom to ignore accessibility'. That implies that
WGAC gets ignored anyway.

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

The thing is, it can be damaging (I'm not speculating to what
*extent*) to accessibility when present with a bad value.

The presence of alt is a prerequisite for accessibility (for people
with certain types of disabilities), but it does not follow from that
observation that *any* alt value is an improvement over not having it.

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

No, I think it characterizes pretty well what many emails to this
thread and related threads read like.

> We're bringing this up because it's a substantial issue, not simply
> to annoy you.

I'm not bringing this up to annoy you, either. My problem is that I
care about the effects that my product induces and I want it to do
good and not induce bad effects. I take no joy (quite the opposite) in
arguing about this and if this thread didn't directly affect the
quality of my product, I'd walk away from this thread in a heartbeat
and use this time for writing better software instead of writing email.

The reason why I'm not just taking your expert word on this is that
while I do believe that accessibility advocates are good at
identifying accessibility problems, I frankly don't really trust the
ability of accessibility advocates to formulate *syntactic*
requirements in such a way that the requirements don't induce unwanted
effects when exposed in a machine checker to potentially uninformed
users or to users who don't share the goals of the accessibility
advocates.

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

If you are arguing that you want to make a piece of syntax machine-
checkably required, it seems to me that the effect such a requirement
will have when people use software that checks for the requirement is
at the very center of evaluating whether the requirement is a good idea.

Setting a policy without considering what its effect on the stated
goal is is very bad policy setting.

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

I think we don't have data about that.

The Image Report is carefully designed to remove bad effects of
putting an alt presence check in the validation function while at the
same time making the feature more useful than a mere presence check to
people whose actual goal is to make images accessible.

The interesting question is what effect the Image Report has on people
aren't trying to make their pages accessible but who upon a presence
check failing would happen to write better-than-nothing alt text by
dumb luck. How will those people behave when they find a tool where
they can enable something called the "Image Report" and the feature
actually gives some succinct advice related to *accessibility*?

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

Low success rate relative to what? Is there data about the success
rate of Bobby users? Do you have data about the success rate of the
W3C Validator's HTML 4.01 alt presence check, which gives *no* advice
about what alt is *for* and what you might want to put in its value
and which says nothing at all about alt if it is present but has a
badly composed value?



P.S. To get a practical idea of what is being advocated as a good-to-
preserve status quo and where I'm trying to move the bar, here's a
quick comparison.

When alt is missing the W3C Validator (the status quo the preservation
of which is advocated) says this:

"The attribute given above is required for an element that you've
used, but you have omitted it. For instance, in most HTML and XHTML
document types the "type" attribute is required on the "script"
element and the "alt" attribute is required for the "img" element.

Typical values for type are type="text/css" for <style> and type="text/
javascript" for <script>."

The Validator.nu Image Report, on the other hand, says this:

"The following images are not links and have no textual alternative
available (no alt attribute), and are, therefore, not accessible to
people who cannot see the images or understand the symbols in them.

An image belongs here if the image is significant (non-decorative) and
the markup generator doesn’t have knowledge on what the image is about
available. For example, a photo gallery generator does not have
textual alternatives available when the user refuses to provide them.

Purely decorative images should have the empty string as the textual
alternative (alt=""), so it is a mistake for those to appear here.
Also, when the markup writer knows what the images are about, (s)he
should write textual alternatives."

(The text can be improved--it's pulled from a wiki.)

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

Received on Wednesday, 14 May 2008 15:09:04 UTC