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

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.

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

> (Oh, and BTW, Mechanical Turk seems like a case where
> images are embedded in HTML without the software knowing what they
> are...)

MTurk also allows you to set constraints on certain tasks (or "HITs"). For
instance, you can require that a worker has vision in order to accept your
task. Add @noalt, and you're done. Simple.

You are still sacrificing a badly needed feature of HTML on behalf of a site
(http://mturk.com) which, like Flickr, doesn't even try to validate. MTurk
is even missing a doctype.

> 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? 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. Should they just try harder, then? Who's going to
give them advice on how to do that? And what other metadata could they
possibly scrounge to repair missing @alt?

> 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. It will only exacerbate the problem,
as more people ignore @alt. Bogus alt text is covered under WCAG, anyway.

>   * Putting an empty-string alt on an image whose presence is
> important for comprehending surrounding text.

This would be a case for @noalt.

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

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

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

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

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

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

And which isn't a widely-used or fully-functional assistive technology.
Sorry. A can of spray paint does not a professional painter make.

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

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

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.

-
m

Received on Wednesday, 14 May 2008 18:03:44 UTC