W3C home > Mailing lists > Public > wai-xtech@w3.org > May 2008

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

From: David Poehlman <david.poehlman@handsontechnologeyes.com>
Date: Wed, 14 May 2008 16:03:36 -0400
Message-ID: <E08D800E8DD54D72A9F04DC5D822BB8D@HANDS>
To: "Henri Sivonen" <hsivonen@iki.fi>, "Matt Morgan-May" <mattmay@adobe.com>
Cc: "HTML Working Group" <public-html@w3.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>

Here is a proposal to throw the burden to the AT.  I might need what you 
suggest and I don't have AT so I suggest we not throw the burden to the AT.

----- 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" 
Sent: Wednesday, May 14, 2008 3:31 PM
Subject: Re: [html4all] HTML5 Alternative Text, and Authoring Tools

On May 14, 2008, at 21:02, Matt Morgan-May wrote:
> On 5/14/08 7:22 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>> On May 13, 2008, at 20:52, Matt Morgan-May wrote:
>>> 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.
> No. What I'm trying to impress upon you is that there _is no
> "accessible"
> ideal_. All you can measure is whether and to what extent the author
> has
> endeavored to use accessible practices.

I thought we were trying to maximize accessibility from the point of
view of the user instead of trying to maximize the endeavor of the

>> 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.
> Once again, I reiterate that validator.nu is not the issue. But it's
> sad to
> see your bias against making your own content accessible.

Uh. My point is that the HTML Validator.nu generates is pulling in
images that aren't "my content".

>> 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).
> How is "unwieldy" a machine-checkable measure?

A UA can measure font metrics before it draws text. Why wouldn't it
measure speech time of a string before speaking it? Or checking that
the string matches something in its dictionary?

> It would have to be, for a UA
> to handle it. But clearly you are pushing responsibility for missing
> @alt
> from the author to the user and/or the user's AT, which you yourself
> are
> arguing cannot handle it.

It's a situation AT needs to be deal with anyway--no matter what's
conforming syntactically.

> Should they just try harder, then?


> Who's going to give them advice on how to do that?

I would hope detecting what strings take very long to speak or that
don't appear to contain words from a dictionary is something that AT
vendors wouldn't need external advice on.

> And what other metadata could they possibly scrounge to repair
> missing @alt?

Ultimately, the *data* instead of the *meta*data. (And no, I'm not
suggesting it would come even close to the usefulness of a human
writing alt text.)

>> 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!)
> UAs that include assistive technology are not going to stop
> conjuring repair
> alt text as long as there's a high likelihood that missing @alt is
> damage.
> Making @alt optional won't change that.

Would @noalt change that?

> It will only exacerbate the problem,
> as more people ignore @alt.

Will they?

> Bogus alt text is covered under WCAG, anyway.

I'm having trouble finding the right part of WCAG.

>>  * Putting an empty-string alt on an image whose presence is
>> important for comprehending surrounding text.
> This would be a case for @noalt.

How would it make the content more accessible?

>>  * Putting alt="image" on an image when the UA would by itself render
>> the word "image" or "graphic" as chrome.
> This could also be a case for @noalt, if the author has no alt text to
> provide.

How would it make the content more accessible?

>> 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.
> Then make a proposal that doesn't cause worse damage. Optional @alt
> is not
> one.

I guess I am expected to take your word for it.

>>> 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.
> The key argument that's been put forward in defense of optional @alt
> is that
> sometimes we _can't_ have alt. All of the cases you cite above are
> use cases
> of this. But "can't have alt" has semantic value of its own to AT,
> which all
> these cases are trying to express in other ways. And it's completely
> unacceptable to say that missing @alt assumes the semantics of
> "can't have
> alt", when it already implicitly has the semantics of "I didn't
> create alt,
> either purposely or accidentally" billions of times over on the web.
> And
> when each time someone creates a new image with missing @alt
> accidentally,
> it further pollutes the stated semantics of missing @alt.

What kind of user interface differences are you envisioning for the
case where there is no alt attribute but there is a noalt attribute
versus the case where there is neither?

So far, I haven't noticed the proponents of the @noalt attribute to
outline even one feasible user agent behavior design for this.
Instead, that talk about @noalt has focused on the behavior of

> (Even after all the arguing, talking about the semantics of a missing
> attribute still makes me smile.)

To me, it seems pretty clear that the semantic user agent has to work
with is that it didn't get data.

>> Instead, I do think that offering text alternatives for review
>> like the Image Report does is helpful.
> Again, still not caring about validator.nu. If it's helpful, great,
> but it
> doesn't come close to covering the same territory as the spec.

So would you be okay with the spec saying that the alt attribute is
required but that conformance checker software is exempt from checking
for this requirement? That can't be what you are saying, can it? I'm
really having trouble understanding with what you are arguing about
machine-checkable requirements if you are not caring about how they
are implemented in checker software.

>> 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.
> Ah, so you're all for accessibility, as long as content producers
> don't have
> to do any of it?

I want to make the Web more accessible. I don't want content providers
to do stuff for the sake of doing stuff to show their commitment. If
we can make the Web more accessible with the content providers having
to make less effort for it, what's not to like? (I'm not saying alt is
one of these opportunities. I'm saying HTML5 is taking such
opportunities and the thanks it is getting is suggestions that it's
ignoring accessibility.)

> I'm sorry, but it doesn't work that way. And however inconvenient,
> you're
> not going to code your way out of it. If you want accessibility to be
> anywhere near supported in HTML5, you're going to need to drop this
> single-authoring idealism.

What's wrong with the idea of media-independent native widgets?

> People are accessing the web using multiple
> modalities (including people without disabilities, who may browse with
> images off because they're on a low-bandwidth line, or prefer having
> web
> pages read to them on their iPod or some other device), and they
> need to be
> accommodated.
> The alt attribute is not about machines. It's about people.

Like I said, alt is one of the things that will require dual authoring
for the foreseeable future. That's why it's such an issue.

But when we can design media-independent features, we should do that
instead of asking authors to expend extra effort to show their
commitment to accessibility.

>> 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.
> Fine with me. I don't trust the ability of language developers to
> formulate
> and satisfy accessibility requirements in ways that don't induce
> unwanted
> effects when exposed to users with disabilities.

Hence, the length of this thread.

> And I reject the idea that a language should have its accessibility
> features
> loosened for the benefit of people who consciously deny (or, to
> euphemize,
> "who don't share the goals of") accessibility. Let's put this as
> bluntly as
> possible: you are arguing that since people presently use HTML in a
> way that
> discriminates against people with disabilities, your wish, or at
> least the
> end result of your wish, is for HTML5 to be complicit in that
> discrimination.

That's not what I am arguing. I'm arguing that we need to face the
fact that there are people out there, who don't share your goals or
mine. We don't get to adjust how they react to a given stimulus (such
as a validator message). We do get to adjust what stimuli we send.

We should set up the stimuli to maximize accessibility *given*
conflicting goals of people *out there*. We shouldn't focus on setting
up the stimuli to be righteous-looking.

Henri Sivonen
Received on Wednesday, 14 May 2008 20:04:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:29 UTC