What should be the minimum / maximum length of alternate text?

Different guidelines recommend different maximum lengths for alternate text. Some recommend 80, 100, or 150 characters. Some have even calculated different maximum lengths based on language (e.g. 100 for English versus 115 for German). Some accessibility checkers also raise warnings if alternate text is too short. So what should be the minimum and maximum lengths for alternate text?

It's a trick question

It's a trick question because alternate text should be as long as is necessary. After all, alternate text is part of the document content. As such, the content author, not an arbitrary number, should determine its length. Alternate text should be as short or as long as is necessary to provide a substitute for an image within the image's specific context (i.e. surrounding text). Putting undue length restrictions on alternate text can undermine the quality of alternate text, limit the amount of information conveyed to readers, and can affect the style of writing in a way that inhibits comprehension.

Diminishing quality

How do you feel when you write alternate text? This seems like a strange question to ask, but how you feel about a task often affects your performance of that task. Take for example the following dialog box, where text field length encourages short alternate text:

Alternate text field shows 15 characters of text, the rest is hidden from view.

Would you feel restricted? Would you feel pressured to write something really short? Would you be tempted to give the alternate text a cursory effort, instead of composing something equal in quality to the rest of your document?

Limiting information conveyed

Below is a very simple flowchart.

The flowchart contains a start step, two conditional steps and three output steps.

In one possible usage of the above image, the alternate text might read:

If the lamp doesn't work, check if it's plugged in. If not, plug it in. If it's plugged in and still doesn't work, check if the bulb is burned out. If it is, replace the bulb. If it still does not work, buy a new lamp.

This succinct alternate text is 218 characters long, exceeding all maximum length guidelines. Yet you could not shorten this alternate text to half its length without sacrificing key information. For more complex flowcharts, it's even clearer that restrictions on alternate text length can lead to loss of essential information.

Affecting style

Length restrictions for cell phone text messages and Twitter messages have changed writing styles. The writing has become terse, abrupt even. In the same way, alternate text made terse by extraneous guidelines will inevitably sound like machine language, upsetting the style and tone of the document wherever the alternate text is inserted.

Conclusion

Putting undue length restrictions on alternate text can diminish the quality of alternate text, limit the amount of information conveyed to readers, and affect the style of writing to a point where it inhibits comprehension. Regardless of what guidelines say, alternate text should be as long as necessary to fulfill its function, which is to provide an equivalent substitute for an image within a given context. The result will be more accessible content.

Public comments

1. Posted by steve faulkner
on Friday 2010-08-06 at 12:34:05 PST

Hi Vlad,
There should be no restrictions on the length of a text alternative, write however much is needed to provide something useful. Unfortunately the same cannot be said for providing a text alternative using the alt attribute, as long strings of text are not handled well by screen readers (so I have been told) and do not display well in browsers. Also you cannot structure text in an alt attribute. A friend of mine who is blind said what he wants to be provided via the alt attribute is a 'cognitive thumbnail' of what's in an image with a longer description programmatically associated with the image if the image requires it.

2. Posted by Vlad Alexander
on Friday 2010-08-06 at 19:21:06 PST

steve faulkner wrote: "...long strings of text are not handled well by screen readers (so I have been told) and do not display well in browsers."

Hey Steve! To me, that is backwards. We should not alter authoring behaviour to suit the temporary limitations of screen readers and browsers. These limitations can be easily fixed if vendors are properly motivated.

steve faulkner wrote: "Also you cannot structure text in an alt attribute."

That is something HTML5 team can fix.

steve faulkner wrote: "A friend of mine who is blind said what he wants to be provided via the alt attribute is a 'cognitive thumbnail' of what's in an image with a longer description programmatically associated with the image if the image requires it."

He may not understand the purpose of alternate text, which is to serve as a textual substitute for an image within a given context. Try his idea in this simplified example (the idea behind this markup can be applied to more complex examples):

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

Your friend's idea will look something like:

I <img src="heart.png" alt="small heart icon" longdesc="file.htm" /> you!

I <img src="heart.png" alt="small heart icon" aria-describedby="abc" /> you!
love

3. Posted by steve faulkner
on Saturday 2010-08-07 at 05:46:01 PST

hi Vlad,

vlad wrote:
"To me, that is backwards. We should not alter authoring behaviour to suit the temporary limitations of screen readers and browsers. These limitations can be easily fixed if vendors are properly motivated."

Ideally this may be the case, but in practice authors have to write their code taking into account many limitations and workarounds for errant browser behaviour. What i want to ensure if i am providing a text alternative is that it coded in such a way that it is unambiguously available to any person that requires it.

steve faulkner wrote: "Also you cannot structure text in an alt attribute."

vlad wrote: "That is something HTML5 team can fix."

the figure/figcaption elments go some way to fixing this.

vlad wrote: "He may not understand the purpose of alternate text, which is to server as a textual substitute for an image within a given context."

I think maybe i did not explain the context of his comments, anyway here is a link to the email for you to read his comments first hand. http://lists.w3.org/Archives/Public/wai-xtech/2010Jun/0002.html.

PS think your third example would be OK if 'love' was the alt attribute text and 'small heart icon'' was referenced by the aria-describedby.

