Accessibility Projects: Studio

# Accessibility Projects: Studio 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. # Adding Keyboard Shortcuts to Opencast Studio ## Summary Opencast Studio, especially the built-in editor, does not support any keyboard shortcuts at the moment. ## Goals Add keyboard shortcuts to Opencast studio where it makes sense. This means first and foremost to the player on the editor view. ## Non Goals Not all functions need keyboard shortcuts. ## Potential Risks Relatively risk-free. ## Success Criteria - Play/pause with keyboard shortcut possible - Setting trim marks via keyboard possible ## Benefits/Rewards - Improved accessibility in Opencast Studio - Developers learn how to include keyboard shortcuts # Dark Mode in Studio ## Summary 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. ## Goals - Implement dark mode in Studio - Users should be able to enable the mode in the settings - By default, it should be set to `auto` to respect the user's system settings if possible - Studio should remember the user's settings ## Non Goals - No custom designs ## Potential Risks - Low risk ## Success Criteria - A dark mode should be selectable on all systems ## Benefits/Rewards - Learn about detecting system dark mode - Better supporting visually impaired users ## Notes - We can likely extend these pull request: - https://github.com/elan-ev/opencast-studio/pull/902 - https://github.com/elan-ev/opencast-studio/pull/909 # Tab Navigation in Opencast Studio ## Summary Right 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. ## Goals - Make sure main components can be reached via tab key - Make sure active elements are visually distinguishable - Make sure elements can be activated via keyboard - Make sure we have sensible attributes ## Non Goals - No full accessibility analysis - No keyboard shortcuts ## Potential Risks Low risk ## Success Criteria A user can create a full recording with no mouse. ## Benefits/Rewards Accessibility improvement for motor impaired people and for visually impaired people using screen reader. # Accessible Tooltips in Opencast Studio ## Summary 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](https://atomiks.github.io/tippyjs/) for rendering [in the Opencast documentation](https://github.com/opencast/opencast/pull/3512): - [accessible-tooltips.mp4](https://data.lkiesow.io/opencast/accessible-tooltips.mp4) ## Goals - Use tippy.js to render persistent toooltips - Make them adhere to the default theme ## Non Goals - Not changing any tooltip textx and/or evaluating their usefullyness - No design evaluatioon for how they should look exactly ## Potential Risks - Low risk ## Success Criteria - Studio renders tooltips similar to Opencast's documentation ## Benefits/Rewards - Improved accessibility - Improved look and feel # Research good tool independent keyboard shortcuts ## Summary 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. ## Goals 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. ## Non Goals Not actually implementing any shortcuts anywhere. ## Potential Risks None. ## Success Criteria A set of at least 10 commonly used shortcuts for web-based media tools. ## Benefits/Rewards It's less confusing for users if they do not have to re-learn shortcuts with every tool they use.