Should photos in photo-sharing sites have alternate text?

We take for granted that photo-sharing sites must have alternate text for photos in order to be accessible. After all, the assumption is that alternate text makes images accessible in content-rich Web pages; so why not use alternate text to make stand-alone photos accessible? Or is it time to challenge this assumption and have a debate on whether or not alternate text is the best way to make photo-sharing sites accessible?

Are photo-sharing sites simply a file system for images?

When you browse photos directly on a digital camera, there is no alternate text for the images. When you browse for photos on a hard drive using Windows Explorer or Finder, there is no alternate text. When you browse for photos on your Web server using FTP, there is no alternate text. When you browse for photos using a desktop application like Google Picasa, there is no alternate text. Yet, browsing the same set of photos through a Web interface, one expects to find alternate text. Why?

Does alternate text make images accessible?

No, alternate text does not make images accessible. Alternate text makes content that contains images comprehensible when images cannot be seen. What's the difference? If alternate text makes images accessible, then reading the alternate text for an image on its own should sufficiently describe the image. This may work for some images but not for all. In the following example, simply reading the alternate text in isolation will not adequately describe the image:

<p>I <img src="heart.gif" alt="love" /> you!</p>

Instead, the real function of alternate text is to work with surrounding content to make that content comprehensible (and therefore accessible) when images cannot be seen.

No context, no appropriate alternate text?

Context, that is the content surrounding the image, determines what appropriate alternate text should be for an image. In other words, appropriate alternate text for an image can only be written within the context that the image finds itself in. Let's take the following image as an example:

Photo of a dog on a beach.

If the text preceding this image reads "My dog looks like a giant Red Heeler.", appropriate alternate text for the image could be: "He has a pronounced nose with a white star. His coat is orange with white on his chest and paws."

Or, if the text preceding the image reads "Bob always loses his ball.", appropriate alternate text could be: "He is on a beach looking intently for it."

On photo-sharing sites, there is no such context for any of the images. The photos are simply organized into a slide show. So if there is no context, how do we write appropriate alternate text?

How to write equivalent content without a context?

On photo-sharing sites, the absence of textual context can make formulating appropriate alternate text impossible, but surely one could still write useful alternate text? As it turns out, that is really hard to do because of the nature (i.e. the restrictions) of alternate text. Let's take the following stand-alone image as an example:

Another photo of a dog on a beach.

Useful (i.e. informative) alternate text for this image could be: "Bob at English Bay in Vancouver, British Columbia, taken in February 2010 by Vlad Alexander." Unfortunately, this alternate text is too informative. This is because alternate text should be an equivalent replacement for an image, providing only information that a sighted user can derive from looking at the same image in the same context. The alternate text suggested provides information that is unlikely to be derived from simply looking at this stand-alone photo.

Are photos in photo-sharing sites eye-candy or content?

What is the purpose of photos in photo-sharing sites? Are the photos simply there to amuse the eye (i.e. decorative) or do they convey meaning? For some people, the photos will have meaning. But do they have meaning for the average Web user? The average Web user is unlikely to know the people or places in the photos and will browse them solely for amusement.

But how can the photos be decorative if they need to be accessible, i.e. if blind people need to know what's in them?

The problem is that we are thinking of alternate text on photo-sharing sites as an accessibility issue. And this is because the HTML5 team framed it as an accessibility issue when they made the alt attribute optional so that HTML5 will validate on photo-sharing sites.

In fact, this is not an accessibility issue at all; it's a usability issue that affects everyone. All visitors to photo-sharing sites want information that is not derived by simply looking at an image and its context. For example, visually a person can derive from a photo that it contains "three people in an office setting". How useful is this? What we are really looking for is information like: "Alice (left), Bill (center) and Kathy (right) at office party in December 2008". But that information is not alternate text (equivalent content). It is information that on photo-sharing sites should be transmitted as descriptions or captions of photos. The alternate text for the photos should be left blank like this:

<div>
<img src="123.jpg" alt="" />
<p>Alice (left), Bill (center) and Kathy (right) at office party in December 2008.</p>
</div>

Conclusion

Photo-sharing sites should leave alternate text blank. Instead, they should encourage users to caption and describe images, with the captions and descriptions being available to all visitors.

