Alt text for original file display defaults to file name

Omeka S Accessibility
1

Our site is: Welcome · BJ Bud Memorial Archives Exhibit · ASU Library Exhibits

I am modifying a child theme of Lively 1.1 to implement better accessibility in general.

Despite all my attempts, I couldn’t get Omeka (core and modules all latest versions) to default to the title or any other of our Dublin core fields no matter what I picked in global settings for the media alt text property field. Then I read the forum question about the media alt text property and what metadata it’s using, and since the media title is apparently the filename and there is no other metadata connected, this global setting isn’t going to work for me.

So, I’ve resorted to editing the theme templates to improve a couple of key accessibility issues:

  • Set grid thumbnails to not be links since the title text links to the same item page, and set the alt text to empty for unlinked thumbnails.
  • Set the item page alt to the title text if there’s no custom alt text associated with the image.

These changes have improved alt text and accessibility for images across the site, but, I’m running into a problem when linking to the original file as part of the item page features. See this example: Miss Arizona Gay Rodeo Association 1992 · BJ Bud Memorial Archives Exhibit · ASU Library Exhibits

On the item page, if no custom alt text is associated with the file, the title gets used, which is what I want. However, if one clicks the image to view the original file, the default alt text becomes the file name again. I can’t find any theme file to edit or other setting to change that can stop the use of the file name in this instance if there’s no custom alt text accompanying the image. Is there such a theme file in general?

I am only assisting with technical aspects of our site and am not the person who is in charge of the data. If the solution is the data person needs to include additional metadata or custom alt, that’s the answer I can take back to my team, but if there’s a way to control the alt text on this last leg of the link tree to see the image, I’d really like to find that solution and implement it for a better user experience sooner rather than later. Updating the metadata may take a while.

I’m relatively new to Omeka so maybe I’m missing something but I’m not finding anything to help me in the docs so I’m asking here. Appreciate any and all feedback!

2

If I read you right, your concern is about what’s happening after you click the image on the page you linked to, so the actual original image itself.

If so, that’s just the browser’s display of the image and we don’t have any control over that.

3

Hello! Appreciate your response!

It is the file display in the browser, yes, but I’m stumped as to why that display defaults to inserting the filename as the alt text. That’s not default browser behavior. The browser should render an empty alt tag if there’s no alt text so I’m assuming the insertion of the file name as alt text might be default Omeka behavior? Or would that be a theme default behavior?

For example, on the rendering of this image: https://exhibits.lib.asu.edu/files/original/1ba84cc845ec6823ad2fe49ab9dd80360916ecda.jpg, the HTML alt text output looks like this:
<img src=“[image file path- same as above]” alt=“https://exhibits.lib.asu.edu/files/original/1ba84cc845ec6823ad2fe49ab9dd80360916ecda.jpg” width=“640” height=“938” class=“shrinkToFit”>

Again, I’m very new to Omeka and surely missing something but I just can’t seem to find any documentation on this particular display or find where I might be able to fix the accessibility issue of outputting the file path as alt text programmatically. Thanks for any feedback and advice!

4

There’s no Omeka or theme influence there at all; it really is just the browser’s default rendering and nothing we’re doing affects it.

To double-check: you should get the same browser-generated markup on any direct link to an image, like this one (the Wikipedia image of the day).

5

Thank you for that clarification- the non-Omeka example really helped. I honestly never noticed that behavior before but I can see it in your example. I really appreciate it!