WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Images with captions - technical realization?

for

From: wolfgang.berndorfer
Date: Jan 4, 2020 4:04PM

Hi Birkir and interested persons on SR UX,

1. figure - figcaption concept

Birkir, your example would announce “Figure 1.2 - relationship between …”
three times while passing the figure with my SR.
Sounds like we should avoid <figure> generally because of the verbosity, it
causes for screen reader users. Or should screen reader devs reduce
verbosity technically by default? (Which SR user knows enough about
individual settings? And the general setting for reduced verbosity in Jaws
often causes loss of information at all.)

The WAI tutorial for complex images from 2015 suggests long descriptions
placed in <figcaption> either linked or with full description text:
https://www.w3.org/WAI/tutorials/images/complex/
Do we have to throw away or improve this concept?
Arrow Down interrupts the SR and continues with reading the next element. Is
this the concept, we suggest to avoid/skip verbose announcements?

2. aria-details

.. is only supported when focus is on it?
https://www.w3.org/TR/wai-aria-1.1/#aria-details

3. role="presentation" on the <figure>

Seems to be an interesting hack. I’m looking forward to testing the
suggestion with SR and HTML validator.
(<figure> doesn’t make much visual noise in comparison to <table>. So, I’d
suppose, it won’t be used, unless its semantic is wished.)

4. Your “presentation on text level semantics”

You call it *poor job*. Yet I still haven’t found any implementation of the
semantics You examined in any SR, I tested (ins, del, em, strong, …)

Thanks,
Wolfgang

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

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.
http://webaim.org/discussion/archives