W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Need differentiator between "no alt text provided" and "no alt text necessary"

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 12 Feb 2009 10:09:29 +0100
To: "Dan Connolly" <connolly@w3.org>, "James Craig" <jcraig@apple.com>
Cc: "Ian Hickson" <ian@hixie.ch>, "Maciej Stachowiak" <mjs@apple.com>, public-html@w3.org
Message-ID: <op.uo8ed3x6wxe0ny@widsith.local>

On Wed, 11 Feb 2009 23:56:48 +0100, Dan Connolly <connolly@w3.org> wrote:

>
> On Fri, 2009-02-06 at 12:33 -0800, James Craig wrote:
>> On Feb 6, 2009, at 12:15 PM, Ian Hickson wrote:
>>
>> > I've added a note that says:
>> >
>> >   In a conforming document, the absence of the alt attribute indicates
>> >   that the image is a key part of the content but that a textual
>> >   replacement for the image was not available when the image was
>> >   generated.
>> >
>> > Does that help?
>>
>> That's perfect. Thank you.
>
> Did we just achieve consensus between the HTML and the PFWG
> on ISSUE-31 missing-alt?
>
> i.e. James, are you pretty sure the rest of the PF WG agrees
> with you?
>
> Matt May, Chaals, etc. is Ian's position close enough
> to your own? It works for me. Do we have 3 independent parties
> in agreement, I wonder?

I think we are close, but not there yet. I have a couple of real  
disagreements with the current draft, towards the end of the section on  
alternatives[1]:

Section 4.8.2.1.11 "An image in an e-mail or document intended for a  
specific person who is known to be able to view images" seems to me mildly  
harmful. Specifically, it appears to legitimate claims of the kind "all  
our customers can see, so we don't need to worry", something that causes a  
huge umber of problems in ensuring accessibility where it is in fact  
necessary.

An example given a decade ago was about a driving school, where someone  
asked what the point of providing alt was. And someone pointed out that  
there are many people who
1. Are blind
2. Weren't always, and learned to drive
3. Have children who ask them for help when learning to understand the  
road rules.
(Possibly even more who meet condition 1 and 2 but instead of meeting 3  
want to offer unsolicited advice on everything including driving - but  
that's not relevant to the topic).

I realise that this is a somewhat political / use-based argument, byut my  
personal experience suggests that removing this section would do no real  
harm and some small good.

4.8.2.1.13 Guidance for markup generators also seems problematic. Its  
suggestion that tools might simply assume that things are decorative and  
use alt="" flies in the face of both ATAG 1 [2] and the current draft of  
ATAG 2 [3], both documents designed specifically to address this issue for  
the relevant audience. The section's treatment of what to do when an image  
represents a link is, IMHO, an over-simplification of the guidance in ATAG  
that is also in conflict for some cases with what that specification  
actually says.

If the former section were removed, and the latter section rewritten to  
follow what ATAG says (and even better, refer to it directly), then I  
believe the current draft and those modifications would resolve ISSUE-30.  
(Whereas the current draft and some other set of  odifications may or may  
not, IMHO).

A more minor quibble that I think is editorial is with "don't do this"  
example of bad practice given in Section 4.8.2.1.2 A phrase or paragraph  
with an alternative graphical representation: charts, diagrams, graphs,  
maps, illustrations" - rather than using the current text, I would suggest  
something like "Photo of white house with boarded door" - and perhaps a  
note that such text *would* be reasonable as a title *in addition* to the  
suggested alt.

Likewise I have editorial quibbles with the allegedly bad example in  
Section 4.8.2.1.9 "A key part of the content" where it suggests that "The  
first of ten cards in the Rorshach test" is bad alt text. Assuming some  
resolution to ISSUE-30 allows for a reference to a further description  
that is not included in the main flow of text, and a page whose assumed  
audience is people who know what the Rorshach test is, or describes it,  
the specifics of the picture is not necessarily relevant and the example  
*may* be perfectly reasonable. As demonstrated by the fact that I can have  
a meaningful discussion about it by email, even though I have no idea what  
it actually looks like because I didn't properly read the description  
included in the proposed good example.

Which is pne reason why as far as I am concerned the current does *not*  
resolve ISSUE-30 - longdesc and whether it is such a great idea to remove  
it from HTML. There are some other examples given in this section of the  
draft, such as descriptions of complex images, where the ability to refer  
to a standalone resource as a description of a complex image would  
facilitate re-use of the image across different pages for users and  
authors, and would facilitate recognition of the image for both authoring  
tools and assistive technologies. Likewise, the use of a title attribute  
to describe another section in the same document as the relevant text is  
helpful in a monolingual world, but even more helpful is the ability to  
provide a machine-readable pointer so the information can be harvested. (I  
doubt Google would harvest it automatically due to web spamming problems,  
but that is not relevant to, for example, an enterprise website management  
system).

However, that has a seperate issue number so that it can be resolved  
another day.

> (FWIW, editorially, I like the suggestion of
> 3 Feb 2009 08:47:11 +0200 to include the two by three table)
>

[1] http://dev.w3.org/html5/spec/Overview.html#alt
[2] http://www.w3.org/TR/ATAG10/atag10.html#check-no-default-alt
[3] http://www.w3.org/TR/2008/WD-ATAG20-20081124/#principle-support-author  
checkpoint B.2.4.3

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 12 February 2009 09:10:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC