Re: Investigating the proposed alt attribute recommendations in HTML 5

2007-08-31 21:23:11 +0200 "Jon Barnett" <jonbarnett@gmail.com>:
> On 8/31/07, Leif Halvard Silli <lhs@malform.no> wrote:
>> On 2007-08-31 17:06:51 +0200 Sander Tekelenburg <st@isoc.nl>:

>>>> And since the spec is supposed ot be media independent, this goes
>>>> for screeen readers as well.
>>>
>>> Of course.
>>>
>>>> (Hence, to say that screen readers can just use TITLE with ALT is
>>>> not available is backwards.)
>>>
>>> Indeed. But where does the spec say that?
>>
>> It doesn't. But some […]. Jon Barnett even […]: [… quotes … ]

>> But if one *really* think that it is enough that either TITLE or ALT is 
>> availble, then we should add something like this [to the spec]:
>> 
>>  «If the src and alt attributes are omitted, the image represents 
>>   whatever string is given by the element's title attribute.»
> 
> That's a misrepresentation of what I said, so I'll clarify my comment
> about @alt and @title with regard to the semantics in the draft.
> 
> You quoted my statement: "My comment about requiring @title would
> satisfy the need for accessible markup without changing semantics."
> 
> You (I believe) pointed out that it's better to provide a "poor" @alt,

I spoke up against the argument that poor alt is worse than anything else.

> or a "descriptive" @alt

I especially feel the 'descriptive' argument thin. Simply because an «alternative text is a replacement», it must often be descriptive. «Replacement» is a function and not a quality. A translation can be good or bad, but it is still a translation.  «Not descriptive» is two words about what kind of _content_ the function should - or shouldn't have. A descriptive text might perhaps be an inadeqate «translation» of the image. But it still have the function of being one. And, most importantly, just because it is descriptive doesn't automatically make it fit as TITLE.

> because without @alt, JAWS falls back to to using @src.

JAWS is just _one_ UA. It is not sufficient to describe what JAWS should do. What should text browsers do? What should your GUA do when you turn off image display? Should it not «seamlessly replace an image with some text» just as you suggest screen readers do?

>  I suggested omitting @alt and using @title instead
> because it gives accessible text without changing the semantics of
> @alt (from "alternative text" to "descriptive text")

Alternative text is equivalent content. You can even write the @ALT text first and find the image thenafter. (E.g. the «wrong» and «correct» examples quoted below comes in a secton of the draft with this title: «A phrase or paragraph with an _alternative graphical representation_».) The saying that descriptive is not fit in @ALT is wrong, as I see it. The meaning of this popular phrase ought simply to be that the text should be written to fit into the natural flow of the rest of the text. One should not simply look at the image and try to describe it, without fitting the description/the alt text into the flow of the rest of the text. But when we have a photo album, then we should indeed try to make the descripions a bit independent - as there is no story to tell per se.

Perhaps the good/simple thing with TITLE is that TITLE's are not supposed to be quite as integrated with the rest of the text, as are @alt text. :-)

> The draft gives this example:
> <!-- This is the correct way to do things. -->
> <p>
> You are standing in an open field west of a house.
> <img src="house.jpeg" alt="The house is white, with a boarded front door.">
> There is a small mailbox here.
> </p>
> 
> An aural UA can announce "You are standing in an open field west of a
> house. The house is white, with a boarded front door.  There is a
> small mailbox here."
> 
> Even without announcing the presence of an image, the image is
> completely replaced with the alternate text and the meaning of the
> document hasn't changed.

Based on Fangs [1], it seems JAWS briefly announces the presense of a graphic.

>  (After all, the draft says, "It is important
> to realise that the alternative text is a replacement for the image,
> not a description of the image.")

That quote from the draft follows just after this counter example, which you did not quote:

> <!-- This is the wrong way to do things. -->
> <p>
>  You are standing in an open field west of a house.
>  <img src="house.jpeg" alt="A white house, with a boarded front door.">
>  There is a small mailbox here.
> </p>

I get the feeling that you think that this «wrong way» example would have been a perfect semantic match had it been used in TITLE and not in ALT. And that, this «wrong way» example would have been a in violence of the «semantics» of ALT.

But fact is, that here the difference between «wrong» and «correct» is simply the difference between definite and indefinite form: «The house is white, …» or «A white house, …». I find these two alt texts to be of the same quality - perhaps the "wrong" text is even better, to my taste. (Another issue: many languages do not have definite form in their language - and will therefore perhaps not understand the draft at this point.)

Both «wrong» and «correct» text have one outstanding quality: They both use punctuation. They both ends with a full stop! That in itself means that the author have been thinking about the texts as replacment texts.

It is true that using the indefinite form is the super-neutral way of describing things in languages with definite and indefinite forms. It is also true that the draft says that a «on an image, [title=] could be the image credit or a description of the image». But this does not mean that if the text describes the image, then it should be in the title. Perhaps 'a white house' in general seems to fit better in TITLE= than do 'The house is white', but that doesn't mean that 'a white house' doesn't fit well in ALT text. You are not supposed to evalute the text and decide that if looks like a description, then it goes into title. 

ALT is a replacement for the image _regardless_ of how poor quality it has. The replacement-quality isn't a quality - it is a functionality. And when you know that, you can write good alt texts. Of course an ALT text can be - or appear to be - a decription of the graphic. 

> Here's an example from the original post:

[ … snipped flickr example … ]

> An aural UA might announce "Seargent Pepper and Robin-two from pinktigger"

The biggest problem here is, I think (but it would be interesting to hear from screen reader users), that there is no full stop after Robin-two. It should have been «Seargent Pepper and Robin-two. From pinktigger»

> By following the semantics in the draft and replacing the image with
> the alternate text (and not announcing the presence of an image) the
> meaning is changed […] in a confusing way. (What the hell is a
> Robin-two?)

Probably image number two or something. And I see no «change» in the meaning here. What is the orignial meaning?
 
> I suggested omitting @alt and using @title instead:
> <P class=StreamList>[…] <IMG
>       height=75  title=Sgt.Pepper&amp;Robin2
     [ … and noalt …]

> An aural UA might announce "[Embedded graphic titled Seargent Pepper
> and Robin-two] from pinktigger"

