Images with long description should have the long description accessible to everyone

[juliemoynat]

Hello,

In the website, there are some pages with images that requires long description.

• https://almanac.httparchive.org/fr/2019/accessibility
• https://almanac.httparchive.org/fr/2019/mobile-web
• etc.

Long description are hidden by default and can be read only by people using a screen reader.

Long description are useful for people who can't see images like blind people and for people who can't see images well like visually impaired people who need to zoom inside the page. They can also be useful for people with some cognitive or mental disabilities.

So, long descriptions should not be hidden but should be accessible to everyone.

As an example, I learned in the long description of the image about contrasts that the grey boxes are the orange boxes in greyscale. How all people can be aware of it without being able to read the long description?

To fix it, you can hide the long description behind an accessible "Show / hide" button so that it will not take up a lot of place.

I made a CodePen to have an example: https://codepen.io/juliemoynat/pen/ZEbwbvp

In addition, the aria-describedby attribute on <img> tag is unfortunately not compatible with screen readers at the moment: https://www.powermapper.com/tests/screen-readers/labelling/img-aria-describedby/

[tunetheweb]

Thanks for raising this @juliemoynat !

We hadn't considered the long descriptions to be useful for non-screen reader users, but now you've raised this I agree they would be - and there is no reason not to make them available to all.

Since you've knocked up the code pen already, would you be willing to submit a PR for this?

Questions over your current code pen:

• Not convinced it should be hidden by default, rather than hidden off-screen (as we currently have), as would like this to work without requiring JavaScript as well. What do you think?
• Think we need some more UX work on button.

But in principal I like the idea.

As an example, I learned in the long description of the image about contrasts that the grey boxes are the orange boxes in greyscale. How all people can be aware of it without being able to read the long description?

I'm going to raise this as a separate issue - #856

[juliemoynat]

Hi @bazzadp,

I would like to submit a PR but I'm not good at JavaScript development. The JavaScript code in my CodePen is not from me.

You're right with your first question about the hidden attribute. I added an HTML comment in my CodePen to tell the same thing "Note: it would be better to set up the hidden attribute with JavaScript". But, I don't know how to do it properly…

My CodePen is just an example so I didn't take time to code a piece of CSS.

[tunetheweb]

Well if you want to submit a PR, then we'd be more than willing to help guide you through that and review and suggest improvements to any of the code you submit.

Alternatively, if you'd prefer not to, that's fine too - raising issues so others can correct is also very helpful!

Let us know either way, so others can look at it if you don't want to do this.

[juliemoynat]

Thank you so much for your understanding. I am not ready to submit this kind of PR so I prefer to let others correct it. I could help for tests if you need to.

[tunetheweb]

Knocked up something here: https://20200521t143054-dot-webalmanac.uk.r.appspot.com/fr/2019/accessibility#fig-1

Let me know your thoughts.

Also let me know if Google's suggested French wording for Show Description/Hide Description is the best wording for here!

In addition, the aria-describedby attribute on tag is unfortunately not compatible with screen readers at the moment: https://www.powermapper.com/tests/screen-readers/labelling/img-aria-describedby/

That is interesting. Do these bugs also apply if the alt or aria-labelledby attributes are given in the <img> element? The example in that link has neither but we have both. Just wondering if the lack of an accessible name is causing the main problem in that example page? Though why you'd have an aria-describedby but no accessible name is beyond me so not surprising that some screen readers don't handle that well!

[juliemoynat]

I will answer you in several points below because there are multiple complicated subjects here.

