W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13651] Missing alt should not be considered conforming in the presence of figcaptions over 50 words in length.

From: <bugzilla@jessica.w3.org>
Date: Sat, 13 Aug 2011 10:26:52 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QsBQa-00066w-IG@jessica.w3.org>

--- Comment #13 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-13 10:26:48 UTC ---
(In reply to comment #12)
> So it is your counter-opinion then that alternative text in excess of 50 words
> is not harmful, is not a poor user-experience for screen reader users, and
> satisfies the needs of non-sighted users appropriately?

Concision in all text is better.

> Perhaps you have evidence that supports that contrary opinion?

A claim that 50 words is good and 51 words is bad would be nonsensical, since
words are not equal. Some words convey more information than other words. Some
languages need fewer words to convey the same information, because they combine
words to make new words or use inflection in place of parts of speech. Some
words have more syllables than other words, so users will have to listen
longer. Some words have more characters than other words, so users will have to
braille longer. You cannot draw strong correlations between the information
conveyed by a word, its number of syllables, and its number of characters. So
word count is not a reliable limit on information density, listening time, or
braille time, all of which one would aim to minimize for a short text

Previous literature, included that cited by the bug report, makes a wide
variety of recommendations about @alt text length, few of them consistent with
a 50 word threshold:

   * http://www.cs.tut.fi/~jkorpela/html/alt.html (50 characters, based on @alt
display problems)
   * http://www.washington.edu/accessit/print.html?ID=1257 (125 characters,
based on a bug in JAWS 6)
   * http://joeclark.org/book/sashay/serialization/Chapter06.html (1,024
characters, based on @alt display problems)
   * http://www.w3.org/WAI/GL/WCAG20/tests/test3.html (100 words, or higher if
the human checker judges it appropriate)
   * http://itl.uconn.edu/idd/wai/html/multimedia.html (50 words)
   * http://www.accessibletech.org/access_articles/webinfo/altAttribute.php
(151 characters, primarily based on @alt display problems)
   * http://www.ok.gov/abletech/IT_Accessibility/webtips.html (around 100
   * http://www.w3.org/TR/html-alt-techniques/#m5 (75-100 characters or 1-2
   * http://lists.w3.org/Archives/Public/public-html-a11y/2011Aug/0011.html
(250 or 300 characters)

In the absence of positive evidence otherwise, we can see that 50 words is an
arbitrary choice not a magic metric that divides helpful from harmful text

> > there's a wide chasm between a bug reporter understanding a user
> > perspective and us actually solving users' problems, especially when we have
> > such extremely limited influence over the system with which the user has
> > problems.
> First, this is not a "system" issue, this is an authoring and conformance
> issue: regardless of which browser or screen reading technology you may be
> using, a textual alternative for an image should be "brief" and succinct. 

By "system" I did not mean the user's individual hardware and software setup,
but rather the ecosystem that constitutes the Web, the people who consume and
produce content on the Web, the tools they use to do so, and the people that
develop those tools.

