Accessibility issues with the image & text block
Jul 11, 2023
I have identified a couple of accessibility issues with the image & text block.
Issue #1: The first issue is the heading that is included in this block. Whilst there is visually a heading in this block (large + bolder text), the text is not defined as a heading level element and is therefore not programmatically a heading. This means that assistive technology will interpret the heading as a paragraph.
Issue #2: This issue is related to the accompanying image, and if you choose to add a caption to the image. If you add a caption to the image, the caption is also added as an ALT text value to the image. The caption is using the correct semantic HTML <figcaption>, but an ID has been added to <figcaption>, and then an aria-labelledby attribute has been added to the <figure> element, referencing the ID on <figcaption>. For example (code simplified to illustrate issue):
<figure aria-labelledby="labelA" class="block-image__figure" role="figure"> <img alt="Volkswagen camper van parked up by the beach" role="img" src="vw.jpg"> <figcaption id="labelA"> <p>Volkswagen camper van parked up by the beach</p> </figcaption></figure>
This results in, 1) The figure reads "Volkswagen camper van parked up by the beach" due to the aria-labelledby attribute, 2) The ALT text value "Volkswagen camper van parked up by the beach" is then read, 3) The caption is then read.
6 Replies
Hi, Sam! We appreciate you calling out accessibility.
The first issue you identified is within control of the author. The placeholder text for that block has been formatted to look like there's a heading, but the entire block is actually the paragraph type. Authors are able to to format their text freely in that block without making the appearance of a heading.
I wasn't able to reproduce the second issue when I tested with the Share link. I tested keeping the alt text the same as caption text, and with changing the alt text to something specific for screen readers. Since captions don't always include the type of descriptive elements a visually impaired person may need, we allow authors to make alt and caption text separate.
In my test, I found that the alt text was read when the focus was on the image, and the caption text followed once you navigated to the caption using a screen reader. If you have a screen recording showing how you reproduced the 3 announcements, will you please share it with us here? I want to make sure I'm not missing a bug. Thanks!
Hi Crystal, hope you are well, and thanks for the response.
With regards to the first issue, I understand the user can remove the "heading", but I think this is misleading, as the content I review whilst doing accessibility testing for my clients frequently includes this block, with the "heading" in place. I don't think it is unreasonable for authors to assume that the placeholder heading, which as you say has been formatted to look like a heading is using the correct heading level HTML. It is in control of the author, but most authors wouldn't be conscious that the heading is not using the correct semantic HTML for assistive technology.
I think this needs addressing. Either by removing the formatted heading from the block which is inserted by default, or allow the user to select a heading level from the text formatting tools. In this comment section I can select H1 through to H6 via the Format > Headings options. A similar option in Rise would be great.
And for the second issue regarding the same text being read three times:
This post was removed by the author
Hi Sam!
Just chiming in with Crystal!
For issue #1, I agree with you. The title text in Image & Text block does looks like a heading by default, however not marked up as such. Formatting it this way by default does give an impression it is a heading, though it is meant to be a paragraph. We have an open issue about allowing users to select heading levels.
For Issue #2, I went through your recording and I also agree with you. We can definitely streamline the process and clean up the experience here. Unsuspecting users may not realize that adding a caption puts the same value as their image's ALT text, and the extra <aria-labeledby> is adding to the noise. I'll get a ticket going for this.
Cheers!
Marvie
"#1 We have an open issue about allowing users to select heading levels." - This would be a great addition to the software.
#2, thanks for taking the time to review. Streamline is a small thing we can do to improve accessibility.
Thanks again Marvie. I really appreciate your input on these items.
Hi Sam,
Just checking in to let you know we've released an enhancement for image caption handling for cleaner, more optimized accessibility. When an image caption is provided, we no longer set it automatically as the default alt text when the alt text is not defined.
However, we are keeping the
<aria-labeledby>to support a wider range of screen readers & browser combinations. It appears that there is mixed support for the<figure>tag, where it's not always tied to the<figcaption>. Explicitly having an<aria-labeledby>ensures we keep its semantic meaning.Let us know what you think! Cheers!
Marvie
Thanks Marvie. I understand the rationale and can't really argue with it. It would be great if browsers could detect the Assistive Technology being used so we can make appropriate decisions with content, but we're not their yet. It puts the onus on AT to get it right, which I guess is the correct approach.
Thanks for following up.