As a long term goal, new technologies should be developed that allow photographers to annotate photographs right in the camera at the point of capture (using voice recognition, GPS, small keyboards, etc.) These annotations can then be transmitted along with images and be used wherever needed, such as on photo-sharing sites.

Public comments

1. Posted by Laura
on Wednesday 2010-07-28 at 04:51:26 PST

Hi Vlad,

The aria-labelledby attribute has been proposed as a solution for the Flickr use case:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#aria-labelledby_Attribute

It would explicitly associate a text alternative with an image, like the alt attribute. The difference being that the text is available to all by default facilitating universal design.

2. Posted by Vlad Alexander
on Wednesday 2010-07-28 at 06:59:19 PST

Is the aria-labelledby attribute really necessary when you have one image, one heading and one description?

I have not followed ARIA at all so I am not sure if I am misunderstanding the purpose of using aria-labelledby for images or if the following has been brought up or not. I assume the purpose of aria-labelledby attribute on the img element is to present content, found elsewhere in the document, in place of an image when the image cannot be seen? In other words, function just like alternate text. If so, then:

1. Won't this create content repetition? In the example sighted by the link you provided above, content would read: "wind dog wind dog Sighthounds are a family of dogs ...".

2. Won't this cause compression issues because you are taking content written in one context and slotting it into another context? Alternate text should be written to fit surrounding text. Instead this attributes used for images encourages re-use of content from elsewhere in the document which is unlikely to fit nicely into surrounding text of the given image.

3. Posted by steve faulkner
on Wednesday 2010-07-28 at 08:34:56 PST

hi vlad,
if you have an image with a description as you describe ("Alice (left),...") it should not have an empty alt alt="" as this effectively hides it from assistive technology so you are describing something that isn't there for some users.

4. Posted by steve faulkner
on Wednesday 2010-07-28 at 08:39:59 PST

"Is the aria-labelledby attribute really necessary when you have one image, one heading and one description?"

how often on photosharing sites is this the case? taking a random image from flickr http://www.flickr.com/photos/jenniferr_lee/4837466431/ look at the code, its never as simple as you describe.

5. Posted by Andrew Downie
on Wednesday 2010-07-28 at 17:32:42 PST

I have said for years that a whole conference could be devoted to alt attributes (and there would still be disagreement). Vlad raises some valuable points, as much in the area of general sites than photo sharing ones. As a screen reader user, I generally see the value of browsing photo sharing sites as about nil. If looking for an image for a particular purpose though, having them suitably captioned would be useful.
Unfortunately, Vlad's examples of suitable alt text for regular web pages are as rare as hens' teeth. Almost all the alt text I come across is, at best, bland and, at worst, misleading or downright irritating. Descriptions such as "logo", "divider" and "image" achieve nothing but clutter. I came across a bunch of image links on a site recently which claimed that the link opened in a new window. As well as using verbose expression, half of the links didn't do so.
I'm not sure that I've advanced the issue much, but feel better for commenting.
Andrew

6. Posted by Vlad Alexander
on Wednesday 2010-07-28 at 19:55:49 PST

steve faulkner wrote: "if you have an image with a description as you describe ('Alice (left),...') it should not have an empty alt alt="" as this effectively hides it from assistive technology so you are describing something that isn't there for some users."

Hey Steve. If the caption/description of the image in surrounding content adequately describes the function the image is meant to serve, then the image is simply eye-candy to those who can see. It should be hidden for text only users as it adds nothing to the content. Let's take a look at a better example:

<p>The Green Tree Frog can grow up to 4 inches in length. Its color depends on the temperature and color of the environment, ranging from brown to green. Figure 1 shows a green adult male with a white stripe along the jaw.</p>
<figure>
<img src="frog.png" alt="" />
<figcaption>Figure 1. Australian Green Tree Frog</figcaption>
</figure>

What could one write for alternate text in the above example that would not duplicate surrounding content? In this example, what are text only users missing if the image is hidden from them?

7. Posted by Niels Matthijs
on Thursday 2010-07-29 at 00:55:25 PST

One thing you should not ignore is that people search the web for information. People using assistive technology can look for images through Google Images, Flickr or whatever service. From that moment these images are taken out of their initial context, and without alt attributes people using assistive technology will have no means to check whatever it is they see returned.

