Navigation - Sticky Nav

[jinky32]

Franklin want to implement a sticky nav on device support pages as per the attached design. Currently they are looking at testing this in Maxymiser but we should be aware wrt future Digital Library implementation.

There is an existing sticky nav implemented on http://www.three.co.uk/Discover/Why_choose_three but it is felt that this isn't particularly on brand and doesn't meet their requirements.

The blue bar in the attached is sticky and will also display the name and mini-icon of the device only once you scroll down past the main heading, so you know what device you’re looking at. The links to the right would appear to be anchors to the content sections below.

@ThreeUK/dac - could you please provide some accessibility advice/requirements on this pattern?

@LucPestille @papafed - I'm not requesting significant work here but guidance on this would be appreciated, for example: @LucPestille - do you know who worked on this from Design? Is it a reusable pattern that we would specify for future similar requirements? For example how would this work on http://www.three.co.uk/Discover/Why_choose_three where there are ten anchors?

@papafed - The example at http://www.three.co.uk/Discover/Why_choose_three doesn't use nav, would your advice be that it should (if it were being done again)? It appears to me that there could be a good amount of reusable code from the header - do you agree?

[GavinAEvans]

Off the top of my head the one thing to look out for with regard to sticky navs is an issue for keyboard users.

When you tab down through the page - no problem. When you tab back up the page, content which has keyboard focus scrolls to the top of the screen and becomes hidden by the sticky nav bar - this happens on the example page http://www.three.co.uk/Discover/Why_choose_three. Tab down to the bottom, then tab back and things like "log in to your account." become obscured.

[LucPestille-Three]

Sticky nav has been used elsewhere (or intended to be used), and I've seen it in various configurations;

• Normally just a centered collection of links (6 max, split evenly across the 12 col grid)
• A title on the left and a link/icon to dropdown and uncover a list of links
• The new variant as above, which is a title and N links on the right.

Andy A'Court designed that page above.

Previously when implementing sticky navs, I've used an offset so that it doesn't cover what anchor link you're scrolling to, but I'm not sure how that might work with keyboard navigation.

[papafed]

Technically it's easy enough to do, but it requires JS to implement. Not a big problem. The accessibility of the thing is tricky because as Gavin says it obscures other content. Shame we have no alpha-transparency in the colour pallette to reveal content underneath (hint!)

It might not be the easiest thing to tab onto itself either. But that has to be balanced against the potential usability benefits for visual users - sticky menus are something like 20% more efficient than fixed ones.

As far as markup goes, yes I'd do it with a nav.

[beasers]

Thanks gents! Yes the keyboard input is the tricky part in terms of tabbing. I checked the Why Choose Three page and reverse tabbing isn't the nicest but I get the feeling it might not be easy to solve.

I am still writing the brief for this (and will of course incorporate your input) but in case useful this is where I have got to. Note that we will not be going sticky on the mobile (smallest) break, the nav bar will show but scroll up in its fixed position same as other page elements.

cheers Justin

Beneath the main introduction section sits a horizontal navigation bar, see Figure 4. This is a new element that will be referred to the Digital Library via Github and reviewed for accessibility and inclusion as a standard pattern. For this first iteration please follow the requirements below as normal. Note - The subnavigation bar (“subnav”) behaves quite differently at the mobile break, see 3.6 below. 3.5.1. The subnav should be full screen width with a blue (.Maggie) background 3.5.2. The three text anchors should be presented as shown in the figures below for the non-mobile breaks; in white text with links underlined. 3.5.3. The anchors should link to their respectively named sections below, with a smooth scroll as used on the new “Welcome to Three” pages. 3.5.4. A white bar should be used to represent both the hover and clicked/active state of each anchor. An anchor may become active either: 3.5.4.1. when clicked (thereby initiating a scroll down to its bookmarked section), or 3.5.4.2. when the user scrolls by any means to the area of the page designated by the anchor. For example, if a user scrolls to the Videos section, the Videos anchor should become active. The precise point at which the anchor becomes active in this case should be when the top of its designated page area is at the vertical midpoint of the viewable browser window or higher. This should hold true for all page anchors including the first (Explore). 3.5.5. If possible please apply a short fade in/out transition to the white bar. 3.5.6. The subnavigation bar should be “sticky”; it should be relatively positioned while scrolling down until its first vertical pixel is about to scroll past the top of the viewable browser window, at which point it should be frozen to the top of the browser window with all other content scrolling underneath it. Please avoid “jumpy” pixels here at the top of the frame. 3.5.7. The subnavigation bar should behave oppositely when the page is scrolled up, and revert to its natural position (“unfreeze”) at the point where it occupies its original relative position in the page. This is the convention for other sticky navigation implementations around the web. 3.5.8. The figures below show two UI elements on the left of the bar: a bespoke device image “icon” alongside the device name, wrapped to two lines and centre aligned vertically to the icon. The elements should be hidden by default and displayed only at the point the subnav bar “freezes”. 3.5.9. Please render the device name as a Heading2/H2. 3.5.10. If possible, please leverage CSS3 to create the image icon (not sure if this is practical but the intention is to avoid unnecessary image assets). 3.5.11. The device icon and name - along with the active indicator beneath the anchor links - should disappear when the subnav bar unfreezes. Please apply a fade in/out transition to these elements. 3.5.12. All three links must be keyboard-accessible in the usual way (via the tab key). This may mean setting a tabindex of 0 on the elements, please investigate. Ideally the tab order should be overridden so that when "reverse tabbing" back up the page, the subnav links are ordered after the last visible element on the page, rather than in their original order. This will require additional investigation and may not be best practice.

[beasers]

Another note - we are probably going to Maxy this first and track the use of the nav links. Or may put them through Omniture, but either way I am not proposing that this kind of navigation becomes widespread unless we find customers use it. I'd also like to put it in front of real customers and get some insight although Ara doesn't reckon we'll learn much from a small handful of lab users.

[GavinAEvans]

We had a bit of feedback from Webaim too:

make the appearance and disappearance of a menu accessible to users of screen readers?

It seems like sticky menus present a few issues.

1. Discoverability: The user must be able to discover the menu even without scrolling the screen. This could be solved by placing it in the DOM in a strategic location where it might first appear.
2. Access: While the menu is always easily available to users who can see or can use the mouse -- if it only appears at the top of the DOM it is likely more difficult to access for users of screen readers and users of speech recognition. Dragon seems to not put its number markers on fixed positioned items unless the fixed location coordinates are within the initial screen's height. Some options might be access or shortcut keys to focus the menu.
3. Role, name, state: There isn't exactly a good role for such a structure. Any state information such as a visual indication of what page region you are on may not be helpful to users of screen readers because once you move to the sticky menu the region has scrolled and the location is not what it just was. I.e. there is no good way to find out where you are by looking at the menu -- but you tell where you are if the regions are correctly marked with ARIA. The names can easily be indicated and aria-describedby can be used to map to the region headings. Aria-controls or something else can also be used to show the relationship between the menu items and region. 4 ARIA: It would be important to mark the regions with ARIA landmarks and ARIA labels or perhaps HTML5 sections as well as headings to help screen reader users understand the different regions of the page and their relationship.

[beasers]

Thanks Gavin. Re point (1) above, the menu will appear on first load as part of the page above the fold (for most screens). It just sticks in place once the user has scrolled so hopefully that should be ok. I'll look into the ARIA recommendations, thanks again