W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2007

Re: Baby Steps or Backwards Steps?

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 16 Aug 2007 12:00:05 -0700
Cc: Jason White <jason@jasonjgw.net>, public-html@w3.org, wai-xtech@w3.org
Message-Id: <0DECC2C7-533A-4A2F-B8FC-DEBECBCD47AE@apple.com>
To: Gregory J. Rosmaita <oedipus@hicom.net>

On Aug 15, 2007, at 11:35 PM, Gregory J. Rosmaita wrote:

> 3 questions:
> 1. why not raise the issue on public-html?

At the time I sent mail about this, the HTML Working Group had not yet  
adopted the HTML5 draft.

> 2. why not cross post your concerns/issues to the WHAT WG list
>   and the w3c-wai-au@w3.org list, which exists precisely to
>   address authoring tool issues;

I prefer not to cross post. And I don't think this is an authoring  
tools issue.

> 3. how does leaving alt out entirely when an image is not "purely
>   decorative" "better" serve someone merely by indicating the
>   presence of an image?

I have no direct experience of this, because I do all my browsing in  
image-capable browsers. But I have been told the following:

1) Text-only browsers such as Lynx distinguish empty alt from missing  
alt by showing nothing at all in the former case, but the filename and  
a download link in the latter case. This would let console-mode users  
know there is an image, possibly gain information from the filename,  
and save it for separate viewing.

2) At least some assistive technologies apparently make a similar  
distinction between empty alt and missing alt. Someone compared this  
to a transcript of audio explicitly stating "inaudible" for a part of  
the speech that the writer couldn't make out, instead of just omitting  
it, which makes sense to me.

If distinguishing empty alt from missing alt is indeed a useful thing  
for user agents to do, then we should set up the incentives so that  
consumer-targeted authoring tools do not gratuitously insert empty alt  
in the markup.

One alternative to allowing missing alt that was discussed is having a  
"noalt" attribute to distinguish alt text intentionally missing on a  
meaningful image (perhaps because a program is generating the html and  
has no way to obtain alt text) from alt text that was accidentally  
omitted. This would make conformance checking more useful to people  
who are authoring by hand, since they couldn't leave out alt  
accidentally if they ran their code through a conformance checker. The  
current spec text would make it easier to accidentally leave out alt.


> 1 suggestion:
> check out the work of the Authoring Tool Accessibility Guidelines
> working group -- http://www.w3.org/WAI/AU -- there is a normative
> technical recommendation (ATAG 1.0 -- http://www.w3.org/TR/ATAG10/)
> and work on ATAG 2.0 is currently underway...  the purpose is to
> ensure that authoring tools of every type enable an author to
> create valid, structured, semantically meaningful and accessible,
> AND to ensure that authoring tools of every type are useable by
> persons with disabilities, so that they need not be relegated to
> passive consumers of content (there's already a medium for that,
> named television) but can equally participate in aspects of life
> that hitherto were impossible, such as managing one's own finances,
> or even directly communicating with a large network of one's own
> peers -- before electronic information exchange, one of the biggest
> obstacles preventing effective communication between blind individuals
> and/or groups, one had to decide how many alternative versions of
> the content needed to be made available...  there's large print (and
> there are legal definitions of what constitutes text that can be
> posted "free matter for the blind or physically impaired"), which
> will be useful to some, braille -- something which only a relatively
> small portion of the totally blind community can use, due to  
> neuropathy
> and other neurological complications that may accompany blindness,
> or be sustained afterward; and converting information in a timely
> manner (such as a legislative alert, asking people to write to their
> representatives on an issue of direct import) into an audio format,
> mass reproducing hard copies of audiblized content, and sending them
> out often makes the audiblized information moot by the time it  
> actually
> reaches the intended recipient; electronic communication changes the
> landscape dramatically, enabling -- for the first time in human  
> history
> -- users who could not directly communicate or network amongst 
> themsevles, were suddenly able to do so due to email, newsgroups,
> and, eventually, the web...  this is but one example -- i can only
> speak of that which i know, but i'm sure if i had cross-posted this
> thread to the w3c-wai-ig (interest group) list, you would have heard
> from quite a few specific user groups who have their own set of
> barriers to overcome...  when TBL initiated the Web Accessibility
> Initiative, it was precisely to remove existing barriers and to
> encourage developers, implementors, authors and end-users to
> consider all aspects of usability/universality/accessibility at
> EVERY stage of the W3C process, so that new barriers would not
> be erected by or codified in a W3C technical recommendation...
> gregory.
> --------------------------------------------------------
> Men are not against you; they are merely for themselves.
>                              -- Gene Fowler (1890-1960)
> --------------------------------------------------------
> Gregory J. Rosmaita: oedipus@hicom.net
> Camera Obscura: http://www.hicom.net/~oedipus/index.html
> --------------------------------------------------------
> ---------- Original Message -----------
> From: Maciej Stachowiak <mjs@apple.com>
> To: Jason White <jason@jasonjgw.net>
> Cc: HTMLWG <public-html@w3.org>, wai-xtech@w3.org
> Sent: Wed, 15 Aug 2007 22:52:44 -0700
> Subject: Re: Baby Steps or Backwards Steps?
>> On Aug 15, 2007, at 9:07 PM, Jason White wrote:
>>> On Thu, Aug 16, 2007 at 01:43:04PM +1000, Lachlan Hunt wrote:
>>>> IIRC, one of the problems with that approach is that encourages
>>>> authoring
>>>> tools wanting to output conforming markup to generate useless alt
>>>> text,
>>>> which is often worse than providing no alt attribute at all.
>>> On the contrary, it could also encourage authoring tools wanting to
>>> output
>>> conformant markup to prompt the author appropriately in the user
>>> interface to
>>> supply the necessary ALT text.
>> I raised this issue a while ago on the WHATWG list. The specific
>> examples I cited were:
>> 1) Photo sharing sites like flickr.com. It would be wildly
>> impractical  for such a site to prompt the user for alt text for
>> every image,  especially since they allow batch uploads of
>> hundreds of photos. They  do allow adding caption text that is
>> visible to everyone, but don't  require it.
>> 2) Mail clients that generate HTML. A user may be inserting an
>> image  or multiple images through drag-and-drop or copy/paste.
>> Again it would  be impractical and annoying to prompt the user.
>> Please keep in mind these kinds of scenarios where the
>> "authoring  tool" is simply an end-user application that happens
>> to generate HTML.  Such applications aim not professional
>> authors but end users who are  not experts on markup or
>> accessibility. Note that popping up a modal  dialog to ask for
>> alt text could actually hurt accessibility for  creating and
>> sharing content.
>> In practice what has happened in cases like 1 and 2 is that
>> alt=""  gets inserted always, which is counterproductive. It
>> leads screen  readers and text-only clients to treat the image
>> as purely decorative,  which it's not. It is better to leave out
>> alt entirely in such cases  so that tools can indicate the
>> presence of an image.
>> Regards,
>> Maciej
> ------- End of Original Message -------
Received on Thursday, 16 August 2007 19:00:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:17 UTC