Navigation elements remain at top of page

[NickColley]

This issue is from a May 2019 external accessibility audit report.

WCAG Reference: Usability feedback only, there is no WCAG related guidelines.
Issue ID: DAC_Issue33
URL: https://design-system.service.gov.uk/styles/layout/#page-wrappers

Screen Shot

Some users, especially those that zoomed into the page, found that once they had ‘skipped’ to an area of the page using the ‘in-page’ links, the navigation elements remained at the top of the page.

Current Code Ref(s)

<nav class="app-subnav">

Low vision user comments

“Whilst there was not an issue with identifying and locating the links list on the left side of the page, I was able to make selections from this list and find that the content on the right-side updated accurately. However, when looking to select another topic, I scanned back across to the left side of the page to find that no list was present. My expectation in this instance would have been for the links list to move down the updated page of contents. In this instance I was forced to scroll all the way back to the top of the page to access the links list.”

Solution

Some users may prefer that the navigation panel to the left of the page ‘follows’ their focus as they move down the page, to enable them to locate them again easily after making a selection and moving down the page.

[NickColley]

I wonder why the back to top link did not follow this user? 🤔 Perhaps using a browser that does not support position: sticky

[36degrees]

Because of the number of items in the left-hand navigation on some pages, making it fixed requires it to scroll independently of the content.

We previously used a layout of this type (with two scrollable panes and a fixed header) prior to #687, which removed them in response to accessibility issues from the DAC audit in June 2018.

There are two internal scrolls present on this page. This is not obvious as there is no scroll bar for the left-hand navigation or the content.

This is prevalent in Internet Explorer. As a result, a voice activation user is not going to know what they are going to need to do additional work to access all of the links in the left- hand navigation and the content. The additional work needed includes using keyboard commands to tab into that area to move the focus to that scroll.

We would recommend removing the internal scroll features and allow the page to work in sync with the sub-navigation area on the left of the page.

The previous audit provided examples of how having two internal scrolls might impact users of assistive technology, whereas this seems more like usability feedback. For that reason, I'm going to close this.