SPIKE: How should we communicate Exit this Page interaction to screen readers?

[owenatgov]

What

Investigate how best to communicate to screen reader users that they are interacting with the Exit this Page button. Specific questions we want to answer:

• Does the current 3 x Esc keyboard activation interfere with any screen reader functionality in such a way that it causes problems for users?
• How could we communicate that the Esc key has been pressed without causing interference for user announcements?
• How could we/should we let users know they've activated the button?

Epic: https://github.com/alphagov/govuk-design-system/issues/1755

Prototype: https://github.com/alphagov/govuk-frontend/pull/2545

Time limit: 1 week

Why

Following research on Exit this Page with users with access needs, we hypothesise that we need to better communicate the use of the button to screen reader users. However we're not confident about how much we should communicate to the user, how to communicate and if our current implementation hampers this.

Who needs to work on this

Developers, Accessibility specialists

Done when

• [x] Investigate use of esc key in assistive tech
• [x] Investigate communication of esc key press against assistive tech
• [x] Investigate communicating button activation to users
• [x] Write up findings and potentially recommendations
• [x] Implement recommendations (if any) into prototype

[owenatgov]

As I'm investigating this, despite an effort to rework the 3xEsc key functionality, I'm finding that it doesn't work at all on firefox. There seems to be a push-pull of bugs between 3xEsc not working at all in firefox and it being very choppy or not working on pages across all browsers where the user has yet to interact with the page in a meaningful way. Will continue to investigate.

[owenatgov]

Investigation findings

I've put together a testing sheet to record my findings.

Summary of results

• JAWS is the only screen reader that will articulate when a user presses a key, in this case "escape"
• Most screen readers don't provide clear, consistent indication that navigation has occurred ie: that a link has been clicked. JAWS on edge will announce "loading page", NVDA will sometimes announce "busy" and VoiceOver has a dedicated chime to indicate navigation
• I opted for creating a span on js initialisation with the attribute aria-live="polite" and would update the text to update screen reader users of status
• Adding content on key press worked well, although by the time the user is announced the message (to test I used the phrase "Exit this page key press {count} of 3") the key press timer has run out
• I wasn't able to reliably test announcement on activation, see below section

Technical issues

In the above comment I mentioned that the 3xEsc feature wasn't working reliably. I believe it's in a reliable state now, however the reason I believe it was being unreliable and in some cases actively broken was because browsers were flagging the js as malicious code. I can't find any documentation or evidence for this so it's purely my speculation, although it wouldn't be surprising if browser vendors made a conscious choice not to document this for security reasons. A lot of what we're doing for Exit this Page risks making browsers "suspicious" even if we don't have any ill intent.

Parts of the code that browsers appear to take note of when determining if code is malicious or not:

• "messy" code aka: code that looks like it's not part of a professional codebase or is intended to intentionally obfuscate intent
• making direct changes to window.location via non traditional means such as a key event instead of a click
• assigning event listeners to links
• mutating the page in the same thread as a navigation event eg: changing the innerText of an element
• Using certain keys in keydown events. When I changed the triggering key ot something other than escape, a lot of the problems I was facing stopped

That latter one has meant that I've not been able to get the 3xEsc functionality working without abandoning the update on navigation.

Thoughts and recommendations

I think the button press announcement needs content designing but don't think it's necessarily a derogatory feature. We could also consider expanding the key press timeout from 2 seconds.

The lack of ability to reliably announce button activation is problematic. We may have to weigh up the value of the 3xEsc feature vs activation announcement. I don't think it's critical that we announce button activation as it's a pattern in screen readers to not explicitly announce navigation.

The technical issue on adding listeners to links may have a negative impact on future feature investigations, most notably https://github.com/alphagov/govuk-design-system/issues/2389 which would be tied to button activation.

[owenatgov]

Update

I've managed to get the 3xEsc feature to work reliably by switching the event listened for to trigger the behaviour via keyup instead of keydown. I'm not certain exactly if there's different weighting between the 2 events in terms of what counts as user interaction or of keydown is already being used in browsers for something else.

I've therefore updated the testing sheet linked above with results on activating the button.

New thoughts and recommendations

I think both an announcement that the esc key has been pressed and that the button has been activated have value. I think the latter far outweighs the former as we've identified that the time it takes to announce the message cuts into the key timer.

[jbuller]

It's is an interesting challenge to balance informing the screenreader user what's going on vs their abuser not hearing it as they approach (and a similar one for voice input users too).

[owenatgov]

Some extra thoughts from a chat with @davidc-gds:

• This covers WCAG 4.1.3 which notes that status changes should be announced to screen reader users. The criterion documentation notes 2 points that are relevant to us:
  • You need to document why you omit a status update if you do
  • You should only use role="alert" if your status update is important and/or time sensitive
• We think it's ok to omit an announcement saying that esc has been pressed 3 times and that the announcement that the button has been activated is enough here. How we articulate that or if we even need to is still unclear
• The choice of aria-live="polite" might not be the right way to let the user know as it technically is time sensitive and important, however role="alert", especially when the user might be using the esc key for other things, might be stressful for the user if they're getting announced to a lot
• The update message should probably be called from the relevant place ie: once we've finished exploring https://github.com/alphagov/govuk-design-system/issues/2390 we should consider announcing the esc key press from the semantic location of the visual change.

For now I'm going to close this and we can assess the results of all the button behaviour spikes current in flow as one to see how they might impact each other and how to solve some of these lingering problems.