WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Images with captions - technical realization?

for

From: wolfgang.berndorfer@zweiterblick.at
Date: Jan 6, 2020 10:28AM

Hi Birkir,

> You can code the caption as a heading, (make sure it comes before the image)
Not always the caption needs to be before the image in the DOM for understanding. Think about a traffic accident: An online newspaper might show a photo with an caption below.
alt="ambulance car "
<h4>Alcohol driver killed six passant.</h4>

> but if the following section does not start with a heading it's sometimes hard to figure out where that section ends and other content begins (one of the main advantages of landmark regions over headings in some situations).
This is my experience too. Therefore <figure> seems useful for SR experience for images which need linked or nested long descriptions.

> If the figcaption ia alt text for the image you can use my aria-labelledby proposal rather than aria-hidden, it should achieve the same thing (though there's a chance it might be announced twice by a screen reader).
I tested and my SR announced twice. So I'd suppose aria-hidden.

> I'm always worried about using aria-hidden to hide content, too many times have I seen people use it incorrectly resulting in important information being hidden from screen reader users.
I agree in cases of misuse. You'd probably agree that if aria-hidden is used correctly, it is helpful and necessary.

Thanks for your reflections!

Wolfgang

-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von Birkir R. Gunnarsson
Gesendet: Sonntag, 5. Jänner 2020 20:08
An: WebAIM Discussion List < <EMAIL REMOVED> >
Betreff: Re: [WebAIM] Images with captions - technical realization?

You can code the caption as a heading, (make sure it comes before the image), then give the image a descriptive alt text.

I think something like
<h4>Figure 1.1 - blah</h4>
<p>some text about it</p>
<img alt="description of image">
pretty much does the same thing as the figure/figcatption element (except the boundries of the figure element are announced by screen readers.

A heading marks the beginning of a section, but if the following section does not start with a heading it's sometimes hard to figure out where that section ends and other content begins (one of the main advantages of landmark regions over headings in some situations).

If the figcaption ia alt text for the imgae you can use my aria-labelledby proposal rather than aria-hidden, it should achieve the same thing (though there's a chance it might be announced twice by a screen reader).

I'm always worried about using aria-hidden to hide content, too many times have I seen people use it incorrectly resulting in important information being hidden from screen reader users.


On 1/5/20, Sushil Oswal < <EMAIL REMOVED> > wrote:
> If an image is accompanied by a visual caption, screen reader can read
> it and you don't need to retrofit it with an alt attribute.
>
> Sushil Oswal
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of <EMAIL REMOVED>
> Sent: Sunday, January 5, 2020 9:36 AM
> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Images with captions - technical realization?
>
> Ok, seems we don't need <figcaption> to give <figure> an accessible name.
> Does a figure need an accessible name at all? The screen reader then
> just announces beginning and end of the segment surrounded by
> <figure>, which might be enough and reduce verbosity.
>
> What, if we *want* a caption for the figure?
> a) aria-label or aria-labelledby will read the text (referenced)
> additionally at the beginning and end. Seems OK.
> b) If we want the caption to be visual, <figcaption aria-hidden="true"
> > seems to work to reduce redundancy. Jaws 2019/Firefox 71 reads the
> text of the figcaption still at the beginning and end of the
> figure-segment. Seems OK too.
>
> But what about a simple image with a visual caption under it? Is the
> figure element useful for that anyway? Seems not.
>
> And what, if the text of the visual caption is identic with the alt-text?
> I'd suggest hiding the visual caption for SR with aria-hidden. Correct?
>
> I think, I thought to complicated before and I was confused by the WAI
> tutorial for complex images.
>
> Wolfgang
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag
> von Jonathan Avila
> Gesendet: Sonntag, 5. Jänner 2020 02:34
> An: WebAIM Discussion List < <EMAIL REMOVED> >
> Betreff: Re: [WebAIM] Images with captions - technical realization?
>
> 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-figu
>> r
>> 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.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.