WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Images with captions - technical realization?

for

From: Jonathan Avila
Date: Jan 4, 2020 6:34PM

The HTML Accessibility API Mappings 1.0 document (https://www.w3.org/TR/html-aam-1.0/#figure-and-figcaption-elements) indicates that figcaption be used as the accessible name if there is no aria-labelledby or aria-label. I agree with Birkir's comment that the figcaption is not meant to be a replacement for any images in the figure -- but rather a caption for the figure.

One question this does raise is whether it's a violation to have a figure element without an accessible name. I'd say no as the figcaption is optional. If there is text that acts as a caption then figcaption or equivalent would be needed though -- much like a table and table caption. Any images in the figure would need their own accessible names as well -- unless decorative.

Jonathan


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, January 4, 2020 12:55 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Images with captions - technical realization?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


I think the standard use case for the <figure>/<figcaption> element is a figure in a textbook, where the caption gives contect for the image (but is not alt text for the image), something like <figure> <figcaption>Figure 1.2 - relationship between accessibility and customer satisfaction</figcaption> (possibly an extra line of text) <img alt="graph depicting the relationship showing that accessible websites score on average 20% higher in customer satisfaction than inaccessible sites"> </figure> (these are ficticious numbers) If the figure is complex the caption may also contain a table, ideally referenced from the image element using aria-details (though last time I checked I found zero support for that attribute).

If the figure element is used this way the figcaption element content should not be the alt text for the image, it's about the image, it doesn't describe the image.
Also if it is used this way the natural mapping for the figure element for a screen reader is a group or a landmark region and the screen reader will announce the boundries of the figure as you navigate into and out of it (I think this can be controled viav verbosity settings).
It's important in this sceanrio to keep the content of the figcaption short and put any extra info thta is not the barebones label into a paragraph inside the figure, because the figcaption is used as the accessible name for the figure and repeated 2 to 3 times (if you navigate in browse mode).

I think the figure element is often misused and the figcaption is essentially the alt text for the image, in which case you could use role="presentation" on the <figure> element itself and connect the image with the figcaption element using aria-labelledby <figure role="presentation"> <figcaption id="fig11">ABCD logo</figcaption> <img aria-labelledby="fig11"> </figure>

In this scenario the problem has a lot to do with the figure element not being used as intended, but this ARIA workaround will eliminate the screen reader verbosity and expose it as an image with alt text.

There are a lot of HTML element with very specific use cases and for many of them authors do not use them as intended and browsers/assistive technologies do not expose them in a way that best fits the intended purpose, instead mapping them to more generic roles (or sometimes ignore them).
Using HTML to mark deleted and replaced values comes to mind, see my
2016 presentation on text level semantics:
http://whoseline.a11yideas.com/01_semanticTextElements.html

This is a challenge we must continue to explore and solve to promote full digital equality.


On 1/3/20, <EMAIL REMOVED>
< <EMAIL REMOVED> > wrote:
> Hi,
>
> The more I read, the more I doubt about this simple issue.
>
> How should images with visual captions be technically realized for SR?
>
>
>
> A) <figure> with <figcaption>
>
> . seems to be the native semantic.
>
>
>
> But my screen reader does, what it should: It repeats the value of the
> figcaption three times: When entering and leaving the figure-section
> and when entering the figcaption-element.
>
> These redundancies disturb SR UX, although such examples are even
> presented in the spec:
>
> https://html.spec.whatwg.org/multipage/grouping-content.html#the-figur
> e-elem
> ent
>
>
>
> 1. How to avoid these redundancies technically or with SR settings?
>
> 2. Should <figure> only be used, when a *long description* in the
> <figcaption> is reasonable?
>
>
>
> B) <img> followed by <p> with captioning text
>
>
>
> 3. Could a simple <img> - <p> combination be semantically connected?
> aria-describedby only works within focusable elements.
>
>
>
> Furthermore: Redundancies with the value of the alt-attribute
>
>
>
> 4. What if the value of the <figcaption> or <p> matches the
> alt-attribute in the image already? If alt=NULL, the SR won't announce
> the *existence* of an image at all, which might be useful and
> necessary sometimes.
>
>
>
> Thanks for ideas!
>
>
>
> Wolfgang
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.