4. Posted by Vlad Alexander
on Saturday 2010-08-07 at 08:02:25 PST

Steve, in the email you referenced, Gregory J. Rosmaita describes alternate text as a "brief 'at a glance' or 'congnative thumbnail'". This is incorrect description because it implies that images within a document are standalone pieces of content. In other words, one could pluck out an image from a document, read its alternate text and get an idea of what the image looks like. Within a document, visual and textual view of an image can only be fully understood within a given context (i.e. surrounding text). In other words, it is context that dictates what text should be written for alternate text.

In the same email, Gregory writes: "alt text needs to be terse for a number of reasons, including usability, extremely limited viewports, small amount of video 'real estate' (iPad and smaller devices) etc."

Alternate text is document content. Writing parts of the document content in a terse manner can cause comprehension issues. For example, say I copy and paste a document that contains images into a plain text email. Alternate text is pasted into the email in place of the images (which is correct behaviour). The recipient of the email gets a text only view of the document with no indication that it originally contained images. Because some parts of the document are written well and some are written in a terse manner, comprehension problems can arise. As for viewports and real estate issues, alternate text should not be displayed within the dimensions of the image. Alternate text should be displayed like any other text within the parent element. So if small screen devices can display long documents (which they do), then they can surely display long documents with long alternate text.

5. Posted by steven faulkner
on Monday 2010-08-09 at 00:04:38 PST

Hi Vlad,

you wrote:

"This is incorrect description because it implies that images within a document are standalone pieces of content. In other words, one could pluck out an image from a document, read its alternate text and get an idea of what the image looks like."

I don't think this is what gregory is saying at all, what I think he is saying is that he does not want a long text alternative in a short text alternative container. Sighted users can glance at an image as they scan a web page, or they can concentrate on an image, he wants to be able to do something similar when accessing a page using a screen reader.
a short text alternative contained within the alt attribute a more complete text alternative (if needed) in a programmatically associated container which he can access if desired.

6. Posted by Vlad Alexander
on Monday 2010-08-09 at 07:01:19 PST

steven faulkner wrote: "I don't think this is what gregory is saying at all, what I think he is saying is that he does not want a long text alternative in a short text alternative container."

Having two "text alternatives" is a flawed concept (i.e.: bad design). This failed with longdesc and will fail with what you call programmatically associated text alternative. Steve, since Gregory is your friend, could you ask him to participate in this conversation so that we do not need to guess what he actually means.

steven faulkner wrote: "Sighted users can glance at an image as they scan a web page, or they can concentrate on an image, he wants to be able to do something similar when accessing a page using a screen reader."

He is not seeking alternate text; he is seeking a description of an image. This description can be placed into the title attribute. When sighted users glance at a page, they do not perceive context for images so they are seeing a description of the image. For example, through a glace, they perceive "pretty dog", "dialog box", "a simple flowchart", etc. This is not alternate text. By reading text surrounding images (context), the sighted users' perception of the images changes because they understand the function these images serve. So instead of "pretty dog", they see "A dog desperately looking for his ball." Instead of "dialog box", they see "Properties dialog box with the option 'Clear cache' checked.". Instead of "simple flowchart", they see "If the lamp doesn't work, check if it's plugged in...". And in a different context, sighted users would perceieve something completely different for the same images.

Steve, I really don't get the concept or the need for what you describe as "text alternative" which may or may not need to be programmatically associated. What is so "alternative" about text that is always available in the document? Where are the use-cases that demonstrate the need for this?

7. Posted by steve faulkner
on Monday 2010-08-09 at 08:05:13 PST

Hi vlad,
you wrote:
"Having two "text alternatives" is a flawed concept (i.e.: bad design). This failed with longdesc and will fail with what you call programmatically associated text alternative."

I disagree, the concept is not flawed because the implementation you cite was flawed. Every accessibility API has the concept and provides properties for short and long descriptors which are programmatically associated with an object.

" they do not perceive context for images so they are seeing a description of the image."

I did not say "glance at the page" I said glance at an image as they scan the page. Sighted users can take in context and details in milliseconds from images, users who rely on speach output cannot.

I have pointed gregory to this discussion.

vlad wrote:

"Steve, I really don't get the concept or the need for what you describe as "text alternative" which may or may not need to be programmatically associated. What is so "alternative" about text that is always available in the document? Where are the use-cases that demonstrate the need for this?"

the following provide examples and use cases:
http://webaim.org/techniques/images/longdesc
http://dev.w3.org/html5/alt-techniques/#graphical-representations
http://dev.w3.org/html5/alt-techniques/#images-enhance

8. Posted by Vlad Alexander
on Monday 2010-08-09 at 08:56:53 PST

steve faulkner wrote: "Every accessibility API has the concept and provides properties for short and long descriptors which are programmatically associated with an object."

"descriptors" is not alternate text.

steve faulkner wrote: "Sighted users can take in context and details in milliseconds from images..."

Context comes from surrounding text, not from the image itself. You have to read surrounding text to understand the function of an image.

steve faulkner wrote: "the following provide examples and use cases..."

These are examples, not use-cases. I do not understand why this type of markup is necessary. I do not understand what problem this makrup solves. And I do not understand what is so "alternative" about text that is always available in the document.