I don't think you can say that this is better unless you assume (perhaps you have tried?) that the screen reader is better at reading Title than ALT.
 
> So if the UA falls back to @title in the case of no @alt,
> accessibility isn't harmed - the user is presented with something
> useful. 

Yes, the user gets something useful - especially since often TITLE stuff should have been in ALT. This is a better strategy than to read the SRC URI - I never disagreed. Accessibility is enhanced, I think, if JAWS grabs TITLE rather than SRC. But this should be a useragent issue. Not an author issue. 

> Semantics aren't harmed - the image isn't replaced with
> confusing text, the presence of an image is announced along with
> descriptive text.  @title isn't being presented the same way as @alt
> (fulfilling the requirement you quoted). (It's never implied the the
> image represents the @title text as you said - the image with a title
> represents an image with a title)

We have no guarantee whatsoever that semantics aren't harmed. That is in the hands of the person who write TITLE=. TITLE have more spesific semantics than ALT - which perhaps haven't any other requirement than that it should be able to make the text functionable even without the images.

> I really don't know where your statement about media independence
> comes from.  I don't know what about this is media dependent.

In your GUA you get the graphic. If you have omitted a needed ALT text, then the screen reader doesn't have any replacment content.  If in addition the screen reader gets TITLE text instead, then the document becomes quite media dependent.
 
> This gives the aural UA a fighting chance at knowing when to
> seamlessly replace an image with some text and when to announce the
> presence of an image along with descriptive text.

You mean: when an IMG with noALT, then always announce the TITLE.

The draft does however not require TITLE when ALT isn't there.

>  I think the current
> draft moves us further in that direction in a way that's easy for
> authors (and authoring tools).  If there's a better way to reach that
> same end, it's a valid discussion.

How would you, if you designed an author tool, present to authors the choice between noALT and ALT=""? 

(In my view, this would reqiure that noALT was linked to TITLE and not to ALT: First the tool asks the author about @ALT. If the author leaves it empty, then the tool inserts alt="". Thenafter, the tool must ask for TITLE. If the author gives a title-text, then the alt="" should automatically be changed to noALT by the tool. If the author does not give any TITLE text, then one should assume that the icon is more or less iconic - and alt should remain alt="". [And thus, we could not have iconic images with title!] But what if the tool asks for TITLE= first, will all tools then always rememember to ask for ALT=? And we will also get many text editor written documents, where the author forgot to delete the @ALT. Confusing. I have not seen any serious attemts at explaing how one could work with this a author. Hence my question …)

>>> All I know is that some UAs (Jaws) have been reported to be
>>> configurable (might be the default; that hasn't been reported) to
>>> present the contents of @title when @alt isn't available. We don't
>>> even know if in that case the UA indicates that it is reading
>>> @title.
>> 
>> I know. And now we are discussing browser behaviour - not author 
>> requirements. That is confusing. In order to test what the author 
>> requirements could lead to, Joshue have been performing user tests. When we 
>> got the results, some were reacting by saying that Jaws should change its 
>> behaviour.
> 
> It's clear to me that JAWS's behavior is less than ideal, even in the
> HTML4 sense.  For example, seamlessly announcing the @src of an image
> just seemed confusing to me, as I would bet that a very small
> percentage of images in photo galleries have useful filenames.

Preferring to read SRC before trying the TITLE is indeed not so smart, since URIs are not so Cool that they ought to be ...

> As the semantics are better and more specifically defined - however
> their defined - one would hope that JAWS and other AT will change
> behavior to match those semantics.  (Otherwise it's a futile
> exercise.)

[1]<http://www.standards-schmandards.com/projects/fangs/>
-- 
leif halvard silli

Received on Saturday, 1 September 2007 02:10:14 UTC