Hi,
As part of the process of rolling out Omeka S (initially to our Library staff) as a production service our Institute Accessibility Office has done some backend (admin) interface testing with screen readers, given us some feedback along with possible remedies and we’re wondering how best to handle the issues they’ve brought to our attention? I’ve started to look through the Github issues page (Issues · omeka/omeka-s · GitHub) and assuming that’s where we might add some of the issues mentioned below, particularly with regard to working with Page blocks, adding attachments, error message displays, and other edit-related tasks, if it seems appropriate? I’ll try to list examples of the feedback we received below.
Use grouping and group Labels
Each block should have a group label. This provides context as the screen reader user tabs through the interface. Right now, all the user hears is the label of the thing they land on. For instance, most blocks have a “collapse” button, or a “remove value” button. As you tab through and land on “remove value”, you then need to back up and figure out what block / group your actually removing a value from. This is inefficient and error prone.
- use fieldset and legend elements to create element groups (standard HTML; no aria required)
- or use aria-labelledby (requires aria, lots of element IDs)
Add more shortcut keys to editor
• creating headings, perhaps something like alt+shift+1 through alt+shift+6 for headings 1 through 6
• shortcuts for adding numbers and bulleted lists
• markdown could be another consideration
o maybe a toolbar button with shortcut to invoke markdown mode
o or perhaps a user preference allowing you to choose to have all html entry done via markdown rather than WYSIWYG editor
Displaying errors
Error may appear silently to screen reader users (e.g., receiving an error on save)
• use role=“alert” on each error message when adding to the DOM
• or add html to an existing container whose attributes include a live region role or other live region attribute
o roles: “status” and “log”
o attributes: aria-live, aria-atomic
• see the following to learn more about live regions and alerts
o ARIA live regions - Accessibility | MDN
Adding attachments can be problematic
• create a media embed block
• click “add attachment”
• choose a thumbnail size, or choose whether to show the title; no way to choose the media to be added
A set of choices opens….but the screen reader has no idea that the page has changed, so you need to code this semantically like a modal / dialog (i.e. it doesn’t need to look like one visually).
• add role="dialog" to the container • add aria-labelledby=“id-of-popup-title” to the container
• if a message should be announced (say instructions or whatever) you can add aria-describedby=“id-of-message” to the container as well
• add this to the DOM
• shift focus to a focusable item inside the popup container
o if it’s just a message then this is the close or OK button which dismisses the popup
o if there are other things in there like options to choose, then focus on the first of these (which should of course be properly labeled)
• be sure that when the popup is closed / dismissed, focus returns to the “add attachment” button, or whatever control launched the popup
There is now a dialog element in HTML which has become widely supported which may be useful. See: ARIA: dialog role - Accessibility | MDN
Adding a media type
When you click an item such as “brittle end paper”, the selection dialog closes, or is replaced by one which allows you to add a caption.
• the caption field should gain focus when this appears
• the caption field has no programmatically attached label (i.e. screen reader should announce “caption” when it gains focus)
Block ordering
• Suggest the easiest approach would be to create a list of block titles, then allow cut / paste operations on this list (think typical file manager where you can select a file in a folder list, cut it, move to another place in the list, and paste).
Again, we can open Github issues (would try to group some of them together)?
Thanks,
Carl