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

On May 14, 2008, at 23:51, Matt Morgan-May wrote:

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

No. Now you are again writing as if we were discussing banning alt.

If you are an author, by all means go ahead and use the more useful  
technique. But if you are an AT vendor you need to deal with the  
situation of the more useful technique not being used.

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

Actually, when there is an authoring tool that guarantees that its  
output is machine-checkably syntactically correct, what AT would be  
getting wouldn't be an expression made by the author. Instead, it  
would receive a tool-inserted piece of syntax that is there in order  
to make the output data stream from the tool pass a machine- 
administered syntax check.

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

Sorry about being thick, but I don't see how that is addressing bogus  
alt text in a way other than effectively saying that alt text must not  
be bogus.

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

With @noalt you can be sure that the developer of a markup generator  
wrote the code to put the attribute there, but you can't know anything  
new about the intentions of the user or the markup generator.

>> 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 still don't understand why you don't care. "Your specific checker"  
implies that you expect there to be others. Is there a particular  
reason to believe that later competitors would suck but gain market  
share to have significance?

On the other hand, if you're saying that you are seeking to be  
normative or asking any WAI group to ask the HTML WG to be normative  
over my software, I can drop this discussion right now.

> I assume you wouldn't remove the image checker if @alt were mandatory.

I wouldn't. However, putting messages about alt  presence on the side  
of the validation function would water down the part of the design of  
the image report that is meant to not induce bad alt text.

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

Like Boris pointed out, that depends on whether it interferes with  
improving accessibility.

WCAG 2.0 sure puts a lot of emphasis on *claiming* conformance--as if  
that was what's important.

> As does the HTML WG.

Actually, the HTML WG doesn't issue badges.

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

http://lists.w3.org/Archives/Public/public-html/2007Jun/0886.html

Using <progress> as an example in particular:
http://lists.w3.org/Archives/Public/public-html/2007Jun/0808.html

> What AT companies, disability groups, and accessibility experts have  
> vetted your decisions?

I'm not aware of vetting by AT vendors. In the case of e.g.  
<progress>, buy-in from AT companies isn't needed if they already  
support an API for receiving information about ARIA progress bars (or  
progress bars in general). A browser is expected to expose <progress>  
and role='progressbar' using the same accessibility API.

I'm not aware of disability groups vetting HTML 5. My understanding is  
that the features have been on the radar of some accessibility  
experts, but I don't recall specific public endorsements, and I'll let  
people speak up for themselves if they so choose.

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

Received on Thursday, 15 May 2008 07:26:28 UTC