8. Posted by steve faulkner
on Thursday 2010-07-29 at 05:12:01 PST

Hi Vlad, in the example you provided in comment 6. I would recommend that the image have no alt attribute and an aria-labelledby that references the <figcaption> as figure/figcaption are not supported by ATs (granted aria-labelledby is only supported by more recent AT/browser combinations. This way the image is identified as an image to the user and it is explcitly labelled. As I said previously a caption is a caption for something (in this case the image) so providing a method for users to be ablke to identify the nature of the object being referenced is necessary. In the future when figure/figcaption is supported, I envisage that the an image without an alt attribute inside a figure with a figcaption will be announced to screen reader users as an image or graphic despite not having an alt attribute, as the association between the caption and the image will be identiifed by the software.

9. Posted by steve faulkner
on Thursday 2010-07-29 at 05:45:04 PST

hi vlad, here are 2 links that may illuminate my thinking on this subject;
Investigating the proposed alt attribute recommendations in HTML 5 (september 2007) and HTML5: Techniques for providing useful text alternatives

10. Posted by Vlad Alexander
on Thursday 2010-07-29 at 08:15:07 PST

Niels Matthijs wrote: "People using assistive technology can look for images through Google Images, Flickr or whatever service. From that moment these images are taken out of their initial context, and without alt attributes people using assistive technology will have no means to check whatever it is they see returned."

As I mentioned in the article, "Alternate text does not make images accessible. Alternate text makes content that contains images comprehensible when images cannot be seen."

When images are taken out of their context, they are just bits organized into a file. So what these services do is offer a file search for file types GIF, JPEG and PNG. These services could just as well offer search for PSD, AI, DOC, DAT, ICO, etc.

steve faulkner wrote: "... I would recommend that the image have no alt attribute and an aria-labelledby that references ..."

Does this mean that you support an optional alt attribute?

steve faulkner wrote: "This way the image is identified as an image to the user and it is explcitly labelled."

Steve, I really would like to understand why this is necessary. So:

1. Why does an image need to be identified as an image to the user? For example, Firefox does not identify an image as an image when rendering alternate text in place of an image; which I think is correct behaviour. In the following example, the text "the RSS button" is alternate text:

Web browser displaying text: 'Press the RSS button to get recent articles.'

2. Why is it necessary to explicitly associate an image with a caption/description when the caption/description is adjacent to the image?

11. Posted by steve faulkner
on Thursday 2010-07-29 at 14:49:26 PST

Hi Vlad

"Does this mean that you support an optional alt attribute?"

I support the an img without alt being conforming HTML5 when aria-labelledby is present (non-empty only), the <img> is located within a <figure> that has a non-empty <figcaption> or when an image has role="presentation".

"Firefox does not identify an image as an image when rendering alternate text in place of an image; which I think is correct behaviour."

Conversely all other major browsers do. Whether a graphical browser indicates whether an image is present or not is a different question from whether screen readers should provide users with an indication of the presence of an image. You agree with Firefox behaviour in this case, I do not, for one thing if i am browsing with images off I still like some indication that an image is present so I can view it if desired or copy it or save it.

"Why does an image need to be identified as an image to the user? "

this should not be something the author or browser gets to decide it should be something the user decides via preferences.

"Why is it necessary to explicitly associate an image with a caption/description when the caption/description is adjacent to the image?"

<img> caption text <img>

which <img> is the caption text for?

12. Posted by Vlad Alexander
on Thursday 2010-07-29 at 19:38:31 PST

steve faulkner wrote: "which <img> is the caption text for?"

I don't think it really matters much, within a given document, because the textual view of the content will convey the same meaning to the user as the non-textual view.

13. Posted by ryan
on Thursday 2010-07-29 at 22:53:36 PST

@Andrew Downie said "I have said for years that a whole conference could be devoted to alt attributes (and there would still be disagreement)."

So true!

@steve faulkner said "Conversely all other major browsers do."

Yes, those browser vendors either cut off alternate text or don't display it at all. I would not use them as a showcase of correct behavior.

14. Posted by R.B.
on Friday 2010-07-30 at 20:32:45 PST

>it should not have an empty alt alt="" as this effectively hides it from assistive technology so you are describing something that isn't there for some users.

Steve, it should be a setting in assitive technology to _totally_ ignore images with empty alt or _partially_ ignore them by only identifying their existance. We should not have to code webpages to the limitations or bugs of assistive technology.

15. Posted by steve faulkner
on Saturday 2010-07-31 at 04:17:39 PST

Hi RB,

>Steve, it should be a setting in assitive technology to _totally_ ignore images with empty alt or _partially_ ignore them >by only identifying their existance. We should not have to code webpages to the limitations or bugs of assistive >technology.

alt="" is promoted as a method to use to indicate that images can be safely ignored by AT and so they do. In HTML5 browsers will implement this formally by removing <img> elements from the accessible DOM tree when the <img> has alt="".

What you describe is not a browser or AT bug, it is an authoring mistake. If the image has a caption that refres to the image, then the image should not have a flag (alt="") that indicates to AT that they can safely ignore the image.

16. Posted by steve faulkner
on Saturday 2010-07-31 at 06:39:32 PST

hi vlad,

"I don't think it really matters much, within a given document, because the textual view of the content will convey the same meaning to the user as the non-textual view."

You are assuming the 2 views(textual and non-textual) are mutually exclusive, knowing that a description pertains to its visual representation can be important for users with limited vision or cognitive impairments who use AT to aid in their understanding of page content.

17. Posted by Vlad Alexander
on Saturday 2010-07-31 at 08:05:22 PST

Steve, generally I support markup that builds relationships within content. Such relationships can help people and machines with comprehension. However, omitting the alt attribute and using ARIA attributes is a very poor approach.

Authoring alternate text is hard enough, now there are now conditional rules (if this, then that, but not when...). Not only will Web site creators not use these rules correctly, but also they are impossible to implement using authoring tools. Can you describe a user-friendly WYSIWYG editor interface that can make the alt attribute optional and generate the ARIA markup to associate content? If not, then the approach you recommend is designed for hand-coding by experts.

18. Posted by steve faulkner
on Saturday 2010-07-31 at 15:06:25 PST

hi Vlad,

"However, omitting the alt attribute and using ARIA attributes is a very poor approach."

I don't see how using an empty alt on an image that is referenced and described in the text is a better approach.

"Authoring alternate text is hard enough, now there are now conditional rules (if this, then that, but not when...). "

There have always been conditional rules when authoring alt text. There will most probably always will be.

"Can you describe a user-friendly WYSIWYG editor interface that can make the alt attribute optional and generate the ARIA markup to associate content? If not, then the approach you recommend is designed for hand-coding by experts."

As the context of this discussion is one you framed ie "photo-sharing sites" It is highly unlikely any users of such sites will be using a WYSIWYG editor to add text to images. The ARIA attributes would be added to the template by the site developer. The end merely has to add a description or caption or whatever it is labelled as via a text field.

But I do not think it an impossible task to provide a WYSIWIG interface that allows the referencing of an element with an ID value from an image. It is much the same as the for/id attribute relationship between a control and its label. Is this impossible? The editor I use provides a mechanism to do this.

btw
"This is because alternate text should be an equivalent replacement for an image, providing only information that a sighted user can derive from looking at the same image in the same context."

Where did the basis for this statement arise from? While provision of text alternatives for the blind is a major use case for alt="" it is not the only case.

19. Posted by Vlad Alexander
on Saturday 2010-07-31 at 17:11:43 PST

steve faulkner wrote: "There have always been conditional rules when authoring alt text."

Never as complex as you are proposing. Your rules involve additional markup, optional alt attribute and the need for conflict resolution when alt is not empty and ARIA attributes are used.

steve faulkner wrote: "As the context of this discussion is one you framed ie 'photo-sharing sites' It is highly unlikely any users of such sites will be using a WYSIWYG editor to add text to images."

The "Australian Green Tree Frog" example in comment 6 applies to any document. Nevertheless, once the alt attribute is optional for one situation, in the minds of many, it is optional for all situations.

steve faulkner wrote: "But I do not think it an impossible task to provide a WYSIWIG interface that allows the referencing of an element with an ID value from an image."

It might be possible but is it practical and user-friendly? I would still love to see a sketch of such an interface. Including the steps/interface where a non-technical user needs to apply an ID to the element that is going to be referenced by the image properties dialog box.

I wrote: "This is because alternate text should be an equivalent replacement for an image, providing only information that a sighted user can derive from looking at the same image in the same context."

steve faulkner wrote: "Where did the basis for this statement arise from? While provision of text alternatives for the blind is a major use case for alt="" it is not the only case."

I base this statement on my experience and common sense. If you feel this statement is incorrect, please provide a mainstream use-case in order to disprove it. Steve, when writing my articles, I always think of use-cases involving not only people but also machines using the Web.

20. Posted by Andrés Sanhueza
on Saturday 2010-07-31 at 22:58:57 PST

What do you think of the former XHTML2 approach of using the content of an element as a fallback (like object does) instead of an attribute? They even allowed to have a "title" attribute with markup instead (not inside the title attribute, but with a meta tag that contained the "title" content, and the about and property attributes to reference an specific element).

21. Posted by steve faulkner
on Sunday 2010-08-01 at 03:28:53 PST

"Never as complex as you are proposing. Your rules involve additional markup, optional alt attribute and the need for conflict resolution when alt is not empty and ARIA attributes are used."

These are not rules I am proposing they have been proposed by the W3C web accessibility initiative coordination group after months of discussion on how to find an acceptable compromise between optional alt attribute and mandatory alt attribute (for the purposes of HTML5 conformance).

WAI CG Consensus Resolutions on Text alternatives in HTML 5
http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html

"and the need for conflict resolution when alt is not empty and ARIA attributes are used."

no need for 'conflict resolution' ARIA always overrides, that is what the ARIA spec says and what browsers are implementing.

22. Posted by Vlad Alexander
on Sunday 2010-08-01 at 08:22:18 PST

Andrés Sanhueza wrote: "What do you think of the former XHTML2 approach of using the content of an element as a fallback (like object does) instead of an attribute."

Speaking in general terms, HTML has adequate facilities for alternate content for images. This can be improved by "using the content of an element as a fallback (like object does) instead of an attribute."

steve faulkner wrote: "... after months of discussion on how to find an acceptable compromise between optional alt attribute and mandatory alt attribute (for the purposes of HTML5 conformance)."

This compromise compromises accessibility. In fact, this compromise is not a compromise on the part of HTML5 team at all. They get their optional alt attribute and they don't care if add-on markup is used such as ARIA. The HTML5 team's approach to accessibility is: we gave you ARIA so leave us alone on markup.

Steve, this article demonstrates that there is no need for an optional alt attribute. Anyone is free to use the ideas from this article to negotiate a real compromise with the HTML5 team (if that is even possible).

23. Posted by steve faulkner
on Sunday 2010-08-01 at 10:11:04 PST

Hi Vlad

"This compromise compromises accessibility. In fact, this compromise is not a compromise on the part of HTML5 team at all. They get their optional alt attribute and they don't care if add-on markup is used such as ARIA. The HTML5 team's approach to accessibility is: we gave you ARIA so leave us alone on markup."

I would request that you curtail the hyperbole.

Further options for the provision a programmatically associated text alternative is a win for accessibility. The alt attribute is not always the best way to provide a text alternative. For the "photo sharing site" use case figure/caption is a good alternative method to provide a text alternative and until it is implemented in browsers and AT, using ARIA to plug the gap is the right thing to do.

"Steve, this article demonstrates that there is no need for an optional alt attribute."

I am not convinced it does, and I think you conflate an optional alt attribute with an optional text alternative, the two are not equivalent. the alt attribute is just one type of programmatic container for a text alternative and a pretty limiting one at that.

24. Posted by R.B.
on Sunday 2010-08-01 at 16:40:31 PST

>using ARIA to plug the gap is the right thing to do.

I don't think we need any more temporary plugs that inevitabley become permanent.

>I think you conflate an optional alt attribute with an optional text alternative

I think _many_ people will make this mistake. it's too fine a distinction. If you believe Vlad is making such a mistake, can you imagine what less technical people will do.

As a compromise, how about an empty alt attribute and an association with description text like so:

<img src="dog.png" alt="" aria-labelledby="cap1"><br /><span id="cap1">Big dog</span>

<img src="dog.png" alt="" id="dog1" /><br /><span for="dog1">Big dog</span>

25. Posted by steve faulkner
on Monday 2010-08-02 at 01:40:04 PST

Hi RB

RB wrote:
"I don't think we need any more temporary plugs that inevitabley become permanent."

If you do not want to use ARIA to provide accessible relations between elements, then its your choice as an author.

RB wrote:
"I think _many_ people will make this mistake. it's too fine a distinction. If you believe Vlad is making such a mistake, can you imagine what less technical people will do."

So your answer it to bind and ossify the provision of text alternatives to one attribute, I don't agree that this is the way forward.

"As a compromise, how about an empty alt attribute and an association with description text like so:"

alt="" is being implemented as equivalent to the ARIA role="presentation" this means that the img role will be removed from the accessible DOM tree by the browser. So what have is an association to nothing. it doen't work.

26. Posted by R.B.
on Monday 2010-08-02 at 07:25:26 PST

>If you do not want to use ARIA to provide accessible relations between elements, then its your choice as an author.

Your response is insulting Steve. The discussion is not about me. The discusion is about a crappy design for alternate text.

>So your answer it to bind and ossify the provision of text alternatives to one attribute, I don't agree that this is the way forward.

One attribute worked fine for years and still continues to work now. Can you provide a list of user complaints that show a need for _breaking_ the way alt works now?

>alt="" is being implemented as equivalent to the ARIA role="presentation" this means that the img role will be removed from the accessible DOM tree by the browser.

Don't do that. Don't bend and twist alt to fit the ARIA notations of accessibility. Let screen readers pick up image from DOM and deal themselves with alt=""

>So what have is an association to nothing. it doen't work.

Prove that you need this association in the first place. Then figure out a way to do this without breaking alt text.

27. Posted by R.B.
on Monday 2010-08-02 at 10:36:38 PST

The following should illustrate what can happen when _template_ sites like Flickr associate images with content elsewhere in the document:

<h1 id="heading">Does it get any better than this?</h1>

<img aria-labelledby="heading">

It's _absurd_ to use aria-labelledby in place of alt and _automatically_ associate image with content elsewhere in document.

28. Posted by steve faulkner
on Monday 2010-08-02 at 12:16:40 PST

hi RB

"Your response is insulting Steve."

That was not my intention and I am sorry you took it this way.

"The discussion is about a crappy design for alternate text."

I do not think you have shown that it is 'crappy design'. aria-labelledby and aria-describedby are not designed specifically to provide text alternatives for img elements, but they can be used for this purpose. They are designed as a general mechanism to associate content from one element with another.

>One attribute worked fine for years and still continues to work now. Can you >provide a list of user complaints that show a need for _breaking_ the way alt >works now?

How is providing a text alternative via another mechanism other than the alt attribute "breaking the way alt works now"?

"Don't do that. Don't bend and twist alt to fit the ARIA notations of accessibility. Let screen readers pick up image from DOM and deal themselves with alt="""

Not all screen readers pick up information by accessing the DOM directly (voiceover for example) they access it via an accessibility API. What is being twisted? alt="" has signified a way to indicate to AT that the image can be ignored its meaning is merely be formalised as part of the process of HTML standardization.

"Prove that you need this association in the first place. Then figure out a way to do this without breaking alt text."

breaking alt text??

"The following should illustrate what can happen when _template_ sites like Flickr associate images with content elsewhere in the document:"

is this something you found or made up?

<h1 id="heading">Does it get any better than this?</h1>

<img alt="Does it get any better than this?">

This is just just as bad, its not the method that is the issue it's the quality of the text.

29. Posted by R.B.
on Monday 2010-08-02 at 13:52:33 PST

>How is providing a text alternative via another mechanism other than the alt attribute "breaking the way alt works now"?

In order to provide alt via another mechanism, you have to break the rules of how alt works now. Now it is always required. This rule needs to be broken and alt made optional in order to support the other mechanism.

>Not all screen readers pick up information by accessing the DOM directly

What's your point? You brought up DOM as an issue.

>is this something you found or made up?

Got example from here and changed wording:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#aria-labelledby_Attribute

>This is just just as bad

<h1 id="heading">Does it get any better than this?</h1>

<img alt="Does it get any better than this?">

Yes, but this article says don't do that.

> its not the method that is the issue it's the quality of the text.

No, it's the _method_. You said above "The ARIA attributes would be added to the template by the site developer." In other words, image _automatically_ associated with other content. This article says write caption/description _manually_ for images. You ssee, it's the method that is different and as result you get better quality of text.

30. Posted by steve faulkner
on Tuesday 2010-08-03 at 02:36:01 PST

hi RB

"In order to provide alt via another mechanism, you have to break the rules of how alt works now. Now it is always required. This rule needs to be broken and alt made optional in order to support the other mechanism."

Yes it is always required in (HTM4/xhtml) but more often than not on sites like flickr a text alternative is either absent or of extremely poor quality or what is provided is semantically a label or caption. Providing methods to add a caption or label when that is all is available is better than providing only a container (alt) for what should be a good text alternative not a caption or label.

WCAG 2.0 does not require use of the alt to provide a text alternative, it only requires that you provide a text alternative.

"What's your point? You brought up DOM as an issue."

I was responding to this statement you made: "Let screen readers pick up image from DOM and deal themselves with alt=""""

"Yes, but this article says don't do that."

poor quality text alternative is going to be a poor quality text alternative regardless of the method used to provide it.

"No, it's the _method_. You said above "The ARIA attributes would be added to the template by the site developer." In other words, image _automatically_ associated with other content."

Yes in exactly the same way the that alt attribute text is added to images take a look at this example from flickr: http://www.flickr.com/photos/zz77/3280996694/

Its not the method.

"This article says write caption/description _manually_ for images. You ssee, it's the method that is different and as result you get better quality of text."

The method advocated in this article promotes a practice that hides the image from some users while at the same time providing a caption for the image it is hiding. What are screen readers expected to do honour the presence of alt="" by not announcing the presence of an image to users unless they vist a photo sharing site?

Anyway, it is obvious you have strong views on this subject and therefore I urge you (and anyone) to join the W3C HTML working group, a forum in which you can have an impact on the outcomes of HTML standardization in respect to the alt issue.

You may also like to provide feedback on the document I am editing on text alternatives (linked in comment 9 above)

31. Posted by Laura
on Saturday 2010-08-07 at 03:32:13 PST

Start of a HTML working group discussion thread on specific points of controversy relating to the alt issue:
http://lists.w3.org/Archives/Public/public-html/2010Aug/0073.html

Please consider contributing to the deliberations there to advance ideas that you feel strongly about.

32. Posted by JF
on Friday 2010-08-13 at 19:00:02 PST

RB Wrote:
"In order to provide alt via another mechanism, you have to break the rules of how alt works now. Now it is always required."

RB,

OK, so first of all, what "rule" are you talking about? The HTML 4/XHTML 1 specification regarding the image element? WCAG 1? WCAG 2? Section 508? A different accessibility requirements specification?

All of the above's "rules" regarding alternative text all state that alt text must be required, yet are routinely broken today by sites and authors who do not supply alternative text for their images. And what happens? Why the image still displays in the browser! We can argue all we want about whether this is a good thing or a bad thing (and I have argued for draconian fail in the past), but the reality is that "broken" images exist on the web today, and will continue to exist on the web tomorrow, next year, and likely from here to the end of time. The absolute best we can say is that a page that contains an image without some alternative text for non-sighted users is 'non-conformant' (in HTML5 language) or non-valid (in HTML 4 language) - but if a content author doesn't care, what are we to do? Rightly or wrongly the browsers have chosen to still render the image - browsers in fact do error handling all the time: have improperly nested tags? That's against the rules too, but still, it 'works' in the browser, and will continue to do so in HTML 5, HTML 6 and likely HTML 15. That ship has sailed, and either you're on it, or standing on the dock...

HISTORY:
Early on, screen reading software settle on the fact that alt="" would silence the screen reader from trying to guess what the image was, as the best guess alternative was to announce the file name: "Image: 34trgui89 dot jay-peg" (that's *REALLY* broken, but the image would still display on screen)

Enter ARIA, and the role="presentation" value, which, for the purposes of screen readers delivers the same net result: it does not read out any information about the image, as the author has *specifically* marked the image as being decorative only. Using either alt="" OR aria-role="presentation" is functionally the same. Now if an author posts a picture of *you*, but adds alt="" they have technically satisfied a 'rule', but the net effect is that blind users still doesn't know that it is a picture of you.

...continued...

33. Posted by JF
on Friday 2010-08-13 at 19:01:14 PST

TODAY / HTML5
So now what should we do? Is there other programmatic ways that we can somehow convey to the end user that the picture of RB on this page, is in fact, a picture of RB? This is what the HTML5 Accessibility Task force has set out to solve.

TO BE ABSOLUTELY CLEAR, AUTHORS *SHOULD* PROVIDE APPROPRIATE ALTERNATIVE TEXT, and by far the best way to do so is by using the alt attribute, but if at the end of the day the important information that the picture on the page is that of RB is conveyed to non-sighted users, who really cares how we got there? Do blind users really care? I doubt it very much, they just are happy that they know (and if that sounds in any way condescending it is not meant to). Practical outcomes trump technical purity 7 days a week (certainly for the numerous blind and disabled users I have worked with over the years), and *that* is what we should be striving for. Getting overly religious about methodology stalls progress on the larger front - it's like insisting that you must eat your salad before your main course, because the "rules" of Fine Dining say so. You want to eat your steak before your salad? Go for it because the important thing is that you are hungry and that you need to eat - the 'rule' about which order you eat in is an artificial and arbitrary rule that has no practical outcome on your hunger.

And so, the current WAI recommendation to the HTML5 Working Group states that *IF* soup, salad or steak is on the table, you may begin to eat (uh, actually it states *if* an image contains one of:

@alt is present (empty or non-empty) OR
@aria-labelledby is present (non-empty only) OR
the <img> is located within a <figure> that has a non-empty <legend> OR
@role="presentation"

*THEN* it can be considered conformant or valid.)

However the proposal makes no determination of the *value* of the text string, but it states that any of the above conditions can be a programmatic method of associating a text description to an image (or in the case of role="presentation" marking the image as not-to-be-announced in screen readers, which is another way of authoring alt="").

But here's the important take-away: no matter what the method used to associate a text description to an image, it is the quality of the text description that is most important: if I tear up yesterdays newspaper and put it in a bowl and tell you it's salad, well...

As you rightly noted, this:

<h1 id="heading">Does it get any better than this?</h1>

<img aria-labelledby="heading">

...really doesn't do much for the end user, but not because of the association mechanism, but because of the *value* of the text being associated to the image is of poor value. Complaining that this is somehow the new proposal's fault places the blame in the wrong place: Flickr should be a) allowing photo-uploaders an ability to "tag their photos" for blind users, and as a fall back perhaps look to other auto-generated data instead (when the user doesn't 'tag' their photo) - perhaps something like "Photo 215 of RB's Photo stream". Now granted, this still doesn't tell the blind user what the picture is about, but it is unique and factual information about the image which the blind user can use in constructive ways: remember at this point we're talking about fall-back - Flickr *ABSOLUTELY* should provide a means for photographers to better 'tag' their photos for screen readers. However that is a short-coming of Flickr, not of HTML5, HTML 4, or the draft proposal on alternatives to the alt attribute.

...continued...

34. Posted by JF
on Friday 2010-08-13 at 19:01:41 PST

SO...
It's frustrating when we perceive slippage, and somehow the idea of @alt being more loosely 'policed' seems somehow wrong. I get it, I got it a long time ago. But finding workable solutions to real problems means being able to stretch outside of the box, and I honestly believe the current proposal will improve things for screen reader users (otherwise I would have never suggested it in the first place: http://www.w3.org/html/wg/wiki/IssueAltAttribute#Explicitly_Noted_Alternatives_Via_Multiple_Methods)

RB, you are obviously passionate about this. May I suggest you take that wonderful passion, and focus it on teaching authors about the importance of GOOD alternative text, and less on how they must associate it to the image? Honestly, that will deliver the bigger pay-off to those users who need that alt text.

Cheers!

35. Posted by Vlad Alexander
on Friday 2010-08-13 at 21:53:49 PST

JF wrote: "May I suggest you take that wonderful passion, and focus it on teaching authors about the importance of GOOD alternative text, and less on how they must associate it to the image?"

JF, this is very unprofessional behaviour and shows arrogance on your part. All participants of this blog have just as much right to voice their opinions on how future standards should be developed/implemented as you do.

Comments are closed for this article.

Rebuilding The Web