Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move #top anchor to before the skip link #2161

Merged
merged 1 commit into from
May 19, 2022
Merged

Move #top anchor to before the skip link #2161

merged 1 commit into from
May 19, 2022

Conversation

36degrees
Copy link
Contributor

@36degrees 36degrees commented Apr 28, 2022

The ‘back to top’ link takes users to the #top anchor point, which is currently before the navigation but after the ‘skip to main content’ link.

This means you can no longer skip past the navs etc (as per WCAG 2.1 2.4.1 Bypass Blocks) unless you know to press shift + tab to go backwards in the tab order.

Instead, we want the 'back to top' link to take the user to the very top of the page, so that the next tab will take them to ‘Skip to main content’ (or the cookie banner, if it’s not been dismissed).

We also considered taking the user to the start of #main, bypassing all of the navigation, but opted instead to move the #top anchor to be the very first thing because:

  1. The back to top link was introduced in Remove fixed layout, introduce back to top component #687, when we moved from the side navigation and the main content being fixed, independently scrollable panes. This change meant that the side navigation no longer remained within the viewport.

    It seems that the intent at the time was that the back to top link would bring the side navigation back into view, rather than providing a convenient way for the user to get back to the top of the main content.

  2. Linking to #main makes it harder for users who have to get back to the navigation:

    If you're using a screen reader you could jump between landmarks using hot keys, but if you're just using a keyboard you're kinda just left with the tab key. Maybe I'm missing something, but the only options I could see to get back to the nav would be:

    • use TAB to go all the way through the content and footer content until you eventually get back to the top of the page
    • use back to top to get to the top of the main, and then use SHIFT+TAB to reverse through the nav menu
    • refresh the page and use TAB
  3. We think users would expect to see the header when using the ‘Back to top’ link, especially if they were aiming for the navigation.

Closes #1561

@36degrees 36degrees requested a review from dav-idc April 28, 2022 12:56
@netlify
Copy link

netlify bot commented Apr 28, 2022

You can preview this change here:

Name Link
🔨 Latest commit a9db159
🔍 Latest deploy log https://app.netlify.com/sites/govuk-design-system-preview/deploys/627a6712e7ef7100085af94d
😎 Deploy Preview https://deploy-preview-2161--govuk-design-system-preview.netlify.app/community/design-system-working-group
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Copy link
Contributor

@dav-idc dav-idc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @36degrees, Im not sure why, but I'm now seeing that with this latest commit the focus doesn't actually move to the item with id="top".

Once you press enter on or click the 'back to top' button, if you tab, it starts into the footer, rather than going to the first tab area on the page (the cookies banner button if you haven't dismissed it)

The ‘back to top’ link takes users to the #top anchor point, which is currently before the navigation but after the ‘skip to main content’ link.

This means you can no longer skip past the navs etc (as per WCAG 2.1 2.4.1 Bypass Blocks [1]) unless you know to press shift + tab to go backwards in the tab order.

Insetead, we want the 'back to top' link to take the user to the very top of the page, so that the next tab will take them to ‘Skip to main content’ (or the cookie banner, if it’s not been dismissed).

We also considered taking the user to the start of `#main` [2], bypassing all of the navigation, but opted instead to move the `#top` anchor to be the very first thing because:

1. The back to top link was introduced in #687, when we moved from the side navigation and the main content being fixed, independently scrollable panes. This change meant that the side navigation no longer remained within the viewport.

It seems that the intent at the time was that the back to top link would bring the side navigation back into view, rather than providing a convenient way for the user to get back to the top of the main content.

2. Linking to #main makes it harder for users who have to get back to the navigation:

> If you're using a screen reader you could jump between landmarks using hot keys, but if you're just using a keyboard you're kinda just left with the tab key. Maybe I'm missing something, but the only options I could see to get back to the nav would be:
>
> - use TAB to go all the way through the content and footer content until you eventually get back to the top of the page
> - use back to top to get to the top of the main, and then use SHIFT+TAB to reverse through the nav menu
> - refresh the page and use TAB

3. We think users would expect to see the header when using the ‘Back to top’ link, especially if they were aiming for the navigation.

[1]: https://www.w3.org/TR/WCAG21/#bypass-blocks
[2]: #1561 (comment)

Closes #1561
@36degrees
Copy link
Contributor Author

Hi @36degrees, Im not sure why, but I'm now seeing that with this latest commit the focus doesn't actually move to the item with id="top".

Once you press enter on or click the 'back to top' button, if you tab, it starts into the footer, rather than going to the first tab area on the page (the cookies banner button if you haven't dismissed it)

We were using #top as hard-coded in the HTML spec to indicate the 'top of the document'. Unfortunately the way the spec is written, and the way it is currently implemented in browsers, means that keyboard focus is not moved back to the start of the document.

I've updated the PR to instead add an explicit anchor with an ID of top immediately after the <body> tag, so that it should all work as expected…

@36degrees 36degrees requested a review from dav-idc May 11, 2022 08:35
@lfdebrux lfdebrux self-requested a review May 11, 2022 09:04
Copy link
Member

@lfdebrux lfdebrux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Copy link
Contributor

@dav-idc dav-idc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a quick look at it with JAWS and NVDA on Chrome and it appears to be working now - woo!

I didn't test with all screen reader and browser combinations, but the general code change here seems to be working properly.

@36degrees 36degrees merged commit f96323a into main May 19, 2022
@36degrees 36degrees deleted the move-top-anchor branch May 19, 2022 08:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

'Back to top' link moves focus after the 'skip to main content link' but before the navigation
4 participants