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

On 5/14/08 12:31 PM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
> On May 14, 2008, at 21:02, Matt Morgan-May wrote:
>> 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?

This is grasping at straws. There is no easy solution readily available for
AT. The current draft already tried that, remember? If you're going to
demand a complete-to-your-satisfaction solution to this issue, then we're
going to expect the same of you if you throw the problem over the wall at
us.

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

So we should get rid of the more useful technique already in practice for
one you already acknowledge as inferior.

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

Yes, because it would prompt AT not to attempt to repair missing @alt,
because the author has expressed that it's not possible.

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

Yes, in droves. Even with it as a required attribute, it's still taken 10
years of conditioning to get authors to do it.

>> Bogus alt text is covered under WCAG, anyway.
> 
> I'm having trouble finding the right part of WCAG.

It's the very first technique:

1.1.1 All non-text content that is presented to the user has a text
alternative that serves the equivalent purpose(...)

http://www.w3.org/WAI/WCAG20/quickref/20080430/Overview.php#qr-text-equiv-al
l

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

Not any more than I'm expected to take yours.

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

That's because all you've been talking about is the validator!

Visual UAs wouldn't require any new behavior. AT would announce the presence
of the image, and that it's not accessible, in the user's language, and
would not attempt to repair missing @alt. This is different from @alt="",
which silences decorative images. Images with missing @alt and @noalt, being
invalid, are treated as damaged, causing AT to attempt to repair.

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

And not whether that is intentional, for which I'm proposing @noalt, or
accidental, in which case AT would need to attempt to repair the missing
data. The implications for these two scenarios is very different at the
UA/AT level. 

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

What I'm saying is that how you deal with optional @alt in your specific
checker does not matter to me, as long as it's still optional. I assume you
wouldn't remove the image checker if @alt were mandatory.

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

There's nothing wrong with getting content providers to show their colors,
IMO. WAI even issues downloadable badges for it. As does the HTML WG.

> If we can make the Web more accessible with the content providers having
> to make less effort for it, what's not to like?

No arguments here. (For once!)

> (I'm not saying alt is one of these opportunities.

Then we agree, it's not. (Two in a row!)

> I'm saying HTML5 is taking such
> opportunities and the thanks it is getting is suggestions that it's
> ignoring accessibility.)

Okay. Now I have to ask, in the language of the HTML WG: where's the data?
What are you doing that's in the plus column for overall accessibility? What
problems are solved? Where is it documented? What AT companies, disability
groups, and accessibility experts have vetted your decisions? I'm willing to
be swayed. Seriously. Show me something you think would make me retract my
statement.

-
m

Received on Wednesday, 14 May 2008 20:52:29 UTC