Exit this Page: Add text to the "ghost page" button feature

[owenatgov]

What/Why

Adds text to the "ghost page" feature of the exit this page button so that we can revisit if this has a positive or negative impact on users. The text is unbranded and unstyled.

Additionally this change moves the button activation announcement for screen readers to the ghost page itself as opposed to the announcement span being used currently.

Closes #3266

Notes

From a quick screen reader test, as I've been finding whilst working on #3061, there is an inconsistency in the button activation alert being announced before the screen reader "beats" the announcement and starts instead announcing navigation and the new page.

[querkmachine]

Code looks good to me.

I assume we're OK leaving $updateSpan reading "[...] press 2 of 3" on activation given we're leaving the page anyway at this point—with either the overlay or the browser hijacking any further screen reader announcements.

I see there's still a discussion ongoing about what the ghost page's text should say, so I won't weigh in on that just yet.

[owenatgov]

@querkmachine Re: clearing the span, I think that it doesn't really make a difference but it probably can't hurt to clear it. Cheers for pointing it out.

[dav-idc]

This generally looks good to me, and I'll add to the discussion of what the text should actually say in the internal microcopy doc. 👍

I've been one of the more vocal proponents for having some kind of status on the blank / loading / ghost page, especially as a way to assure people that the page didn't just crash when they're navigating on a slow connection.

After seeing it in action, I'm still in favour of it, with a couple extra notes of details:

• I think we should rename it to something like 'loading overlay', rather than ghost page. It is neither a ghost, nor a page.
• This loading overlay's text should communicate the current status, ideally without drawing attention to the EtP feature. I like Calvin's current suggestion of "Loading". It says what's it's doing and keeps it simple.
• I think this new "Loading" text should be announced by screen readers, but it's not wildly essential that it gets announced. But announcing it could be helpful for people on slow connections where it hangs for a few seconds before the next page comes up.
• I think we might be able to fully replace the 'exit this page successful' announcement with announcing this 'loading overlay' text instead. It's a tradeoff as far as what info we're providing to screen reader users, but also screen readers aren't reading out the 'success' message anyhow, because there's no time.

[querkmachine]

As another thing that just popped into my head during discussions on Slack: We haven't done anything to ensure that the content beneath the overlay stops being accessible, via keyboard navigation, assistive tech or other means.

Whilst probably a minor issue given the user will be in the process of directing away from the page anyway, it could potentially lead to the accidental activation of a different control or announcement of different text after the EtP button has been activated.

[Ciandelle]

100% agree with renaming the page to loading overlay, feels more in the style of calling it what is it.
Also like the idea of keeping things as simple as possible. In terms of the announcement to screen readers, wouldn't it be better from to announce 'loading complete', rather than 'exit this page successful' if they are in a dangerous situation anyway?

[calvin-lau-sig7]

"Exiting this page" (telling the user they've successfully activated Exit this Page) and "Loading" (You are going to a new website) are 2 separate messages, but combining them does make sense if WCAGs allow.

Just "Loading" might be enough to assure the user that they've activated Exit this page correctly, but it'd be nice to reinforce somehow.

Is there any other way to give an audio indication that Exit this page has activated?

[owenatgov]

Some thoughts from the discussion so far:

Firstly, after seeing this in action I also don't hate it. This isn't 100% informed but my instinct is that this isn't significant or unusual enough that going to put users at risk like we assessed (one for the community crit?).

Secondly, I agree that we should do something about moving focus and blocking the page for the user. I'll work on this next once I'm back from AL.

Finally, on the announcement itself and the inconsistency in how it's announced across screen readers. I don't see a huge amount of harm in having a generic message like "loading" to signify button activation. I also don't think it only being announced some of the time is a major problem. As a reminder, this was found during the testing for #3221 that SRs were rarely announcing the activation message over letting the user know that they were on a new page. I suspect this is the result of a race condition where the browser navigation is "beating" the activation message 99% of the time.

I don't think we should be trying to "hack" our screen reader setup to be more consistent with the exact announcement ecosystem we want, in part because I don't think there's a positive way to do so. role="alert" is intended as the most aggressive way to get an announcement out and all major screen readers know that text changing in an alert region means that they should stop their announcement and read this new status message right away. That's what we're doing and I think trying to stretch this artificially using tricks eg: adding a timeout to give the screen reader time to read the announcement would create technical risk.

I'm personally in favour of giving way to the opinion of screen readers ie: the screen readers think that telling a user they've navigated is more important than quickly announcing this message before navigation, therefore that's what we should accept.

[owenatgov]

Okie dokie, I've fixed the navigation under the overlay issue by adding a class to the body which sets everything to display none. From some light testing, I don't think this requires an !important but I'm not 100% confident. Interested in specific takes on that by @querkmachine and @davidc-gds.

More broadly, I think we're in agreement that we're actually gonna implement this and that the current solution works nicely? Calling additionally on @calvin-lau-sig7 and @Ciandelle as folks in the convo so far for any additional thoughts.

[querkmachine]

A couple of non-blocking comments. Happy with everything else!

I'm inclined to say let's !important it.

[dav-idc]

Okie dokie, I've fixed the navigation under the overlay issue by adding a class to the body which sets everything to display none. From some light testing, I don't think this requires an !important but I'm not 100% confident. Interested in specific takes on that by @querkmachine and @davidc-gds.

Heya! I've read through the comments here and this is the only piece that seems unresolved: to !important or !!important (haha a code joke mixed with Hamlet).

I agree with @querkmachine that this is kind of the situation for which !important was designed.

!important feels appropriate for a few reasons:

• We definitely don't want anything getting through the loading overly and remaining active. Like, there's no exceptions that would possibly be a good idea to allow.
• If a specificity war breaks out accidentally on some service somewhere, it's going to be very hard to identify. The screen persists for only a moment on fast connections, so the likelihood of anyone noticing that portions of the content are still interactive after the overlay is applied is pretty much nil.
• Adding !important here provides contextual value to developers: don't override this thing, whether by accident or intentionally.

[Katrina-Birch]

Going back to Ciandelle and Calvin's comments about the wording. Whilst 'exiting this page' and 'loading' are two different messages, and the former is a more accurate description of what's happening, I err on the side of 'loading page' to avoid any association with Exit this Page.