E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: wolfgang.berndorfer
Date: Fri, Jan 03 2020 2:42PM
Subject: Images with captions - technical realization?
No previous message | Next message →

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-figure-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

From: Birkir R. Gunnarsson
Date: Sat, Jan 04 2020 10:54AM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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 ADDRESS REMOVED =
< = EMAIL ADDRESS 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-figure-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
>
> > > > >


--
Work hard. Have fun. Make history.

From: wolfgang.berndorfer
Date: Sat, Jan 04 2020 4:04PM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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 ADDRESS REMOVED = > Im Auftrag von
Birkir R. Gunnarsson
Gesendet: Samstag, 4. Jänner 2020 18:55
An: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
< = EMAIL ADDRESS 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

From: Jonathan Avila
Date: Sat, Jan 04 2020 6:34PM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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

From: wolfgang.berndorfer
Date: Sun, Jan 05 2020 10:35AM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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 ADDRESS REMOVED = > Im Auftrag von
Jonathan Avila
Gesendet: Sonntag, 5. Jänner 2020 02:34
An: WebAIM Discussion List < = EMAIL ADDRESS 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

From: Sushil Oswal
Date: Sun, Jan 05 2020 11:45AM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Sun, Jan 05 2020 12:07PM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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 ADDRESS 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
>

From: wolfgang.berndorfer
Date: Mon, Jan 06 2020 10:28AM
Subject: Re: Images with captions - technical realization?
← Previous message | Next message →

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 ADDRESS REMOVED = > Im Auftrag von Birkir R. Gunnarsson
Gesendet: Sonntag, 5. Jänner 2020 20:08
An: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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
>

From: wolfgang.berndorfer
Date: Tue, Jan 07 2020 2:01PM
Subject: Re: Images with captions - technical realization?
← Previous message | No next message

Seems the discussion is finished, so I try to distillate recommendations for techs for images with visual captions.

A) Simple image – caption combinations:

1. If an image needs an alt-attribute and has a visual caption (in <p> or <hx>), the <img>-Element and the captioning element have to follow each other in the DOM immediately
2. If the value/content of the alt-attribute and the caption are identic, the captioning element should get aria-hidden to avoid repetitive annunciations of the same by screen readers.

B) complex images with visual captions

Additionally to A)
1. The image typically should have a long description, either linked or completely presented near the <img>-element in the DOM.
2. Image, caption and long description should be grouped to mark the boundaries of this unit for screen readers.
3. If the beginning of the image-unit is marked with a heading, the end of the unit needs to be marked by a heading for the next unit of the page.
4. If you mark the boundaries by grouping image, caption and long description in a <figure>-element:
4.1 The text in the optional <figcaption> needs to be as short as possible. Never place the long description completely in the figcaption! This is the accessible name for the <figure> ( if you don't use aria-label/labelledby on the figure-element).
4.2 The <figcaption>-element should get aria-hidden to avoid triple annunciation for screen readers while passing the figure-element.

Thanks for inputs in the discussion, which I hopefully interpreted and formulated correctly.

Wolfgang