9. Posted by Alan Smithie
on Monday 2010-08-09 at 09:55:55 PST

Your flowchart alternative text example is flawed.

You do not need to describe in detail the alternative text if you provide a quality image description within the body content accompanying the image. In other words, instead of saying this in the ALT text:

"If the lamp doesn't work, check if it's plugged in. If not, plug it in. If it's plugged in and still doesn't work, check if the bulb is burned out. If it is, replace the bulb. If it still does not work, buy a new lamp."

Change it to:

"A small flowchart describing a process of whether a lamp is working or not."

In the body text accompanying the image, describe the details of the image similar to what you originally had at the ALT text.

10. Posted by Vlad Alexander
on Monday 2010-08-09 at 10:30:09 PST

Alan Smithie wrote: "You do not need to describe in detail the alternative text if you provide a quality image description within the body content accompanying the image."

You are partly correct because what you are describing is context for the image. However, here is an example where your alternate text does not work because it unnecessarily repeats content found elsewhere in the document:

Below is a small flowchart describing a process of whether a lamp is working or not. If the lamp doesn't work, check if it's plugged in. If not, plug it in. If it's plugged in and still doesn't work, check if the bulb is burned out. If it is, replace the bulb. If it still does not work, buy a new lamp.
<img src="flowchart.png" alt="A small flowchart describing a process of whether a lamp is working or not." />

In the above example, the appropriate alternate text should be no alternate text at all (blank alt attribute) or some can argue it can be simply "Flowchart". So you cannot say if alternate text is appropriate or not without reading the surrounding text (context). Here is another example that will demonstrate how your alternate text "A small flowchart describing a process of whether a lamp is working or not." will not work within a given context:

My diagram creating software always uses a standard set of colors for flowcharts:
<img src="flowchart.png" alt="Start step is pink, decision steps are yellow and end steps are green." />

11. Posted by steve faulkner
on Monday 2010-08-09 at 12:43:31 PST

hi vlad
your wrote:
"descriptors" is not alternate text."

This is you take on what a text alternative is I have a different take which is the one detailed in WCAG 2.0 http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html#text-altdef

vlad wrote:
"These are examples, not use-cases. I do not understand why this type of markup is necessary. I do not understand what problem this makrup solves."

"It must also be possible for people using assistive technologies to find these text alternatives when they encounter non-text content that they cannot use. To accomplish this, we say that the text must be "programmatically associated" with the non-text content. This means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use)."

source: http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-text-alternatives-head

" And I do not understand what is so "alternative" about text that is always available in the document."

I don't understand your point. If a piece of text explains a concept represented visually in a non text object, then its a text alternative to the non text content, what is not alternative about that?

12. Posted by Vlad Alexander
on Monday 2010-08-09 at 19:24:29 PST

steve faulkner wrote quoting WCAG: "It must also be possible for people using assistive technologies to find these text alternatives when they encounter non-text content that they cannot use. To accomplish this, we say that the text must be "programmatically associated" with the non-text content. This means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use)."

This is not a use-case. Why are you unable or unwilling to produce a use-case? This is a broad statement open to different interpretations. This statement covers the alt attribute that is programmatically associated with the img element. Why do you need a different method such as no alt with ARIA attributes?

Steve, you are the editor of HTML5: Techniques for providing useful text alternatives. As such, one would expect you to be able to produce a use-case that describes the problem, shows how current use of alt attribute is inadequate to address the problem, explain how the proposed solution addresses the problem better than the alt attribute, and discuss the consequences of using such an approach.

13. Posted by steve faulkner
on Tuesday 2010-08-10 at 01:50:55 PST

hi vlad,

"This statement covers the alt attribute that is programmatically associated with the img element. Why do you need a different method"

For the situations where alt is an insufficient container for the text alternative.

I have provided examples of such situations, but you do not appear willing to accept them as legitimate, but you have not provided any argument as to why.

The problem: when the alt attribute is an inadequate method to provide a programmatically associated text alternative how does the author achieve this requirement?

why is the alt inadequate:
cannot provide structured text alternative using it.

"Why do you need a different method such as no alt with ARIA attributes?"

This question has been done to death in your previous post.

14. Posted by Vlad Alexander
on Tuesday 2010-08-10 at 08:55:19 PST

steve faulkner wrote: "For the situations where alt is an insufficient container for the text alternative."

Use this premise as the basis for a use-case. Explain why alt is an insufficient container by providing an example where a user is not able to get sufficient information from alt and therefore needs a different container. Explain how a user-agent (screen reader, browser with image rendering disabled, search engine, etc.) is supposed to read/display/process the programmatically associated alternative text found elsewhere in the document.

steve faulkner wrote: "I have provided examples of such situations, but you do not appear willing to accept them as legitimate, but you have not provided any argument as to why."

I am willing to try again. Please include these examples in the use-case. Let's have one place (a use-case document) where everything regarding this issue is readily accessible.

steve faulkner wrote: "why is the alt inadequate: cannot provide structured text alternative using it."

You need to show a need for structured alternate text and show how user-agents should process it. For example, img is an inline element. If programmatically associated text alternative contains block elements, how should the user-agent read/display/process this?

