An initial list of potential accessibility projects for Opencast Studio. We already started working on this, but we do not guarantee that we fix all (or any really) of the listed issues.
Projects are in no particular order.
Opencast Studio, especially the built-in editor, does not support any keyboard shortcuts at the moment.
Add keyboard shortcuts to Opencast studio where it makes sense. This means first and foremost to the player on the editor view.
Not all functions need keyboard shortcuts.
Relatively risk-free.
Glare sensitivity can be one type of visually impairment. This means that bright white surfaces can cause problems for users. This can be particular bad if users have to switch between dark and bright interfaces.
To prevent this, it would be great for Opencast Studio to have a dark mode. Even better would it be if the mode would automatically be triggered by a user's system being in dark mode.
auto
to respect the user's system settings if possibleRight now, a lot of elements can only be reached via the mouse in Opencast Studio. Tabbing through active elements and activating them via keyboard should be possible.
Additionally, sensible title
and aria-label
attributes should be used in the user interface.
Low risk
A user can create a full recording with no mouse.
Accessibility improvement for motor impaired people and for visually impaired people using screen reader.
Toooltips (e.g. HTML title
attributes) are great to add additioonal explanations to control elements. They are – in combination with aria-label
– also picked up by some accessibility tools to help users further.
But non-persistent tooltips can unfortunately hinder accessibility. Users relying on screen magnification tool may be unable too read the whole tooltip since only part of the actual screen is visible.
For example, here is screen magnification being used with default title
attributes vs using tippy.js for rendering in the Opencast documentation:
We have several tools with similar functionality which already support keyboard shortcuts or should support them in the future. We should make sure to not use different shortcuts for the same function.
Research and define a set of ideally well established of keyboard shortcuts for common functionality (play/pause, seek, search, …) we can then implement across different tools.
Not actually implementing any shortcuts anywhere.
None.
A set of at least 10 commonly used shortcuts for web-based media tools.
It's less confusing for users if they do not have to re-learn shortcuts with every tool they use.