React-datocms Image's placeholder images have both alt="" and aria-hidden

[samuel.garbo]

Hello!
In our React project (using create-react-app) we have strict accessibility requirements and have an accessibility expert for accessibility testing. I used react-datocms Image’s blur-up placeholder feature but the accessibility expert wanted to remove the aria-hidden attribute and just use the empty alt tag because it is not semantically correct to have both. Decorative images that the screen reader doesn’t need to read should have only alt=“”. The tester said that since we are not sure if all screen readers can interpret it correctly when you have both aria-hidden and alt=“” I should remove the blur-up placeholder.

Would you be interested to make a fix and remove the aria-hidden attribute from the placeholder images?

[roger]

Hi @samuel.garbo,

Welcome to the forum, and thank you for bringing this up!

I hope you’ll allow some discussion on this topic, perhaps with your accessibility expert involved?

I’m not an expert, but it looks to me like the ARIA specs explicitly allows using aria-hidden with alt="": https://www.w3.org/TR/html-aria/#el-img-no-alt

In fact, it is the only allowed aria attribute when alt text is empty:

I think (but am not sure) that the underlying rationale here is that alt="" mainly targets screen readers, but there may be non-screen-reader assistive technologies (voice control?) that might otherwise consider that item focusable if aria-hidden were not also included: https://www.w3.org/TR/wai-aria-1.2/#aria-hidden

There are also edge cases where certain screen readers might try to parse out a readable image name, even with an empty alt text (https://tinytip.co/tips/a11y-voiceover-svg-title/), or where they may read out “Blank” instead of nothing at all (https://www.powermapper.com/tests/screen-readers/labelling/img-null-alt/).

On the other hand, in my limited research, I couldn’t find any instances of aria-hidden causing alt="" handling to break. If anything, it just seems like a superset, a stronger hint to ARIA-respecting software, while still allowing alt="" to act as a fallback where necessary. It seems like the ARIA specs explicitly allow the two to be used together in this way.

Does that sound reasonable? Just trying to make sure we’re doing the right thing here! Please do let us know if your expert disagrees.

[roger]

I also checked with our UX person, and they mentioned that sometimes our image component is used inside other components (like buttons), and we don’t want the inner image to be separately focusable (regardless of alt text) because it’s just a decorative addition. The ARIA specs won’t let us use role-* if the alt text is empty, so aria-hidden also helps there.

Still, please let us know if your accessibility expert disagrees with our analysis, or if they have real-world experience with this combination breaking in unexpected/unintended ways. We’re not experts in this regard, so if you have better information, we’d love to listen and learn.

Thank you!

[samuel.garbo]

Hello @roger,

Thank you for your helpful replies. Yesterday we discussed again on the topic with our accessibility tester and accessibility-focused developer. In the end, the tester accepted the usage of the blur-up placeholder. It seems the tester had some misunderstanding on the purpose of the placeholder component so after clearing it up it was ok to use it.
Sorry for bringing this topic up even though everything was fine

[roger]

No problem at all, thanks for double-checking and getting back to us!

And web accessibility is something that’s all too frequently overlooked. Thanks for taking it seriously!