Assess accessible approach to thumbnail images in browse lists

[kimisgold]

We've received feedback that our current approach to accessible thumbnails is insufficient. Currently, Omeka Classic provides the filename or title of the primary media thumbnail representing a resource. Here are some possible solutions:

• Set a blank alt tag, marking the image as a decorative portion of a text link.
• Setting aria-hidden="true" so that screen readers skip the thumbnails altogether.
• Using the primary media's description metadata, with either of the previous two solutions as a fallback.

I would love thoughts from screen reader users or others more well-versed in accessible practices.

[sharonmleon]

I don't have anything useful to contribute here, but I figured I'd tag in @allanaaa and @mebrett for thoughts.

[zerocrates]

I'd definitely say blank alt over aria-hidden though I'm not sure we want either.

The S solution has blank alt as the default but lets users set the desired alt (or choose to show a, in classic terms, element).

[allanaaa]

An image needs alt text when it expresses information that the text around it doesn't. In this case, a thumbnail definitely expresses information we can never expect to be contained in any other metadata field. That's why we show them.

In particular WAVE wants an image in a link (a link that doesn't also contain text) to have descriptive text, but it's not clear if they care more about the image or about where the link goes.

Why It Matters Including appropriate alternative text on an image within a link ensures that the function and purpose of the link and the content of the image is available to screen reader users or when images are unavailable. What To Do Ensure that the alternative text presents the content of the image and/or the function of the link. If the full content and function of the link is presented in text within the link (an image and a text caption both within the same link, for example), then the image should generally be given empty/null alternative text (alt="") to avoid redundancy.

I think the best practice would be "Intentional image description alt text or nothing." But then we'd have a lot of nothing.

I'm not sure what precisely the feedback was, but I think that this is not totally on our end? When the site builders themselves don't supply media titles, we have a fallback. For max accessibility, we would just require them to supply titles / alt.... But I don't think we're going to do that.

For now, we could improve the admin interface by strongly recommending people enter media titles, letting them know it will be used for alt text and how important that is. (And that they may be required by law, right?)

But personally, I think a filename fallback is better than nothing, and better than an item-title fallback that is just redundant to what's already on the page. Maybe we should have a longer series of field fallbacks (media title, then media description, ....., then filename).

https://wave.webaim.org/report#/https://scottishchapbooks.lib.uoguelph.ca/items/browse

WAVE found some of the filename alts suspicious and liked others. We are sending a lot of redundant image titles. And the one with good alt text description is actually flagged as "too long" (under 100 characters is what it wants).

[kimisgold]

Could we do something like an "Accessibility" tab for media? I'm thinking it could include a metadata field for alt text that would call attention to the 100 character limit, and maybe upload fields for video captions or subtitles. I'm thinking that using the Dublin Core description, if used, is almost always going to exceed that small limit. It could also raise awareness to web accessibility needs among our users if we call attention to it well.

[zerocrates]

An explicit input for alt seems like a good idea, it's definitely come up before. And of course we now have it in S's core. We can indicate a suggestion of a limit but I wouldn't actually limit it probably.

As for captions, it's a technical issue to upload a file "to" another file that would be relatively complex.

[kimisgold]

I can appreciate that complexity. I was mainly thinking that having files specifically flagged as video tracks could make rendering them in the core easier.