[Spike] Add visual escape key indicators to exit this page button

[querkmachine]

Related to alphagov/govuk-design-system#2390.

A first pass at adding a visual indicator of the 3× escape key functionality on the Hide/Exit This Page button.

Standalone example: https://govuk-frontend-pr-2940.herokuapp.com/components/hide-this-page/preview

Changes

• Add a function to dynamically build and inject the indicators into the page. They don't do anything without JavaScript, so it seemed sensible to not include them in the HTML/Nunjucks that we ship.
• Add a function to update the indicators by adding and removing classes from each individual 'light'. I originally tried something with fancy CSS, but it was hard to read and seemed unlikely to work properly in older browsers.

Other changes:

• Moves the loop that initialises the component to all.mjs. This makes each instance of the component functionally independent, aligning this component with how others work and preventing some issues with cross-contamination if there were multiple buttons on the page.
• Relatedly, there is now an explicit check to see if the escape key functionality (which we don't want initialising multiple times) has already been initialised.
• Renamed some variables to match the convention of prefixing $ to variables containing elements.

Implementation thoughts

At the moment, I've made it so that the indicator lights are always visible. This is so that the button doesn't need to change size (potentially requiring page content to reflow) when the user hits the escape key.

No part of it concerns itself with screen reader announcements, as that is covered by a different spike: alphagov/govuk-design-system#2386

I've not made any major assumptions about the visual design this could take on. I've started with 'three lights' as that was the idea posed in the initial issue. I've pondered some others, but not prototyped them:

• A 'progress bar' style design would be more subtle and potentially space efficient, but also be easier to miss without utilising a more bespoke design (e.g. filling up the background of the button).
• A circle that fills itself up in three slices would be more space efficient, but is more technically complex and could be confused for a 'stuck' loading indicator by an end user.
• The existing 'three lights' but in a different arrangement (such as a triangle) would also be more space efficient, but removes the visual association of progress brought on from the lights moving from left to right.

[owenatgov]

This is looking great! I'll let our lovely designers weigh in more thoroughly on this but some little thoughts:

• Considering that we're planning to explore implementing a ghost page on activation in SPIKE: Investigate "ghost page" after clicking Exit this Page button govuk-design-system#2389, we should design this on the basis that the user may not see the final light in the progress bar
• We'll be recommending users implement a fake skip link at the top of the page, under our skip link component, meaning that with the current implementation, there will be 2 buttons on a page using the button. Considering we're expanding the behaviour of the visual button, I'm wondering if we should change how we treat the extra skip link to not be an extra button but instead be a separate entity with a govuk-js class but no data module. We could add a listener for it which hooks up to the activation event handler, meaning we cal reliably only look for one EtP data module.

[christopherthomasdesign]

Sorry for the delay looking at this! Some thoughts.

When the icons show

To my eye, the 3 circles clutter up the button and, like a lot of icons, have an unclear meaning until you 'activate' them. I'm wondering if the icons should only show after the first time a user presses the escape key?

What the icon looks like

I think the 3 dots have a clearer meaning once activated. But like the above point, they do take up quite a bit of space.

If we don't think it's a good idea to hide them until someone presses escape, I think we should look at an alternative option. If we do that, let's have devs & designers working more closely together on how that could look.

A more detailed point on style – the 1px outlines on the circles look a bit low contrast to me. Don't think it's a WACG issue though AFAIK, what do you reckon @davidc-gds ?

Clashes with other icon?

I'm not sure if this is captured anywhere else yet, but I know there was a discussion about having a permanent 'exit' icon included in the button to make its function more immediately clear (checking with @Ciandelle??). Options for that icon included one similar to an exit sign, or an arrow. It'd probably sit at the right hand side of the button too. Worth mentioning because if we want to do both, the visual design's gonna have to change so they don't clash with one another.

[Ciandelle]

My thoughts on this are:
I love the simplicity of the lights themselves, though I am concerned about the cluttered feeling of the overall button as well.

I would second @owenatgov comment about users not seeing the last light, I wouldn't expect them to see it unless they had a really slow connection.

I agree with @christopherthomasdesign that hiding them before the esc key is used would be a great way of minimising some of aforementioned clutter. I also question if 3 seconds is long enough before the key becomes inactive. Thinking mostly from an accessibility point of view, would there be an instance in which it would take a user longer than that to press the button?

Finally on the point of using an icon/arrow, I'm uncertain on the added benefit of this. Although I like the idea from a purely visual stance, I feel that it would make the button too conspicuous, which goes against the key principle of the button. I feel that the button needs to be as simple and close to our others as possible, otherwise we risk drawing a potentially abusive person's attention to something.

[querkmachine]

In my experience the third light is visible, albeit briefly, on my (not particularly slow) internet connection. You're right that it's dependent on a whole bunch of factors including network speed and cacheing though.

The third light will definitely not be visible if we proceed with the 'ghost page' functionality.

My reasoning for having the indicators always be visible was to prevent the button having to resize or change position to account for them becoming visible. We could have it so that they're invisible but still take up space, but that leaves us with a button that is a bit awkwardly sized, regardless of where we put the indicators.

[christopherthomasdesign]

We could have it so that they're invisible but still take up space, but that leaves us with a button that is a bit awkwardly sized, regardless of where we put the indicators.

Oh that's a very fair point the spacing's gonna look weird if we don't show it but leave a space...

[querkmachine]

I guess an alternative approach would be to show the indicators outside of the button (e.g. below it)? That way there is still a reserved space, but it's 'invisible' in most circumstances.

[christopherthomasdesign]

Possibly, though that could open it up to issues with clashing with other content e.g. if used on a heavily zoomed screen and is stuck at the top, where do they go then?

I think the 3 dots look ok within the button, but to be sure it's probably worth @Ciandelle and I doing a quick exploration into different visual ideas in case we can come up with something less obtrusive

[querkmachine]

I've pushed up an amended spike which:

• moves the indicators to below the button
• only shows the indicators after the first Escape key press
• increases the border thickness of the indicators and adds a background colour

On narrow screens, the indicators appear on top of the content. This does risk that they might be obscured on mobiles, but it is also less likely that the Escape key functionality will be used on mobile resolutions in the first place.

I've added pointer-events: none so that the presence of the indicators—visible or not—doesn't interfere with user interactions, though this is notably not supported in IE 10 and below. However, we don't really expect users of old IE versions to be using services in mobile resolutions.

[dav-idc]

On narrow screens, the indicators appear on top of the content. This does risk that they might be obscured on mobiles, but it is also less likely that the Escape key functionality will be used on mobile resolutions in the first place.

Would it be reasonable to put a white background behind the indicator area? At least that way it isn't clashing with text, and would just look like an extension of 'the button' on mobile screens and on weirdly failed dark-mode desktop browsers. Black dots on black text isn't high enough contrast 😛

[Ciandelle]

Plus 1 to David's latest comment about the white space. Although we might not be expecting users to make use of the escape key on smaller mobile devices, it could still be used. I'm thinking of devices such as portable gaming devices etc where someone can potentially use them without worrying about an abusive person monitoring them.

[owenatgov]

It's worth noting that it's possible to plug a portable keyboard into a small screen device. Will users do that? Unlikely but it's a base covering exercise.

Also, If we put a white background underneath the button then I'd like to recommend we add some sort of visual divider between the button icon area and the content on the page. Off the top of my head, a border around the icons so that it's almost an extension of the button itself. My thinking here is content on a white background appearing to "disappear" behind this overlay section which otherwise blends into the white background might be confusing to users.

[querkmachine]

Mm, I did initally put a white background behind the indicators, but as the code currently only shows and hides the indicators (not the entire indicator container), it meant there was always a white area appearing on top of the content instead.

I guess the options are either to:

• Amend the code to show and hide the indicator container, rather than the individual indicators.
• Add a border to the container to visually delineate it from the page's content.
• Both!

[querkmachine]

Updated to do both!

[owenatgov]

Adding a comment on record that I dig the current implementation!

[christopherthomasdesign]

I think the general approach is looking good, just a comment on styling!

My slight beef with this visually is that there are a lot of different visual elements going on at the same time – thick black circles, a dark red line, a thin grey border etc. Could be a bit more cohesive visually.

My first go at addressing this was to just make everything chunkier, so the border protruding from the button matches the thickness and darkness of the other lines:

Then I thought why don't we just make it red and white so the button (visually at least) just sort of extends when you activate it:

I have a strong preference for that last one. Would need to play with the spacing a bit but looks a lot neater to my eyes. Especially in the context of a page. Any thoughts?

[christopherthomasdesign]

I have another comment about this feature more generally, which I'm gonna put here because I don't know where else to put it. It's to do with the 'interruption page' we're exploring which introduces the EtP button and explains what it does.

This escape key functionality needs JS to work right? And we're treating it as an enhancement, so if a user doesn't have JS, the functionality be available. How does that work for content on the interruption page? Would that need to only show content about the escape key functionality if the user has JS? Feels tricky. Hopefully this isn't a real problem and I've missed something obvious.

[owenatgov]

@christopherthomasdesign Cheers for the input.

Firstly, the redesign: Done! I'm a little wary of this. This was trickier than I though as the design is essentially putting the indicator inside the button as before it was a sibling to the button. In this case it's ok because the button is an a tag dressed up to look like a button and not semantically a button, however the HTML spec specifies that you shouldn't put anything other than text inside button elements. I'm wondering about the precedent this could set in future designs if we decide that extending the button is something we want to do and will involve some thinking on the dev's parts on how we expose the button styling to elements that semantically aren't buttons.

Secondly, the thoughts on the interrupt page content: Personally, I'm leaning towards not explaining this. I think it's getting too detailed to explain the specifics of a visual enhancement and think just telling folks broadly that the button is there, what it's for, how to use it and what'll happen if you use it are enough. Take that with a big pinch of salt of course, I ain't no content person.

[Ciandelle]

Having looked at this, I really like the third design as well, though I do understand @owenatgov's comments. I think this is something we need to keep in mind when we are doing future designs. I also agree that we shouldn't over explain the interruption page (side question - do we have a specific github issue for this?)

[owenatgov]

I didn't get around to merging this so I'll give that honour to @querkmachine. I have some final thoughts:

Re: the button styling stuff, I think considering it's a link and it's right now just for this component that this is fine. It's unlikely from glancing at the backlog that we'll ever want to "extend" the button in the same way. This is a special case and in isolation it's not causing problems.

[owenatgov]

This is ready to go and looking great!