1. About the aria-describedby attribute not compatible with all screen readers when it is on an <img> tag, yes, the bug applies even if the image has an accessible name. I have updated my own test on a CodePen this morning (in French - I'm about to write an article about it). It works in some cases but not at all for NVDA nor JAWS 2020 and the results depend on the browser as well. I don't know why PowerMapper didn't add an accessible name to their example. It's not correct: you shouldn't have a description to an image if it has no name.
   As there is an accessible way to access the long description (the button you just added), I would remove the aria-describedby attribute from the image because it's redundant.

2. The "Show / hide description" button is working well and the French translation is correct. I have two comments about it:

   1. I think the name of the button should contain "Figure 1" like "Show Description of Figure 1". Like this, if there are more than one image with a long description, you would not have several buttons with the same name. It would be better for people who navigate accross interactive elements or for people using voice control. But it could be more difficult for you to do this automatically so I would understand if you tell me that you can't do it.
   2. The image alternative should tell the users that there is a long description available below so that they can be aware of its availability. You can add this piece of text at the end of the alt attribute: "Long description available below".

3. About the accessible name of the image, here we are in the case of a captioned image. In the website, the aria-labelledby attribute is attached to the image caption.

   1. An image shouldn't have two types of accessible name. If you use the alt attribute, it's sufficient and it's the best way to do it (because of the first rule of ARIA: if an HTML element or attribute is available, don't use ARIA). If you use an aria-label or an aria-labelledby attribute in addition to the alt attribute, a screen reader will never read the alt attribute.
   2. In a captioned image, the name of the image is not necessary equal to the caption. To be as accessible as possible, the name of the image should contain a part of text which is in the caption (this is because <figure> and <figcaption> are not compatible with all screen readers, again). As an example, if you're numbering your images ("Figure 1", "Figure 2", etc.), you should have this text inside the alt attribute and inside the <figcaption> element. But, the rest of the text can be different because you don't always need to have the same text as an alternative and as a caption. And they need to be different here because you should add the "Long description available below" text inside the alt attribute ;-)
      So I think you should remove the aria-labelledby attribute.

So in our example, the image with it's alt attribute should be:

<img alt="Figure 1. Example of what text with insufficient color contrast looks like. Long description available below" src="/static/images/2019/accessibility/example-of-good-and-bad-color-contrast-lookzook.png" loading="lazy" width="600" height="278">

And the caption wouldn't change:

<figcaption id="fig1-caption">
    <a href="#fig-1" class="anchor-link">Figure 1.</a> Example of what text with insufficient color contrast looks like. Courtesy of LookZook
</figcaption>

[tunetheweb]

Thank you so much for your valuable input here!

On alt and aria-labelledby

The duplication of the alt and aria-labelledby is something we struggled with for a long time. There seems no clean way of handling single-figure images in a figure, with a visible <figcaption> - that duplicates the alt attribute. While I agree the alt and <figcaption> don't always have to match (particularly for multiple image <figures>), for us it does and I don't think we'd benefit from different text anyway. I agree it's redundant duplication, but thought this was the best way to handle this after reading pieces like this:

Note: When using aria-labelledby attribute on an img element, the absence of an alt attribute will cause validation failures for HTML 4 and earlier and XHTML. If alt is provided, it must contain the same text as the aria-labelledby target. Do not use alt="", which would cause some assistive techology to ignore the image completely.

