Re: Investigating the proposed alt attribute recommendations in HTML 5

On Sep 11, 2007, at 12:16, Charles McCathieNevile wrote:

> I think the situation today is similar to that of seven years ago,  
> where "we" were advocating for alt as a required attribute, but at  
> the same time insisting, for accessibility reasons, that authoring  
> tools don't just auto-generate it.

Any HTML spec that makes unattended markup generators non-conforming  
will be disrespected in one way or another, because people want to  
write unattended generators.

> The problem doesn't really come down to JAWS, but to authoring  
> tools/environments.

I don't think JAWS can be excused. Reading out the file name without  
subjecting it to a heuristic readability test first can lead to awful  
usability as demonstrated by Steven Faulkner's testing. File names  
aren't intended to be read out loud by AT in the general case.  
Reading them is a placeholder generation heuristic. Failing to check  
first that the string to be read consists of something readable such  
as words in a dictionary or even sequences of letters that are long  
enough to look like words (as opposed to just punctuation and digits  
where a-f counts as potential hex digits) is just awful.

> Flickr deciding to put null alt, or something that had the image's  
> tags in it, would be a half step forward.

On the photo page, at least, that would duplicate content.

> Flickr, as a photo album, is an odd case - if you get a description  
> then it generally makes sense not to have more text in an image.

As I understand it, the whole point of keeping mentioning Flickr is  
that from the point of view of Web development in general, it isn't  
odd but a showcase Web 2.0 app. Conformance requirements should be  
inclusive enough to allow common apps to be written as conforming.  
(Flickr isn't conforming now, but the HTML 5 spec should be such that  
Flickr could be written as conforming. Otherwise, conformance would  
be just an ivory tower concept.)

> But where a CMS or athoring tool is used, it *should* have the  
> ability to find out something about the image, or draw something  
> only moderately bad, or propose the descriptions that have been  
> used before.

My understanding is that the fundamental assumption behind leaving  
the alternative text generation heuristic to the client side is that  
there is a handful of aural Web clients but a multitude of software  
generating HTML and it makes more sense to solve the problem a  
handful of times as opposed to a multitude of times. Moreover,  
developers of aural browsing software are expected to be in a better  
position to have the expertise and incentive to develop heuristics  
that meet the needs of their users.

Steven Faulkner's testing shows that this assumption fails miserably  
when it comes to the current state of JAWS. The assumption may have  
to be revised if there's a fundamental reason why JAWS and others  
will continue to fail to provide better heuristics on the client side  
to such extent that even hasty non-expert server-side concoctions are  
likely to be better throughout the expected lifetime of the spec.

One way of revising the assumption would be acknowledging that the  
client side heuristic isn't a point of competition for the clients  
and writing a de jure algorithm in the spec saving the client  
developers the trouble of designing one.

> Without active participation from the author, all heuristics are  
> pretty awful.

But the whole point of allowing alt to be omitted is to cover the  
case of what tool developers are to do when the author just isn't  
participating. And insisting that a human should always participate  
in the generation step of HTML documents just isn't going to work  
when it is so clear that people want to have unattended software  
generating stuff.

> I would expect more authoring systems to have developed the ability  
> for J. Adminassistant to provide something half-useful when adding  
> an image, and more authors to realise that they *can* do this  
> easily enough and just remember.

It may well work for some authoring use cases, but not for all  
authoring use cases, which means that such an expectation shouldn't  
be baked into the notion of document conformance.

I upload so many photos to Flickr (5414 photos uploaded in the last  
14 months), that I don't take the time to type nice titles for my  
sighted friends to whom I advertise my Flickr sets. I think expecting  
me to bear the opportunity cost of authoring even more elaborate  
additional (something that my camera doesn't output) data for people  
to whom I don't advertise my relatively inane vacation photo sets to  
is unrealistic, even though I fully agree that it would be great for  
a blind user who comes across my photo sets to have alternative text  
for the photos.

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

Received on Tuesday, 11 September 2007 10:21:39 UTC