[whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
faulkner.steve at gmail.com
Mon Jun 17 02:35:54 PDT 2013
> Am 07.06.2013 um 23:13 schrieb Ian Hickson:
> >> <img src="..." title="image">
> > If you have a caption from the user (as opposed to replacement text),
> > this is a perfectly valid option. It's as valid as the <figure> case, and
> > means the same thing.
> > [...]
the above statement is bad advice:
browsers map title to the accessible name in accessibility APIs when alt is
in the following cases:
<img src="..." title="poot">
<img src="..." alt="poot">
the accessible name is 'poot'.
it is only when there is an accessible name already provided that title is
used as an accessible description:
<img src="..." alt="poot" title="description of poot">
Also note that as per the W3C HTML spec, use of the title without an alt is
non conforming as it does not represent a caption for an image and as
you point out is hidden from a variety of users due to a long and
consistent history of poor implementation.
> >> I don't know whether someones writes something like "which the
> >> following figure illustrates" instead of "which is illustrated by fig.
> >> 3" somewhere in the text above a figure. But this difference decides
> >> whether using the figure element conforms with the spec. So a code
> >> generator can only use something which is structurally and optically
> >> identical to the figure element but does not have the theoretical
> >> requirement to be movable to a different place in the document, e.g.:
> >> <div class="figure">
> >> <img src="...">
> >> <div class="caption">...</div>
> >> </div>
> >> And here conformance checkers will complain about the missing
> >> alt-attribute again ...
> > If you use <img src="..." title="..."> it'll work (and be correct,
> > insofar as anything missing alt text can be correct).
> While the title attribute might be as good as the figcaption or a
> div-caption element in meaning, it differs in practice, as the element can
> include further markup, the attribute cannot. The title attribute is
> displayed as mouse-over text in most browsers whereas the figcaption is
> usually immediately readable to anyone, just as a caption for a picture in
> a book.
> attribute immediately visible as well. But this would require further
> technology on the reader’s side (JS) and complicate things more than
> justified for the cause, in my opinion.
> What my markup generator actually does with captioned images is this:
> <meta name="generator" content="generator-name">
> <div class="figure">
> <img src="..." aria-labelledby="caption-x">
> <div id="caption-x" class="caption">...</div>
> (see also
> Is there a chance that use of aria-labelledby is added to the spec
> (126.96.36.199.13 Guidance for markup generators, 188.8.131.52.14 Guidance for
> conformance checkers) as alternative to figure with figcaption or the title
> attribute? I'd like to suggest this. It does make equally sense in my
> opinion and I think I've described the use case in this thread:
> -- markup generator has no alt-text for an image
> -- image has a caption that should be immediately visible and possibly
> contain markup => no title attribute
> -- it is not known whether the image can be moved somewhere else in the
> document => no figure with figcaption
the restriction on figure/figcaption is only in the whawtg spec not the W3C
HTML spec as it was not deemed a useful or practical restriction when
reviewed by the HTML WG.
In fact markup generators are encouraged to use figure/figcaption for this
use case  as the figcaption is mapped to a caption role accessibility
APIs by browsers.
> -- markup generator should not be pressured to use bogus alt-text to calm
> easily scared customers using validators
> E.g. OCR book digitizers or markup editors strictly following the WYSIWYG
> (PS: Also, thank you and Jukka for your comments that I've not replied to.)
Your suggestion of using aria-labelledby suffers from the same issue as use
of title in this case, in that its value is used for the accessible name
and does not represent a caption semantic unlike figcaption.
More information about the whatwg