Editor: Manual testing using keyboard and screen reader

[swissspidy]

Task Description

The editor and the dashboard need to be usable via keyboard and have sufficient screen reader support. In a first step, we need to thoroughly test the current behavior. This way, we can uncover many low-hanging fruits that we can subsequently address.

We want to fix the biggest issues in this area so that we can kick-off a full accessibility review afterwards that will actually result in useful feedback. As long as we have many well-known issues, such a review does not make sense though.

Note: Testing should be done by engineers as they have the necessary context for how the app is built and which issues are to be expected.

[swissspidy]

Some resources from the doc:

VoiceOver user guide (macOS)
ChromeVox user guide (Chromebook)
ChromeVox Classic browser extension (Google Chrome)
Web Content Accessibility Guidelines (WCAG) 2.1
Accessibility Developer Guide
Lighthouse Accessibility Audit
WebAIM

[swissspidy]

As the ticket says, this will involve testing the editor using keyboard only, and finding out which parts of the editor can and cannot be interacted with, and how screen readers announce changes when doing so.

If not familiar with the resources above, there's also a quick guide at https://rianrietveld.com/2016/05/keyboard/ that covers the basic of testing keyboard navigation.

Reminder: this exercise is for us to find the most pressing issues, and also get some familiarity for testing using the keyboard in the future. We're not the a11y pros here, and we'll leave the more extensive testing to the experts later.

Screen reader recommendations:

macOS: VoiceOver (built-in)
Windows: NVDA (free)
ChromeOS: ChromeVox
Browser: ChromeVox Classic (no longer supported, so use with care, and perhaps only in combination with NVDA/VoiceOver

VoiceOver

On a MacBook, press CMDF5 to enable VoiceOver. You can configure VoiceOver using the built-in VoiceOver Utility.

Navigation: Control + Option is the VoiceOver key.

Key	Behavior
VoiceOver key + left/right arrow	move around the page
VoiceOver key + command + H	skip to headings
VoiceOver key + command + J	skip to the next control
Control	stop verbalization
VoiceOver key + H > H	display a full list of shortcuts
VoiceOver key + U	open rotor (which allows you to customize navigation and focus on browser content inside Chrome)
VoiceOver key + Space	interact with an element

Note: make sure to enable full keyboard access in the macOS system prefs.

NVDA

To configure NVDA, press Insert + N or Caps Lock + N and navigate to Preferences.

Key	Behavior
NVDA key + Arrow	move around the page
NVDA key + H	skip to headings
NVDA key + B	skip to buttons
Control	stop verbalization

More shortcuts can be found at https://webaim.org/resources/shortcuts/nvda

General Info

Interaction Modes:

There are two different interaction modes that a screen reader can be navigating in: forms mode and application mode. If keys suddenly stop doing what you expect them to do, you may have unintentionally triggered a mode switch. You likely should restart your screen reader.

See https://tink.uk/understanding-screen-reader-interaction-modes/

Accessibility Tree

The browser converts the DOM tree into an accessibility tree, which is what screen readers interact with. In Chrome, you can view the accessibility tree for easier debugging by going to chrome://accessibility. You can also inspect it in more detail with this extension: https://chrome.google.com/webstore/detail/automation-inspector-exte/magknkflhkbbjaalinnipadaihkbghoc

[barklund]

I have created a number of tickets from this review all linked to the epic #117.