Additionally this reference states the `aria-labelledby' will be used in preference:

6.8 img element
If the img element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in section 5.2.7. Accessible Name Calculation of the WAI-ARIA 1.0 specification.

img element accessible name calculation

1. Use aria-labelledby
2. Otherwise use aria-label
3. Otherwise use alt attribute
4. Otherwise use title attribute
5. If none of the above yield a usable text string there is no accessible name

So presumably no harm to have both?

To be honest, if it's not causing any harm, I'm tempted to leave this as it's a lot of HTML to change. Should be able to automate removing it with some regexs but, again, if no harm then still tempted to leave as technically they are both correct.

On aria-describedby

The aria-describedby bugs are quite annoying. We seem to have a perfect use case for it here! And the addition of "Long description available below" seems like a poorer substitute which will not expose the actual description to AT elements that do support it.

Additionally that previous reference states this should be usable:

img element accessible description calculation

1. use aria-describedby
2. Otherwise use the title attribute if it wasn't used as the accessible description.

To be honest, I'd prefer to leave this as is for those screen readers that do support this, and in the hope that those that don't aren't suffering too much given that we repeat the image description below now, and the image label in the <figcaption> anyway so they can still get this information. Would you be strongly against that given your testing?

I have taken your suggestion to add the figure number to the button, and also made the buttons bigger on mobile. Checkout latest version here: https://20200521t203320-dot-webalmanac.uk.r.appspot.com/fr/2019/accessibility#fig-1

[juliemoynat]

1. On alt and aria-labelledby: having both is simply useless here. You have a good alt attribute so you don't need to have aria-labelledby. There is no harm at the moment in the present case because you are duplicating both values. But everyone editing content in the website must be careful with this ;-)

2. The Accessible name calculation is not a method telling aria-labelledby should be used in favour of alt. It's a method for user-agents on how to calculate the accessible name of an element. If there is an aria-labelledby attribute, user-agents will consider it over the alt.
   It's like using a tabindex attribute with a great value. If an element has a tabindex="9" attribute, this element will receive focus first over all elements with no tabindex attribute. However, this is absolutely not a thing to do because you would be breaking focus order.
   The accessible name calculation is just like giving a number to each method. We wouldn't use tabindex="9" just because it's stronger, so, in the same way, we shouldn't use aria-labelledby just because it's stronger. The choice should be made in a reasoned way. There is a good article about accessible name if you are interested in: What's in a name?
   The first rule of ARIA is "Don't use ARIA". That's really important to keep it in mind.

3. On the aria-describedby, in my opinion, it is not necessary here and I'm not sure that's a benefit for users to have a very long text on images automatically read by screen readers. If you're telling users in the alt that there is a long description below, users would know that they could have full control on the text below. If the text has lists or other semantic structure, the reading experience would be better. That's a case where we may need some user tests.
   But there is a lot of redundance here: the alternative and the caption are the same and will be read twice for screen reader users. And the description can be read twice too if you activate the "Show description" button and if your screen reader has already read it when you were on the image. You are not aware of it. The "Long description available below" text inside the alt attribute (if there is no aria-labelledby of course) is really important to be aware of the availability of a long description.
   I agree I am talking about comfort and not uncompliance here so you can do what you want :-) I also understand your technical reasons.

By the way, thank you so much for having added the "Show / hide description" button! 👍

[tunetheweb]

On the aria-describedby, in my opinion, it is not necessary here and I'm not sure that's a benefit for users to have a very long text on images automatically read by screen readers.

Oh that's interesting. I presumed aria-describedby was additional information that wasn't read by default and was only read with a key combination (e.g. Alt + R on JAWS).

As per the PowerMapping test:

Note: aria-describedby maps to the accessible description of an object, and is usually only read when a "Say Description" keyboard shortcut is pressed. This is different to the accessible name which is generated from alt / aria-label / aria-labelledby.

That's why I liked creating links via aria-describedby, so the user can hear the description immediately using the tools they are used it, if they are scanning through the documents, rather than them having to go to next item and clicking the button, then the next item.

Now if some screen readers ignore this attribute completely I'm fine (same as removing as you suggest), and if a few screen readers read this out by default, then that's not ideal (though a bug in screen readers IMHO). However if a lot of screen readers read this out by default, then I agree that is far from ideal (though still a bug in screen readers IMHO) and we maybe should consider removing it as you say.

As I say, my gut feel is still to leave as is, for the screen readers that support this attribute properly. Users can always skip past the text if they get bored of hearing it, and they are somewhat used to repetition is my understanding.

Anyway, I think the show hide button is a good addition, and opened #857 for that so hopefully will get that out in next few days, at which point I'll close this issue. But do feel free to continue this discussion here if you can spare the time and have anything else to add - I find it very interesting. Like most things in life, it seems there are no absolute right and wrongs and a lot of this is judgement calls.

[juliemoynat]

When it works, NVDA and VoiceOver are reading the aria-describedby content directly without a keyboard shortcut. But, you can stop the reading experience and then use a shortcut to read the description when you want (but you will need to know which shortcut it is).

A colleague told me that this is the way screen readers should work with this attribute according to official specifications but I didn't succeed in finding a resource about it at the moment.

I've made some others tests this morning and found that, with NVDA, an aria-describedby on an <img> which is inside a link is read but not when the <img> is alone. That's strange. It still doesn't work with JAWS 2020 by the way.

Screen readers obviously need to improve their handling on this topic.

[tunetheweb]

Screen readers obviously need to improve their handling on this topic.

Yup!

And, like with other browser funnies, the question is how much do you work around known issues? A careful judgement call between how badly it's broken for those that don't support it properly, how many people likely to be affected, how much there is to gain by doing it "the right way", how much effort there is involved in working around them, and how much we're allowing the status quo to continue by working around the issue for them!