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

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

Yes.

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

> (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
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 14 May 2008 19:32:38 UTC