Hypothesis client remaining a11y work

hypothesis-client-wcag-a11y.md

This is a brain-dump of remaining work to achieve a fully accessible [1] Hypothesis client.

[1] fully accessible means that you can use all the functionality with a keyboard (or keyboard-emulating input device) and screen reader (or other assistive tech) conveniently and that it meets (both in letter and spirit) all the WCAG criteria. That doesn't necessarily mean that everything is as fully optimized as it could be (eg. in terms of what keyboard shortcuts are available to speed up various workflows).

Development tasks:

1. Make it possible to activate highlights with the keyboard
2. Make it easier to execute Annotate / Highlight commands using the keyboard
3. Group elements in the sidebar into helpful landmarks to enable faster navigation
4. Implement an accessible Preact replacement for the "flash" service to serve alerts to users when errors happen / actions are not possible etc.
5. Implement standard keyboard interaction + focus behavior for menus
6. Convert editor toolbar in a toolbar widget with standard interaction + focus behavior
7. Investigate changing highlighter behavior to avoid heavily highlighted areas of text becoming very noisy/chatty when using a screen reader
8. Update our a11y guidance for developers in the frontend toolkit repo following lessons learned during this project

• This could include: Links to additional resources, how to use automated a11y checks, tools for manual a11y checking, a short summary of the core 4 WCAG objectives.

9. Fix the client bug where it is impossible to open/close the sidebar when VoiceOver (iOS) or TalkBack (Android) is active

Related development tasks:

1. Extract shared client utility code for testing etc. into a package that both the client and lms frontends can use

Non-development tasks:

1. Arrange and execute testing of the client + LMS app with users
2. Review previous WCAG audit and identify whether there is anything mentioned that is not addressed a) by the work we have already done and b) the work listed under "Development tasks" above. Identify what work needs to be done before it is worth scheduling another external WCAG audit
3. Arrange another external WCAG audit. Review results and file issues for any outstanding work.

Bonus stuff for the future:

• Prototype ARIA annotations support once Chrome has implemented enough for us to test (see https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/2uume_z0n8M)
• Prototype dark mode support throughout the app as an a11y feature (anecdotally I have heard from multiple friends that dark mode was very helpful during periods of temporary vision impairment due to eg. eye operations)