Alt Text Character Limit

[cdesrosiers813]

I created this issue on behalf of the [Alt Text Subgroup] (https://www.w3.org/WAI/GL/task-forces/silver/wiki/Alt_Text_Subgroup) of the Silver Task Force.

Explanation:
Up until this point, W3C has not specified a character limit for alt text. The guidelines refer to “short text alternative” and “long text alternative.” This is leading to confusion and mixed messages on the web with organizations attempting to define this limit for users:

University of Illinois: 100 characters
Moz: 125 characters
HubSpot: 125 characters
GVSU: 140 characters
Aces Editing: 140 characters

This topic has been discussed within W3C in the past, and some have raised concerns with defining a character limit. First, restricting the character limit may discourage people from providing a sufficient text alternative for an image. Second, many platforms do not support extended description. Third, the same alt text can have different character lengths when written in different languages.

Question:

Why doesn’t WCAG 2.x set a character limit for the alt attribute value?

[BitwiseAndrea]

Twitters implementation of alt text allows up to 1k characters and is also visible to users who do not use screenreaders behind a button. When seeing this I wondered why longdesc wasn't used instead. If an alt text max length was to be added it seems like it would be a reasonable thing to suggest using longdesc in cases where more than 100 characters were necessary, and improving the pitfalls longdesc.

[fstrr]

The longdesc attribute isn't part of the HTML specification anymore and it has inconsistent support from browsers and assistive technology, which could be why Twitter didn't use it. The Accessibility Guidelines Working Group is proposing to remove the related H45 technique. Alt text doesn't have to fit into 100 characters—the Non-Text Content criterion requires that a text alternative serves an equivalent purpose, and that could lead to a longer description.

[cstrobbe]

Authors should consider two things:

1. How screen readers deal with "long" alt attributes: screen readers may split the contents into chunks of 125 characters. (This has led some people to believe, mistakenly, that the alt attribute gets truncated at 125 characters.)
2. As a screen reader user, you can't pause the alt attribute; you listen to all of it or start over. For this reason, a long text alternative can be frustrating.

However, the relationship between the number of characters on the one hand and the number of spoken syllables (in speech synthesis) on the other varies from language to language (and from writing system to writing system). A general character limit would be unable to take this variability into account. As a consequence, any character limit for the alt attribute would be perceived as arbitrary.

[GreggVan]

hmmmm But without long desc in HTML (and not universally supported) and aria not having an equivalent (other than pointing to some other url) what is our recommendation for if there is a picture that has more information than can be expressed in short ALT? (Also we have Powerpoints and other formats that only have ALT text. Is our advice — make it as long as necessary to convey all important information — but not a word longer? Gregg Vanderheiden ***@***.***

…

On Jul 21, 2022, at 7:34 AM, cstrobbe ***@***.***> wrote: Authors should consider two things: How screen readers deal with "long" alt attributes: screen readers may split the contents into chunks of 125 characters. (This has led some people to believe, mistakenly, that the alt attribute gets truncated at 125 characters.) As a screen reader user, you can't pause the alt attribute <https://yatil.net/blog/there-is-no-character-limit-for-alt-text#komment_566edcf224bd7283ecee75626aa82acb>; you listen to all of it or start over. For this reason, a long text alternative can be frustrating. However, the relationship between the number of characters on the one hand and the number of spoken syllables (in speech synthesis) on the other varies from language to language (and from writing system to writing system). A general character limit would be unable to take this variability into account. As a consequence, any character limit for the alt attribute would be perceived as arbitrary. — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXSAEPO6YWCPJARLI7LVVFNY3ANCNFSM5HTRILPQ>. You are receiving this because you are subscribed to this thread.

[cstrobbe]

I'm not questioning that there needs to be guidance to help authors decide when they should just use an alt attribute (in HTML) or consider complementing that with a long description that is presented through some other means. (The WAI tutorial on Complex Images provides a number of methods without being exhaustive.)

However, defining a character limit as a threshold for adding a long description cannot be done across all languages and technologies:

1. Some languages need fewer characters to express the same information and defining a character limit (plus or minus x) for each language in use on the web is not really feasible.
2. Not all formats or technologies distinguish between a "short text alternative" (like HTML's alt attribute) and a long description. For example, Microsoft Word and PowerPoint used to have the fields "title" and "description" for text alternatives of images, but since Office 2019 (if I'm not mistaken) these have been replaced with a single field [*]. That doesn't mean long descriptions can't be provided in addition to the short text alternative, but the connection between the non-text object and the long description won't always be programmatically determinable. (E.g. in PowerPoint: putting the long description in a text container that is visually hidden behind an image that fills most of the slide.)

So the question becomes: how should we word guidance to authors to help them decide when to complement a short text alternative with a long description? Any character limits given in such guidance should be explicitly marked as language-specific and approximate.

---

* The title field did not provide a text alternative, but if you fill in both title and description for an image in PowerPoint 2016 and then open the presentation in PowerPoint 2019 or a newer version, the title and the description are combined into the Alt Text field. (Probably because many people mistakenly used Title as a text alternative in older versions of PowerPoint.)

[GreggVan]

+1 gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org

…

On Jul 22, 2022, at 9:45 AM, cstrobbe ***@***.***> wrote: I'm not questioning that there needs to be guidance to help authors decide when they should just use an alt attibute (in HTML) or consider complementing that with a long description that is presented through some other means. (The WAI tutorial on Complex Images <https://www.w3.org/WAI/tutorials/images/complex/> provides a number of methods without being exhaustive.) However, defining a character limit as a threshold for adding a long description cannot be done across all languages and technologies: Some languages need fewer characters to express the same information and defining a character limit (plus or minus x) for each language in use on the web is not really feasible. Not all formats or technologies distinguish between a "short text alternative" (like HTML's alt attribute) and a long description. For example, Microsoft Word and PowerPoint used to have the fields "title" and "description" for text alternatives of images, but since Office 2019 (if I'm not mistaken) these have been replaced with a single field. That doesn't mean long descriptions can't be provided in addition to the short text alternative, but the connection between the non-text object and the long description won't always be programmatically determinable. (E.g. in PowerPoint: putting the long description in a text container that is visually hidden behind an image that fills most of the slide.) So the question becomes: how should we word guidance to authors to help them decide when to complement a short text alternative with a long description? Any character limits given in such guidance should be explicitly marked as language-specific and approximate. — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXSIRTPEUBKSLRHOFCTVVLF3BANCNFSM5HTRILPQ>. You are receiving this because you commented.

[cdesrosiers813]

Thanks for providing the history and next steps for discussion on this topic. The question on the table is:

How should we word guidance to authors to help them decide when to complement a short text alternative with a long description?

More guidance on character limits could help create more consistency across providers, as well as help authors understand image description best practices. I agree that the guidance should be noted as language specific.

To kick off the discussion on this topic, how about providing a character limit that is slightly higher than what is popular in the field with a target average? For example, 250 character limit with a target of 125 characters. In this case, any image that requires a description over 250 characters should have a short + long description.

What are your thoughts on this approach? Are there any suggested alternative options to explore?

[bruce-usab]

@cdesrosiers813 – this is in the context of wcag3, correct? For me, a hard character limit makes less sense than ever. Whatever the number chosen will be arbitrary, and 3 aims to be more research-based than 2.

My suggestion is for 3 to have two distinct requirements for non-text context.

1. Short text alternative that provides descriptive identification.
2. Long text alternative that serves the equivalent purpose.

For most web technologies, the alt attribute is probably not the best choice for (2).

Having the requirements combined as they are in 1.1.1 has significant advantages (e.g., when null alt is best, or when the text equivalent is a name). OTOH alt continues to be a topic of much discussion, so certainly there is the opportunity with 3 to communicate principles better.

[GreggVan]

Agree with Bruce And where there IS no long description mechanism — then there certainly should not be a char limit. Else how do you convey the information in a chart or diagram that is not otherwise in the text - just in the illustration. gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org

…

On Jul 26, 2022, at 4:14 AM, Bruce Bailey ***@***.***> wrote: @cdesrosiers813 <https://github.com/cdesrosiers813> – this is in the context of wcag3, correct? For me, a hard character limit makes less sense than ever. Whatever the number chosen will be arbitrary, and 3 aims to be more research-based than 2. My suggestion is for 3 to have two distinct requirements for non-text context. Short text alternative that provides descriptive identification. Long text alternative that serves the equivalent purpose. For most web technologies, the alt attribute is probably not the best choice for (2). Having the requirements combined as they are in 1.1.1 has significant advantages (e.g., when null alt is best, or when the text equivalent is a name). OTOH alt continues to be a topic of much discussion, so certainly there is the opportunity with 3 to communicate principles better. — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXRFUXGKNWLDVXDXP3LVV7CABANCNFSM5HTRILPQ>. You are receiving this because you commented.

[cdesrosiers813]

Thanks for the great feedback. A few follow up questions:

@bruce-usab - How short should a "short text alternative" be? Are you saying it should be long enough to provide descriptive identification? I can see there being some confusion on "how short" and "descriptive identification" here. Perhaps this is the sort of guidance on principles you are suggesting, but I'm curious to hear your thoughts on these points.

@GreggVan - What about when the provider does support long description? Do you think they should still avoid setting a character limit for alt text?

[patrickhlauke]

@bruce-usab - How short should a "short text alternative" be? Are you saying it should be long enough to provide descriptive identification? I can see there being some confusion on "how short" and "descriptive identification" here. Perhaps this is the sort of guidance on principles you are suggesting, but I'm curious to hear your thoughts on these points.

The problem is of course that this is highly context specific and subjective. “Everything should be as simple as it can be, but not simpler”
Binary WCAG 2.x can't set a hard limit or give an unambiguous definition of how short "short" is, in a universal and testable way. The best it can hope for is to provide some non-binding, non-normative suggestions.

[GreggVan]

Thanks for the great feedback. A few follow up questions: @GreggVan <https://github.com/GreggVan> - What about when the provider does support long description? Do you think they should still avoid setting a character limit for alt text?

GV: if long description is supported by BOTH the technology being used and by assistive technologies — then ALT should be short and the long description used. But for technologies (including HTML and Powerpoint and ….) where there is no long description ALT text may need to be longer. (Thankfully ARIA-Description <https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-description> was added to provide long description capability for HTML. A thank you to all that made that happen). gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org

…

On Jul 26, 2022, at 7:25 PM, Caroline Desrosiers ***@***.***> wrote: Thanks for the great feedback. A few follow up questions: @bruce-usab <https://github.com/bruce-usab> - How short should a "short text alternative" be? Are you saying it should be long enough to provide descriptive identification? I can see there being some confusion on "how short" and "descriptive identification" here. Perhaps this is the sort of guidance on principles you are suggesting, but I'm curious to hear your thoughts on these points. @GreggVan <https://github.com/GreggVan> - What about when the provider does support long description? Do you think they should still avoid setting a character limit for alt text? — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXWUYJRG354AAEOQFGDVWCM3BANCNFSM5HTRILPQ>. You are receiving this because you were mentioned.

[ghost]

IHMO a character limit is a valid option to provide more acc to users of braille-interfaces. Reading an long alttext can be really annoying if its out bounce for the length of the braille interface. Therefore a max length should be based on the standard sizes of thes interfaces. Sizes differ on the model of the interface. So devs should be able to choose the best for there specific use case. Providing Options from 12 40 and 80 should be appropriate.

[patrickhlauke]

But again, as a best practice advice, sure. But not as a hard pass/fail criterion, as the point of WCAG is not to abolish things that are "annoying"...

[bruce-usab]

If anyone has data where the early limits came from, that might be instructive. For example, IE at one point used ALT for mouse-over hover text but only so many characters. Did that behavior become enshrined as the canonical limit?

I am inclined to tag this as wontfix since where should this issue go?