15. Posted by Gregory J. Rosmaita
on Tuesday 2010-08-10 at 12:31:28 PST

when steven faulkner wrote of my previously posted comments cited earlier, he was correct when he stated: "he [gregory] does not want a long text alternative in a short text alternative container. Sighted users can glance at an image as they scan a web page, or they can concentrate on an image, he wants to be able to do something similar when accessing a page using a screen reader."

as an end user, i need access to BOTH terse and verbose descriptors; every user benefits from access to such information, and it need not be -- nor should it be -- an either/or boolean choice for the user to have either exposed, first, by user defined setting, and, second, via a toggle key -- the information in the long descriptor may be contained in an externally referenced document, but there is no reason why that content cannot be exposed to the user simultaneously -- for example, the longdesc as hrefdesc technique for simultaneous presentation of the image, its label and its description inline is but 1 means of providing as robust a user experience as possible; for extended discussions on this topic, consult: http://www.w3.org/html/wg/wiki/LongdescRetention

as an end user, i should be able to get a quick overview of the document (in which i would like graphics reported as alt text values) before deciding whether to dive further into that document or not; this sort of capability will be increasingly easy for an AT to provide through the use of WAI-ARIA markup; using your response to alan smithie, i would amend your example code to read:

<img src="flowchart.png" alt="How to tell if a lamp is working." aria-describedby="flowchart-desc1" aria-labelledby="flowchart-desc1-label" />
How to tell if a lamp is working. If the lamp doesn't work, check if it's plugged in. If not, plug it in. If it's plugged in and still doesn't work, check if the bulb is burned out. If it is, replace the bulb. If it still does not work, buy a new lamp.

please note two things: 1) i used both @alt and @aria-labelledby, for until @alt is mapped to @aria-labelledby, it is needed for backwards compatibility -- note that the @alt value and the aria-labelledby values are identical; and 2) i shortened @alt/labelledby text string -- there is a clearer means of providing a terse descriptor (also an accessibility/usability concern) -- as your alt value is unecessarily long (probably to prove your point), but i don't care if the information is contained in a flowchart or a flowerpot -- that is extraneous information; also, since the lamp seems to have but 2 states ("on" and "off") the phrase "or not" is also superfluous...

as for the heart graphic example it is simply fallacious -- there is no doubt in the example that the graphic is being used explicitly to signify a specific word, which in the use case you cited is: "love"

16. Posted by steve faulkner
on Tuesday 2010-08-10 at 12:33:04 PST

Hi Vlad,

"Explain how a user-agent (screen reader, browser with image rendering disabled, search engine, etc.) is supposed to read/display/process the programmatically associated alternative text found elsewhere in the document."

First you were asking for use cases, now you are asking for start to end process details, which are not use cases.

I have pointed to examples from http://dev.w3.org/html5/alt-techniques/ which are illustrative of the sorts of authoring scenarios encountered by authors, you have dismissed them.

You are asking me to provide a use case for wanting structured content, It is exactly the same use case for wanting to mark up text alternatives as it is for any other content on a web page. Why would an author NOT want to structure content, that when structured, becomes easier for users to comprehend?

You appear not to believe that long descriptions for image may be necessary in some circumstances.
This article is worth a read in reference to long descriptions:

"In academia, we encounter images like this all the time. Our journal articles, curricula, reports and presentations, etc. are all filled with graphs, charts, diagrams, and figures that are filled with tons of information."
http://terrillthompson.blogspot.com/2009/09/long-descriptions-of-images.html

You are asking me to provide a use case document... There is a document (in prgress) containing lots of information about alt and how to use it, the pros and cons of various methods of providing text alternativers and examples, it's available here http://dev.w3.org/html5/alt-techniques/ I encourage you to file bugs against any of the content there in which you do not agree with or about content which you think is missing.

17. Posted by Vlad Alexander
on Tuesday 2010-08-10 at 14:13:26 PST

steve faulkner wrote: "First you were asking for use cases, now you are asking for start to end process details, which are not use cases."

What a novel idea! Thinking through from "start to end" before advocating a given technique.

steve faulkner wrote: "I have pointed to examples..."

None of which answer the question why no alt and ARIA attributes approach is necessary.

steve faulkner wrote: "Why would an author NOT want to structure content, that when structured, becomes easier for users to comprehend?"

1. Structured content containing block elements such as h1 to h6, table, dl, ol, ul, etc., may not be practical to implement within an inline element such as img. Think how user-agents are going to read/display/process such content in place of img.

2. It may not be practical to create an authoring interface to build such programmatic relationships.

3. Comprehension problems can occur because you may be duplicating content for some users. For example:

<h1 id="heading">wind dog</h1>
<img aria-labelledby="heading">

What should a screen reader speak or Web browser (with image rendering turned off) display? Is it duplicate content such as: "wind dog wind dog"?

4. Adding loopholes and/or more techniques for text alternatives is a complexity that may result in confused and lost authors. The more choices you give people, the harder it is for them to choose, and the more likelihood of them getting it wrong.

steve faulkner wrote: "I encourage you to file bugs..."

