design-system

design-system copied to clipboard

:pushpin: Summary

This PR introduces a feature to the website that affords users a button that can be clicked to return to the top of the current page.

:hammer_and_wrench: Detailed description

Implementation choices:

• Only appears after user has scrolled some (configurable) distance down the page
• Appears on any page using the <Doc::Page::Content> component, which is pretty much every page except the homepage

:camera_flash: Screenshots

:link: External links

Jira ticket: HDS-3298 Figma file

---

:speech_balloon: Please consider using conventional comments when reviewing this PR.

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
hds-showcase	✅ Ready (Inspect)	Visit Preview	May 20, 2024 8:00pm
hds-website	✅ Ready (Inspect)	Visit Preview	May 20, 2024 8:00pm

@heatherlarsen the CSS linter seems unhappy after the last commit, but you can fix it by running yarn lint:css:fix in website

The approach to always have the button in the DOM with opacity 0 has usability flaws when the button overlaps another interactive element, such as a link on the page (see the example below where it partly overlaps with a doc card image). When the user clicks the area highlighted in red nothing will happen – as you can imagine the problem becomes more acute on narrow screens.

You're right, I didn't think of this case. Do you reckon that adding a pointer-events: none; by default, and removing this style on doc-scroll-to-top--is-visible would be enough?

The approach to always have the button in the DOM with opacity 0 has usability flaws when the button overlaps another interactive element, such as a link on the page (see the example below where it partly overlaps with a doc card image). When the user clicks the area highlighted in red nothing will happen – as you can imagine the problem becomes more acute on narrow screens.

You're right, I didn't think of this case. Do you reckon that adding a pointer-events: none; by default, and removing this style on doc-scroll-to-top--is-visible would be enough?

I've not tested pointer-events, it may allow the click to go through the button and reach the underneath target, but the issue I see with the button being in the DOM when not visible (in contrast with the original implementation) is that when navigating using keyboard and reaching that element the focus is lost (as in, it's on the button, but not visible, hence visually lost), violating WCAG criterion 2.4.7.

I've not tested pointer-events, it may allow the click to go through the button and reach the underneath target, but the issue I see with the button being in the DOM when not visible (in contrast with the original implementation) is that when navigating using keyboard and reaching that element the focus is lost (as in, it's on the button, but not visible, hence visually lost), violating WCAG criterion 2.4.7.

@alex-ju see my last commit: does this address all the issues?

I've not tested pointer-events, it may allow the click to go through the button and reach the underneath target, but the issue I see with the button being in the DOM when not visible (in contrast with the original implementation) is that when navigating using keyboard and reaching that element the focus is lost (as in, it's on the button, but not visible, hence visually lost), violating WCAG criterion 2.4.7.

@alex-ju see my last commit: does this address all the issues?

yes, this looks conformant! 👌