> > Restrictions on authors (especially those requiring them to do additional work)
> > should be proven to be truly necessary and plausibly effective.
> Conformance reports of success or failure (a method of positive and negative
> reinforcement) can have highly effective results - it is in fact the root of
> most education curriculum (Pass or Fail) and behavior modification. 
> http://en.wikipedia.org/wiki/Behavior_modification
> It is in fact this very behavior and methodology that the HTML5 spec is seeking
> to use when it obsoletes existing elements
> (http://www.w3.org/TR/html5/obsolete.html) - by making "bad" author behavior
> trigger a conformance error, the spec seeks to modify such author behavior.

Author conformance requirements are primarily intended to help authors use
markup that does what they want it to, not as some sort of ,control mechanism:


> The Draft Specification seeks to make changes to an existing requirement for
> the @alt attribute, in the process breaking backward compatibility.

A 50 word limit on <figcaption> would not fix backwards compatibility of new
content with old user agents.

> Thus the onus is on the change proponents to prove that this change does not cause
> 'harm'. 

The HTML WG process does not require the existing draft to prove its
differences from HTML4 do not cause harm.

> We have had a decade of user experience that has suggested and supports the
> fact that non-sighted users want and need (when appropriate) both short and
> longer textual content with regard to images, and the WebAIM survey of 2009
> suggests that fewer than 15% or respondents wanted a verbose (long) textual alt
> for images. 
> http://webaim.org/projects/screenreadersurvey2/#images

Is this the "demonstrations" by a "host of affected users" you were referring

Although questionable, this suggestive evidence would still have strengthened
the original bug report. It's a shame it was not provided up front.

> > > Suggesting that perhaps someday some screen reader might afford the end user
> > > the opportunity to undo bad authoring practice is Utopian at best and fosters
> > > the creation of problematic content today.
> > 
> > Requiring authors to generate more metacrap should be our last resort, not our
> > first:
> I find referring to text alternative to images that non-sighted users cannot
> see as "meta-crap" highly offensive and insensitive. If you have such little
> regard for the real needs of real users that you can cavalierly dismiss this
> need as "meta-crap" then frankly you don't have any real understanding of the
> issue and continued debate here is likely pointless.

You misunderstand the link. When they're accurate, hidden text alternatives and
other metadata are a good thing. Requiring people to add metadata guarantees
you will get some bad metadata (metacrap). Where data is really needed, a
solution is to make machines generate data - where possible. Sometimes it's
inevitable that we need people to add metadata. We should try and work out if
this is one of those situations or not. It looks to me like it might be a
situation where we can at least let machines generate the data some of the
time, so we should investigate that possibility before trying to solve it by
making more work for authors through a conformance requirement. That approach
that will fail a lot of the time, and thus fail to address the systemic
problem. For example, @alt is missing on only two out of ten <img> elements,
despite being required by HTML4. (Never mind that many @alt values are entirely


> > I'd restate the problem raised by this bug as follows: users can discover,
> > find, or retrieve relevant content (e.g. by reviewing a document, or reviewing
> > a list, or by skipping from graphic to graphic) more conveniently if short
> > titles label images rather than longer text, even if that text serves an
> > equivalent purpose to the image or provides additional information.
> It is at the point where it is providing that "additional information" that
> authors can inadvertently introduce negative user-experiences. Once again, this
> comes down to understanding the difference between a functional alternative and
> a detailed description of an image (but then, for someone who considers this
> all meta-crap, I'm not too surprised you don't get it)

"Functional alternative" is not WCAG terminology, but assuming by this you mean
text that serves an equivalent purpose (which is WCAG terminology), then such
text may be longer than 50 words.

The Understanding document for the equivalent purpose success criterion, while
merely advisory, is quite explicit here when it says "If a short description
can not serve the same purpose and present the same information as the non-text
content (e.g., a chart or diagram)".


If, in such a case, a short text alternative *itself* was considered to serve
an equivalent purpose, then authors could meet the success criterion by
providing a short text alternative and the effect of the criterion wouldn't
match its intent "to make information conveyed by non-text content accessible
through the use of a text alternative". This was in fact the case with HTML4
conformance where @alt was required but text that served an equivalent purpose
was not.

(That HTML5 does require that there be available text that conveys the same
information as images, in accordance with that intent, is a virtue of the
current draft, even if the ways it proposes this text be made available are

> > How can
> > user agents present a short title for images when <figcaption> isn't one and no
> > alternative mechanism for labelling the image has been used? (Have I missed
> > anything?)
> Except that it is not a "How" question any longer, it's an "if" statement: "If"
> text inside of <figcaption> is too verbose to act as a functional replacement
> for @alt (and it has been conceded that in many instances figcaption can be a
> functional replacement), then it should be considered non-conformant unless
> @alt text is also provided. The question is not if figcaption can be a possible
> stand-in for @alt, but rather when does it cease to be so?

I'm describing an end-user problem, not some point of conformance that it is
hoped will indirectly address that problem. If we avoid conflating problems and
solutions, we stand a better chance of picking an optimal solution.

> As well, in both instances they are summations of existing text, and not
> functional alternatives to images, so you are comparing potatoes to oranges.

Adding a 50-word limit on <figcaption> before requiring an @alt doesn't do
anything to ensure images have text that serves an equivalent purpose. The
point of this bug is to provide a short text alternative not text serving an
equivalent purpose.

Given that we have mechanisms to extract the first sentence from text, it seems
a machine can easily provide some short text given a long <figcaption> and
authors have the tools to override such machine-provided text. Such text is
liable to be a figure title in both cases, since otherwise it would not work as
a good label when the document is being navigated non-linearly - which is the
only purpose of the short text in this case. (Since users consuming the
document linearly will have already heard the whole <figcaption>, an additional
@alt that duplicates information in the <figcaption> will be a brief

> > How is suggesting that such techniques could be expanded to captions more
> > "Utopian" than (say) suggesting popular browsers could expose @longdesc via a
> > button on their main toolbar?
> Because we are talking about authored content, not user interaction or browser
> behavior.

Some user needs can be met by user agents without additional authorial effort.
Maybe this is one of them. So I still don't understand your notion that this is

> > > If you don't like 50, provide another number. 60? 80? 250? 8,439? For
> > > conformance checking, what is the number that you would propose to page
> > > authors? And why?
> > 
> > Neither HTML nor WCAG2 Recommendations constrain labels for UI components or
> > content sections with arbitrary word counts.
> Both HTML and WCAG require "testable" conformance:
> Currently in HTML 4/XHTML1 we have a requirement that all images have @alt, and
> that @alt be either empty (alt="" silences screen readers, and is functionally
> equivalent to aria-role="presentation") or contain a text string. Those are
> testable criteria that validators and other testing tools can apply, whilst
> having your human being verify that the text alternative is *appropriate* is
> also required for true accessibility.
> This is not any different.

Machine-testable is only a subset of "testable". We do not need to adopt bad
machine-testable conformance criteria in lieu of better human-testable
conformance criteria.

> Once again, if you have a better proposal on how to ensure a testable criteria
> that ensures that figcaption as a REPLACEMENT FOR (and not supplementary to)
> @alt is not too verbose can be constructed, please do speak up.

_If_ it's agreed that end-users need short text alternatives (a requirement
that is *additional* to WCAG2), then we can require that if the image has a
programmatically associated text alternative and the first sentence of that
alternative would not be suitable as a short text alternative, the author must
use a mechanism to supply a short text alternative.

Conformance checkers to present images with their short text alternative and
long text alternative, allowing humans to test the text alternatives are

A test suite for the accessibility API mapping suggestions might verify that
the short text alternative (whether implied or explicit) is exposed as accName
or an equivalent feature in another language. It would be a good idea for the
mapping document to specify how to extract a first sentence to promote

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 13 August 2011 10:26:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:00 UTC