I am not getting involved in a process I do not trust. I speak my mind on my blog. Anyone is free to use my ideas to file bug reports if they find them useful.

Gregory J. Rosmaita wrote: "as an end user, i should be able to get a quick overview of the document (in which i would like graphics reported as alt text values) before deciding whether to dive further into that document or not"

What's involved in this "quick overview of the document"? Would you like to instruct a screen reader (or another device) to give you a list of images the document? If so, alternate text will not be very meaningful to you in this scenario. Alternate text is not very useful without context (surrounding text).

Gregory J. Rosmaita wrote: "as an end user, i need access to BOTH terse and verbose descriptors"

Fine. But these descriptors are not alternate text. The information you need should be stored in the title attribute or there should be a new attribute for the img element such as shortdesc. What you need is a description, not alternate text.

18. Posted by steve faulkner
on Tuesday 2010-08-10 at 14:52:32 PST

hi vlad,

vlad wrote:
"What a novel idea! Thinking through from "start to end" before advocating a given technique."

very sarky, not very helpful. Can you explain why you are still advocating a technique that provides a caption for something that is hidden from some users?

you wrote:
"None of which answer the question why no alt and ARIA attributes approach is necessary."

This is not about the ARIA with no alt approach it is about alt text length no? although you want to keep going back to the ARIA approach that bothers you so. In http://dev.w3.org/html5/alt-techniques/ there is not a single example of aria with no alt. The ONLY place that no alt is emntioned is http://dev.w3.org/html5/alt-techniques/#unknown in reference to use of the figure/figcaption.

vlad wrote:
"Structured content containing block elements such as h1 to h6, table, dl, ol, ul, etc., may not be practical to implement within an inline element such as img. Think how user-agents are going to read/display/process such content in place of img."

