SPIKE: Can The Exit this Page button stick to the bottom of the page on small screens

[owenatgov]

What

Investigate if it's possible to position the Exit this Page button as a sticky element at the bottom of the page on smaller screens.

Part of #1755

Time limit: 1 week

Why

Following our user research on Exit this Page, there is a split opinion on if the button should go at the top or the bottom of the page on smaller screens.

Pros

• The button will be easier to press for mobile device users who are more likely to hold their phones in such a way that elements at the bottom of the screen are easier to reach for
• Being at the bottom of the screen makes it less conspicuous

Cons

• The button may interfere with elements at the bottom of the screen/emerging elements as the user scrolls
• The user is more likely to press the button by mistake
• A button at the bottom may be harder to implement

The above are in part conjecture based on expertise so we want to at least do some desk research to verify these.

We previously investigate this but decided that it was premature to investigate before user research. We tracked this in #2117 which contains some useful information.

Who needs to work on this

Developers, Designers

Done when

• Attempt to implement a button at the bottom of small screens to see if it's possible
• Implement in the child maintenance prototype (https://github.com/Ciandelle/hidethispageprototype) to test

[querkmachine]

Implementation

Simply changing the component's CSS to use bottom: 0 instead of top: 0 does the trick for changing the position. No other code changes required.

The good

Having it at the bottom actually interferes less with the 'default' surrounding page than at the top—as it now only covers an already empty area of the footer when scrolled to the end of the page, rather than immediately covering parts of the GOV.UK header and branding.

Collapsing mobile browser UIs didn't appear to interfere with it in any recent version of Safari/iOS (tested back to iOS 10) or Chrome/Android (tested back to Android 9). The button simply moved to meet the new 'bottom' of the viewport whenever it shifted. WITH SOME EXCEPTIONS.

I don't believe that the button being at the very bottom of the screen is likely to produce a significant number of accidental activations. It is easier to press (from the perspective of someone holding a phone and using their thumbs as the interaction method) but it still requires some effort to reach below the 'resting thumb area' and activate the button.

The bad

In Safari/iOS (tested back to iOS 10), the button becomes obscured when the virtual keyboard is opened. This is because the keyboard is overlaid on the viewport and the viewport is not actually resized (kinda). It is still possible for the user to scroll the button back into view by scrolling down, and they do not need to scroll the entire length of the document to so, however scrolling up will again obscure the button behind the keyboard. This was not an issue in any Chrome/Android combos I tested.

Accidental activations are still easier than if the button was at the top.

The ugly

Although the button now covers an empty part of the footer, it is still overlapping the footer, and visually appears very close to the copyright link. Ideally we'd probably want more space here.

[owenatgov]

Thanks @querkmachine for this very thorough investigation. My thoughts on this are that the keyboard covering the button creates too much disruption for this to be worthwhile. Additionally re: the footer, we'd be relying on that space never changing creating a dependancy for this component. I vote keeping it at the top after all.

[querkmachine]

There is still, in my mind, a fairly significant problem with it being at the top of the page, however—it covers the page header and any navigation controls within it.

As noted elsewhere, we're likely to be adding a skiplink version of the button to the top of the page anyway. I'm wondering if this could do double-duty as a skiplink on desktop and as the sticky button on mobile? I'm not sure how practical that would be given the different visual treatments and viewport-conditional functionality, though.

[owenatgov]

This is probably the best idea. A couple of thoughts on this:

• I mentioned in [Spike] Add visual escape key indicators to exit this page button govuk-frontend#2940 (comment) that we could treat the hidden button like a separate entity that was part of EtP's js ecosystem. I don't think that's gonna fly now as any users on a small screen but with a keyboard plugged in needs access to that esc key functionality. We'll therefore need to think about treating the 3xEsc like a singleton.
• Since we're going to be styling this like a skip link on desktop and a button on mobile, we need to think about how we do this efficiently. It's going to be messy to pick one and then try to restyle it like the other and risky to ask service teams to implement special versions of both. The lesser evil in my mind is to add an attribute to the macro eg: isHidden and add some skip link shaped styling to that top one.
• I'm concerned about the risk that a user has implemented the "main" EtP button but not the hidden one. We can't include it in the macro call since it's going to be far away. We will be releasing the EtP pattern so the risk is lessened somewhat. I do still wonder if we need to think about a fallback. This is very hacky, but maybe the desktop EtP retains it's position: fixed but we set its z-index lower than the mobile EtP so that the mobile EtP will always float on top of it if it's present? If the mobile EtP is using position: sticky it should create space above the header for the button so the desktop one can neatly behind it. Another hacky idea is for the skip link to create some padding above the header on mobile for the desktop button to sit in on mobile.

[querkmachine]

It's been, rather coincidentally, announced today that the next version of Chrome on Android will change their default viewport sizing behaviour when the keyboard is visible to match Safari on iOS. https://developer.chrome.com/blog/viewport-resize-behavior/

There will be a meta tag switch to use the current behaviour, but this still wouldn't resolve the problem on Safari, so this is an extra push to not place the button along the bottom of the vewport.

[querkmachine]

Closing this for now. The lack of visibility of the button when it's positioned at the bottom of the screen, and the virtual keyboard is open, is too problematic for us to consider this viable going forwards.

The discussion on whether to use the skiplink variant as the sticky button on mobile will continue elsewhere.