I work in academic technology at Harvard, and my team supports an Omeka Classic service for our students and faculty. There is also a new digital accessibility group at the university, and have recently asked them to take a look at some of our Omeka sites to identify accessibility concerns. We did identify some issues in the admin dashboard, namely around color contrast, input labels, link clarity, and TinyMCE’s keyboard accessibility. There were some issues on the public-facing side as well, but we focused on a theme I made and that we have as a default: https://github.com/jaguillette/hvd-dh-omeka-theme
We plan to at least make some accessibility-oriented changes based on their feedback to our own fork of Omeka, but would prefer to make changes in a way that makes them easy to merge upstream, since they should benefit Omeka Classic users in general.
This seems like the start of a longer conversation, but I wanted to post here to get started, and make sure that our work is broadly applicable.
We are, in fact, in the midst of an admin reskin for Omeka Classic, so this your post is really timely. We’re aiming to get this release (v.2.8) out in October.
We would love to hear from your group about what they’ve discovered so that we can cross-check with our own assessment. We could go either of two routes on that: 1) you could just share your findings here; or 2) you could make an issue, or a set of issues on the core repository (https://github.com/omeka/Omeka).
Thanks for your willingness to help improve the platform for everyone!
It sounds like our timing is unusually good! I’ll start by posting the issues we’ve identified here. I’m happy to add them as issues to GitHub, but I want to get a sanity check on their scope before potentially confounding the issue tracker.
Color contrast - Mostly the orange/tan combination in the admin console. I like tota11y for visualizing color contrast issues, and it even suggests alternatives.
TinyMCE - The formatting buttons aren’t included when tabbing through fields, although you can access them with Alt+F10 with a cursor in the text field. The focus indicator for those buttons is also very low-contrast, but the interactive demo of the latest TinyMCE has much better focus indicators. It uses the same interaction pattern though, which ought to be telegraphed to keyboard and assistive technology users. That could be through regular text, but I’m currently looking into any alternatives that might be preferable.
Link purpose - The edit, delete, and details links on lists of items, collections, and exhibits aren’t specific to the item they reference, so a screen reader pulling out links will see a repeated sequence of “Item name, details, edit, delete”. We’re looking at adding item titles to those links with a visually hidden span of text, as in the visually-hidden class in this example codepen.
Input labels - The metadata inputs on items and collections aren’t labelled as to which field they refer to, so it’s difficult for someone using a screen reader to figure out what they refer to. The accessibility team here recorded a screencast of what shows up when editing metadata.
Drag-and-drop only re-ordering - In both the navigation settings and exhibit page, there isn’t a way for a keyboard-only user to rearrange the navigation/pages. In the navigation settings, a keyboard user also can’t expand the navigation item details, as tabbing through the page skips the arrow to expand those details. Those arrows could be made into buttons, and there could be text input fields to change the order of items, but I’m not sure how to handle nesting.
Those are the categories of issue that we found in the admin interface. Some of them, like input labels and link purpose, have implications for plugins as well, so I’m hoping that we can establish some best practices for plugins to adopt as they are able.
If those 5 things make sense as issues for the Omeka repo, I’m glad to add them there.