That is the whole reason why it is sometimes required to provide a text alternative somewhere else on the page or another page and provide a pointer (programmatically associate) from the image to the images text alternative, this can be as simple as a link (for example: http://dev.w3.org/html5/alt-techniques/#hav)

your wind dog example (like your heart example) is oversimplified and fallacious and designed not to be a realistic example but one purely created to reinforce your arguments.

"I am not getting involved in a process I do not trust."
fair enough.

19. Posted by Gregory J. Rosmaita
on Tuesday 2010-08-10 at 16:17:57 PST

vlad wrote:

QUOTE
Structured content containing block elements such as h1 to h6, table, dl, ol, ul, etc., may not be practical to implement within an inline element such as img. Think how user-agents are going to read/display/process such content in place of img
UNQUOTE

your how to tell if the lamp is working flowchart is an example of content that would greatly benefit from structured content -- in this particular case, an ordered list (OL) listing, in numbered steps, the measures to take to ascertain if the lamp is working or not... as far as the instructions are concerned, i'd have to feel the lightbulb for them to work for me, and since i have a neuropathy in my fingers/hands, i can't think of an alternate appendage i'd want to use to check by heat if a lightbulb is turning on and off...

out of curiosity, if one wishes to present such information to a user in a graphical mode such as a flowchart, why not set a cascade for displaying content as SVG instead of forcing the load of a PNG image?

20. Posted by Andrew Downie
on Tuesday 2010-08-10 at 16:40:54 PST

The following is a rambling piece, for which apologies are extended. It is intended to be conciliatory rather than inflammatory. While some of the intricacies on both sides escape me without further digestion, as a screen reader user I wish that the vast majority of people who write alt attrributes would apply anything like as much thought to their use as the preceding authors. I have no major problem with long alt attributes as such, provided the information is useful. Screen readers provide facilities for skipping around material quite quickly. One concern, touched on by Alan, is the heavy reliance on images. While Vlad's original alt attribute is fine for my purposes, it should be available for all visitors. For completeness, it's perhaps of some value to me to know there's a flowchart there. As was drummed into us when doing stats at uni, graphs and charts should also be described textually (one marker criticised me for not using enough charts). I do like Vlad's "I love you" example. In such a case, reading "I image of heart you" would somewhat detract from the moment. Given the generally apallingly low level of compliance with alt attributes on images, including image links, this discussion could be seen as a bit self-indulgent. That isn't necessarily a bad thing, but it would be good if some level of consensus could be reached. I am not yet as familiar with ARIA as I should be. My concern, though, is that if we can't get vast numbers of authors to provide meaning alt attributes or, worse, to include alt attributes at all, expecting them to use ARIA is somewhat ambitious.

Andrew

21. Posted by Vlad Alexander
on Tuesday 2010-08-10 at 17:34:16 PST

steve faulkner wrote: "your wind dog example (like your heart example) is oversimplified and fallacious and designed not to be a realistic example but one purely created to reinforce your arguments."

As a tool vendor, I need to know what a user-agent should render when encountering the following markup:

<h1 id="heading">wind dog</h1>
<img aria-labelledby="heading">

Why can't I get a straight answer from you regarding this? If you or others on the HTML5 team cannot answer this question, then the section "HTML5 Should Provide for New and Better Text Alternative Features" should be dropped from the document Correct and Improve <img> Conformance Checker Guidance.

steve faulkner wrote: "That is the whole reason why it is sometimes required to provide a text alternative somewhere else on the page..."

We seem to be going in circles. In the "wind dog" example above, how should a Web browser render the above markup when image rendering is turned off?

Andrew Downie wrote: "Given the generally apallingly low level of compliance with alt attributes on images, including image links, this discussion could be seen as a bit self-indulgent."

I see your point. As a separate discussion, let's find out why there is such a low level of compliance. Is alternate text simply too difficult a concept to understand for most users? Is the problem a lack of education or poor/inaccurate information on how to write alternate text? Is it because people don't care about accessibility? Is it because of bad authoring interfaces such as the following where only 15 characters of alternate text are visible and the user is given the option to turn off the prompt for alternate text all together?

Alternate text field shows 15 characters of text, the rest is hidden from view. Below, message reads: If you don't want to enter this information when inserting objects, change the Accessibility preferences.

22. Posted by Roger Hudson
on Tuesday 2010-08-10 at 19:13:52 PST

I have no problem with the WCAG 2 recommendations regarding providing descriptions for complex images: Namely, provide a meaningful short text alternative for the image (usually an alt) AND a long description which can be accessed by those who need it. In my experience testing sites, this is the approach most people who rely on screen readers to access the web want. What Steve is arguing for and Gregory describes is right on the money IMHO. As to the question of why don't some developers include alt attributes – well there a many possible reasons ranging from lack of awareness, lack of knowledge through to a lack of humanity. We shouldn't abandon something that is worthwhile and benefits many just because some people don't do it.

23. Posted by Carol Richter
on Tuesday 2010-08-10 at 20:11:41 PST

The Wind Dog example is beyond my competency. The I Love You example is very clear and a very good teaching aid which shows me that I was writing alternate text incorrectly before. I learned how to write alternate text from articles which now seem to have been misleading.

24. Posted by steve faulkner
on Wednesday 2010-08-11 at 00:45:19 PST

what does a user agent render when encountering this markup?

<h1 id="heading">wind dog</h1>
<img aria-labelledby="heading">

a browser will render the heading and the image as it normally does

an AT that supports aria-labelledby will announce
"Heading wind dog"
"graphic wind dog"

an AT that does not support aria-labelledby will announce
"heading wind dog"

when an image has no alt attribute or an empty alt attribute, it is typical for AT's to hide the image from users.

25. Posted by Vlad Alexander
on Wednesday 2010-08-11 at 07:38:59 PST

steve faulkner wrote:
an AT that supports aria-labelledby will announce
"Heading wind dog"
"graphic wind dog"

Thank you Steve for the clarification!

RE: Inline element containing block elements through programmatic association

Are you sure a screen reader that supports ARIA should not announce "graphic heading wind dog"? This is related to my previous question regarding an inline element (img) that now contains block elements through programmatic association. Let's take another example based on Gregory's suggestion of using ordered lists in programmatically associated text alternatives:

<img src="flowchart.png" aria-labelledby="instructions" />
<ol id="instructions">
<li>do this</li>
<li>do that</li>
</ol>

Should a screen reader that supports ARIA, while processing the image, announce the existence of a list like this?

graphic ordered list item 1 do this, item 2 do that. ordered list item 1 do this, item 2 do that.

RE: Content duplication

Steve, do you see my point regarding content duplication? Let's examine how other applications should handle this content duplication. If the above markup example is rendered by a graphic Web browser that supports ARIA and content is copied and pasted into Notepad or a text only email, content will paste as:

do this
do that

What should say Firefox (when it will support ARIA) with image rendering turned off display for the above markup? Should it duplicate content like this:

Web browser displaying two identical lists. First list item is 'do this'. Second list item is 'do that'.

26. Posted by steve faulkner
on Wednesday 2010-08-11 at 10:49:11 PST

hi vlad,
you wrote:
"Are you sure a screen reader that supports ARIA should not announce "graphic heading wind dog"?"

Yes, the way in which aria-labelledby works is it provides a text string to an accessibility API, such as MSAA or IA2 that is mapped to the accessibility APIs accessible name property, this is the same way that alt works.

you wrote:
"Should a screen reader that supports ARIA, while processing the image, announce the existence of a list like this?"

no.

"What should say Firefox (when it will support ARIA) with image rendering turned off display for the above markup? Should it duplicate content like this:"

Firefox already supports ARIA it maps the roles, states and preoprties to accessibility APIs, It is not a requirement of ARIA the ARIA specification that browsers expose the information otherwise. So its current behaviour is supporting behaviour.

27. Posted by Vlad Alexander
on Wednesday 2010-08-11 at 15:43:01 PST

1. Steve, I don't get it. You said the benefit of programmatically associating text alternatives found elsewhere in the document with an image is that text alternative can be in a form of structured content (i.e. lists, tables, headings, etc.). Yet, user-agents are not supposed to speak/display/process structured content as structured content. I don't get it!

2. So some users get content duplication and others don't? Do you not think content duplication is a problem for those users that do get duplicate content?

28. Posted by steve faulkner
on Thursday 2010-08-12 at 11:59:45 PST

Hi Vlad,

"Steve, I don't get it. You said the benefit of programmatically associating text alternatives found elsewhere in the document with an image is that text alternative can be in a form of structured content"

1. Ideally short and long text alternatives should be programmatically associated with the image that they pertain to.

2. Ideally the short and long text alternatives should be provided via methods that allow structured content.

I did not say that the use of WAI-ARIA provided 2 (currently).

The only standardized way to achieve 2 is through the use of the @longdesc, which is not a good method , as implemented currently. There are other methods which I illustrate in http://dev.w3.org/html5/alt-techniques/ which revolve around the use of a link to the longer text alternative.

vlad wrote:
"So some users get content duplication and others don't? Do you not think content duplication is a problem for those users that do get duplicate content?"

In the example you provided the use case: what to do in a situation where a text alternative has not been provided. Through the use of the same text for the heading and the image, the image is identified. Is this an adequate text alternative no, does this satisfy accessibility guidelines criteria no, is it better than nothing, I definitley think so.

29. Posted by Everett Zufelt
on Friday 2010-08-13 at 03:12:24 PST

I am admittedly not as familiar with html5 as I ought to be...

My thoughts, after speaking with Gregory yesterday, are as follows.

1. There needs to be a way to offer a brief "glance" at the purpose / role of the image. Using the example from this post, I do want to know "Graphic: Flowchart explaining how to change how to troubleshoot a lamp". The reasoning is that I want to know that there is a graphic on the page containing this information visually, even if it is of no use to me. Perhaps my friend has been seeking a flowchart graphic just like this one and I can refer her to this page to copy it.

I would liken the brief description to the title of a book. Once I know the title (purpose and role) of the book I can decide if I wish to gain more information. I do not think that there should be any restrictions on the length of this text, indeed based on different use-cases the alternative text description may be enough.

2. When a brief description is not enough (author's discretion) I want access to a more detailed, or verbose, description of the image. Following the flowchart example, I would like a textual representation of the content of the image, and yes I would like it to be structured if that is appropriate. Not only do I wish to have access to this description as a screen-reader user, I wish for everyone to have access to this description.

2.1 Using the flowchart example, I would like the content of the long description to be structured as an ordered list, as it would be if it were textual content inline with the rest of the page content. Since the purpose of providing this content is to convey a textual meaning of the image, it only makes sense to allow the content to be marked up semantically. Since I would ideally wish to access this content voluntarily, and not have to read it every time I access the page I see no real problems with the content being structured, as there will likely be a mechanism that exposes this to me in an appropriate and convenient way.

2.2 The minimal requirements for a long description in the spec should be:

a. the longdesc attribute must point to a specific element reference within the current page, or an external page. Alternatively, a details element within the current page could be used with a for attribute to point to the id ref of the img element.

b. The default behavior of all user agents should be to provide visual and programmatic indicators that a long description of the image is available, without requiring the user to query the image for this indicator.

c. An input agnostic method of exposing both visually and programmatically the content of the long description should be made available by all user agents.

d. Users should be able to access the content of the long description without having to be redirected within the current document, or to an external document.

3. There are obviously objections to be raised against any long description approach, and with my approach in particular.

a. Developers will find it difficult to understand the process and purpose of providing these descriptions. This is not new to the issue of providing textual representations of visual materials.

b. Depending on implementation the content will not be available to older technologies. Not knowing the W3C's position on backwards compatibility within html5, I would argue that since longdesc is almost never used, and then rarely used properly, in xhtml that the benefit outweighs the cost.

c. The use of "alt" as a short title and "longdesc" as a more verbose descriptor is not semantically meaningful. Better pairings may include "title" and "description", "desc" and "longdesc", "alt" and "longalt", and so on.

30. Posted by Vlad Alexander
on Friday 2010-08-13 at 08:21:09 PST

Everett and Gregory, what you guys are looking for is a description, not alternate text. In your pursuit of this "brief glance/detail" feature, when you talk about alternate text, you are eroding value of alternate text by encouraging people to use alternate text incorrectly.

Everett Zufelt wrote: "I would liken the brief description to the title of a book. Once I know the title (purpose and role) of the book I can decide if I wish to gain more information."

Let's look at this comparison. The title of a book is immutable. The title of the book does not change if the book is placed in a library, or in a bookstore or re-published online. The title of a book remains unchanged even if adjacent books on the shelf change.

Alternate text changes with location (context / surrounding text). And as such, alternate text may not make much sense when read on its own. The same image in different documents or even in different locations of the same document may have different alternate text.

Everett and Gregory, I believe the best approach to implement this "brief glance/detail" feature is not to store this information in the document. Instead, this information should be stored / accessed via public and private online services that authoring tools and Web browsers interact with, uniquely identifying images through their checksum (such as MD5). The benefit of storing description of images outside the document is that it partially removes the burden on the content author to write description of images. Different people can author image descriptions and image descriptions can be re-used between documents.

31. Posted by Everett Zufelt
on Friday 2010-08-13 at 09:38:59 PST

Vlad Alexander wrote:

"Alternate text changes with location (context / surrounding text). And as such, alternate text may not make much sense when read on its own"

The assumption you are making here is that I am advocating for a fixed alt attribute for any particular image, I am not.

Perhaps if you could explain what about my post raised this assumption I can be more clear about what exactly I am thinking about this issue.

32. Posted by Vlad Alexander
on Friday 2010-08-13 at 10:14:04 PST

Everett Zufelt wrote: "The assumption you are making here is that I am advocating for a fixed alt attribute for any particular image, I am not. Perhaps if you could explain what about my post raised this assumption I can be more clear about what exactly I am thinking about this issue."

Sure. What I hear you and Gregory say is that in your pursuit of the "brief glance/detail" feature, one possible scenario is to use the alt attribute a brief description. Since users of this proposed feature would be reading the brief description without context (surrounding text), the only way to make the alternate text be always meaningful is to use it as a description of the image, not as a substitute for the image. And description of images is likely to be the same regardless of where you use the image.

Everett Zufelt wrote: "...I want to know that there is a graphic on the page containing this information visually, even if it is of no use to me. Perhaps my friend has been seeking a flowchart graphic just like this one and I can refer her to this page to copy it."

Let's look at this markup example where the alternate text is "love" for a small heart icon to from a sentence "I love you!".

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

If you tell your sighted friend to go to this page and copy the image of "love", she will probably not find this image. The reverse is also true. If a sighted friend asks a blind person to go to this page and find a "small heart icon", the blind person will probably not find this image.

Everett, this is why I think you need a description of an image, instead of alternate text for the "brief glance/detail" feature. And this description is unlikely to change with context.

33. Posted by steve faulkner
on Friday 2010-08-13 at 12:28:14 PST

hi Vlad,

you wrote:
"Let's look at this markup example where the alternate text is "love" for a small heart icon to from a sentence "I love you!".

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

You keep using a particular example to back up your argument, namely one where an image is inline, in a sentence, and a replacement for a word or words. This is just one context where images are used and not a very frequent one at that. I would also suggest that a sighted user could ascertain from the context the image is used in, that the 'love' image was the heart.

34. Posted by Vlad Alexander
on Friday 2010-08-13 at 13:14:20 PST

steve faulkner wrote: "You keep using a particular example to back up your argument, namely one where an image is inline, in a sentence, and a replacement for a word or words."

Steve, I use this example because it teaches how to write alternate text for all images (inline or not). So, let's change my example to a non-inline image such as the flowchart in this article. For example:

My diagram creating software always uses a standard set of colors for flowcharts:
<img src="flowchart.png" alt="Start step is pink, decision steps are yellow and end steps are green." />

If you tell your sighted friend to go to this page and copy the image of "Start step is pink, decision steps are yellow and end steps are green.", she will probably not find this image. The reverse is also true. If a sighted friend asks a blind person to go to this page and find a "Flowchart explaining how to change / troubleshoot a lamp.", the blind person will probably not find this image.

FYI, Steve, here is an example written by your peer using an inline image to teach people how to write alternate text. His example is slightly incorrect:

Driving along, we spotted a giant prawn <img src="giant-prawn.jpg" alt="The Giant Prawn at Ballina">, so we had to stop and take a closer look.

It should be:

Driving along, we spotted The Giant Prawn at Ballina, <img src="giant-prawn.jpg" alt="mounted on top of a building" />, so we had to stop and take a closer look.

Regardless of his minor error, inline images are wonderful ways to teach users to write alternate text. You should consider using more of such examples in your 40+ page (and growing) document on how to write alternate text. If you used more of such examples, you could really cut down the size of your document and make it easier for users of all skill level to understand the principles of alternate text. If you are interested, I would be happy to provide you with some great examples.

35. Posted by Everett Zufelt
on Friday 2010-08-13 at 14:25:33 PST

Vlad Alexander wrote:

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

Vlad I think your example is flawed as it does not make use of the longdesc attribute. If there were a longdesc attribute, and the user agent provided users with an indication that the longdesc was present, the following would be a more appropriate example. Note that I have entered the longdesc text in the attribute, so as not to confuse the issue with where the text is located.

I <img src="heart.png" alt="love" longdesc="Image of a heart meant to represent the word love." /> you!

Vlad Alexander wrote:

My diagram creating software always uses a standard set of colors for flowcharts:
<img src="flowchart.png" alt="Start step is pink, decision steps are yellow and end steps are green." />

Again Vlad, I think your reasoning is faulty. Imagine if you would that the above example has the longdesc "An image of a flowchart explaining how to troubleshoot a lamp ... [list of steps]" and that the user agent exposed the fact that this longdesc existed to all users.

Screen-reader user to sighted user:
"There is a flowchart image with directions on how to troubleshoot a lamp, there are some pink, yellow and green steps on it."

Sighted user to screen-reader user:
"There is a flowchart image with directions on how to troubleshoot a lamp, there are some pink, yellow and green steps on it." Although the alt for the image doesn't include the word "Flowchart" I did find an image with some coloured steps on it, and look, my user agent tells me that there is a more verbose description... oh wow, a flowchart!

36. Posted by Vlad Alexander
on Friday 2010-08-13 at 19:00:54 PST

Everett, I have no objection to the use of longdesc. Just please don't call the contents of the alt attribute a "description" or "short description" or "brief glance" or "cognitive thumbnail". The alt attribute serves as equivalent textual replacement for an image within a given context.

Comments are closed for this article.

Rebuilding The Web