Tags: navigation



Sunday, January 28th, 2018

A Tale of Two Rooms: Understanding screen reader navigation | The Paciello Group

A nice analogy to help explain what it’s like to navigate with a screen reader—and how much well-structured markup can help make it easier.

Friday, January 5th, 2018

Improving the Accessibility of 24 ways | CSS-Tricks

Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.

Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.

Thursday, October 5th, 2017

Creating accessible menus-Part 1

James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.

Monday, September 25th, 2017


I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.

Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.

Friday, September 1st, 2017

Progressively Worse Apps

This article makes a good point about client-rendered pages:

Asynchronously loaded page elements shift click targets, resulting in a usability nightmare.

…but this has nothing, absolutely nothing to do with progressive web apps.

More fuel for the fire of evidence that far too many people think that progressive web apps and single page apps are one and the same.

Sunday, July 2nd, 2017

Sticky headers

A three-part series by Remy looking at one interface pattern (a sticky header) and how his code evolved and changed:

  1. Sticky headers
  2. Smooth scroll & sticky navigation
  3. CSS sticky nav & smooth scroll

Sunday, January 15th, 2017

Using the aria-current attribute – Tink

The aria-current attribute is very handy and easy to implement. Léonie explains it really well here.

Monday, September 12th, 2016

CSS Mega Dropdown | CodyHouse

I’m no fan of mega menus, and if a site were being designed from scratch, I’d do everything I could to avoid them, but on some existing projects they’re an unavoidable necessity (the design equivalent of technical debt). In those situations, this looks like a really nice, responsive approach.

Sunday, August 7th, 2016

The Future of Browser History — Free Code Camp

I’ve been thinking about this a lot lately. It feels like a user’s browser history is an incredibly rich seam of valuable information just waiting to be presented in a more interesting way.

Wednesday, June 29th, 2016

Completely CSS: Progressively Collapsing Navigation | Kenan Yusuf

One way of implementing the growing/shrinking navigation pattern—an alternative to just shoving everything behind a hamburger icon.

Sunday, June 26th, 2016

Sticky headers

I made a little tweak to The Session today. The navigation bar across the top is “sticky” now—it doesn’t scroll with the rest of the content.

I made sure that the stickiness only kicks in if the screen is both wide and tall enough to warrant it. Vertical media queries are your friend!

But it’s not enough to just put some position: fixed CSS inside a media query. There are some knock-on effects that I needed to mitigate.

I use the space bar to paginate through long pages. It drives me nuts when sites with sticky headers don’t accommodate this. I made use of Tim Murtaugh’s sticky pagination fixer. It makes sure that page-jumping with the keyboard (using the space bar or page down) still works. I remember when I linked to this script two years ago, thinking “I bet this will come in handy one day.” Past me was right!

The other “gotcha!” with having a sticky header is making sure that in-page anchors still work. Nicolas Gallagher covers the options for this in a post called Jump links and viewport positioning. Here’s the CSS I ended up using:

:target:before {
    content: '';
    display: block;
    height: 3em;
    margin: -3em 0 0;

I also needed to check any of my existing JavaScript to see if I was using scrollTo anywhere, and adjust the calculations to account for the newly-sticky header.

Anyway, just a few things to consider if you’re going to make a navigational element “sticky”:

  1. Use min-height in your media query,
  2. Take care of keyboard-initiated page scrolling,
  3. Adjust the positioning of in-page links.

Tuesday, May 31st, 2016

turbolinks/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

During rendering, Turbolinks replaces the current body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, persist from one rendering to the next.

Here’s the mustard it’s cutting:

It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.

This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.

Thursday, April 7th, 2016

A couple of alternatives to the hamburger menu | Kenan Yusuf

Two (similar) patterns for responsive navigation that don’t involve sweeping everything behind a hamburger icon.

When I’ve experimented with auto-overflowing horizontal patterns like this, I’ve found that a judiciously-placed box shadow can give a nice affordance.

Friday, December 18th, 2015

Temporary Constellations — Buckley Williams

This is a really lovely project by Dan and Nat—Christmas cards featuring the fleeting invisible constellations formed by the mesh of GPS satellites within which our planet lies.

Monday, October 12th, 2015

Histography - Timeline of History

A nice navigable timeline of historical events from Wikipedia.

Thursday, August 20th, 2015

The Hamburger Menu Doesn’t Work - Deep Design

Building on Luke’s research, James outlines the problems with hiding navigation behind a hamburger icon. So, to be clear, the problem isn’t with the icon, so much as the way it is used as a cupboard to shovel all our messy navigation issues into.

Tuesday, January 27th, 2015

Thoughts on Pagination

I’ve been thinking about this a lot lately; alternate ways of paginating through the past e.g. by day instead of by arbitrary amount.

Tuesday, December 9th, 2014

Responsive Enhancement

This article first appeared in 24 Ways, the online advent calendar for geeks.

24 Ways has been going strong for ten years. That’s an aeon in internet timescales. Just think of all the changes we’ve seen in that time: the rise of Ajax, the explosion of mobile devices, the unrecognisably-changed landscape of front-end tooling.

Tools and technologies come and go, but one thing has remained constant for me over the past decade: progressive enhancement.

Progressive enhancement isn’t a technology. It’s more like a way of thinking. Instead of thinking about the specifics of how a finished website might look, progressive enhancement encourages you to think about the fundamental meaning of what the website is providing. So instead of thinking of a website in terms of its ideal state in a modern browser on a nice widescreen device, progressive enhancement allows you to think about the core functionality in a more abstract way.

Once you’ve figured out what the core functionality is—adding an item to a shopping cart, or posting a message, or sharing a photo—then you can enable that functionality in the simplest possible way. That usually means starting with good old-fashioned HTML. Links and forms are often all you need. Then, once you’ve got the core functionality working in a basic way, you can start to enhance to make a progressively better experience for more modern browsers.

The advantage of working this way isn’t just that your site will work in older browsers (albeit in a rudimentary way). It also ensures that if anything goes wrong in a modern browser, that it won’t be catastrophic.

There’s a common misconception that progressive enhancement means that you’ll spend your time dealing with older browsers, but in fact the opposite is true. Putting the basic functionality into place doesn’t take very long at all. And once you’ve done that, you’re free to spend all your time experimenting with the latest and greatest browser technologies, secure in the knowledge that even if they aren’t universally supported yet, that’s okay: you’ve already got your fallback in place.

The key to thinking about web development this way is realising that there isn’t one final interface—there could be many, slightly different interfaces depending on the properties and capabilities of any particular user agent at any particular moment. And that’s okay. Websites do not need to look the same in every browser.

Once you truly accept that, it’s an immensely liberating idea. Instead of spending your time trying to make websites look the same in wildly varying browsers, you can spend your time making sure that the core functionality of what you’re building works everywhere, while providing the best possible experience for more capable browsers.

Allow me to demonstrate with a simple example: navigation.

Step One: Core Functionality

Let’s say we’ve got a straightforward website about the twelve days of Christmas, with a page for each day. The core functionality is pretty clear:

  1. To read about any particular day, and
  2. To browse from day to day.

The first use-case is easily satisfied by marking up the text with headings, paragraphs, and all the usual structural HTML elements. The second use-case is satisfied by providing a list of good ol’ hyperlinks.

Now where’s the best place to position this navigation list? Personally, I’m a big fan of the jump-to-footer pattern. This puts the content first and the navigation second. At the top of the page there’s a link with an href attribute pointing to the fragment identifier for the navigation.

  <main role="main" id="top">
    <a href="#menu" class="control">Menu</a>
  <nav role="navigation" id="menu">
    <a href="#top" class="control">Dismiss</a>

See the footer-anchor pattern in action.

Because it’s nothing more than a hyperlink, this works in just about every browser since the dawn of the web. Following hyperlinks is what web browsers were made to do (hence the name).

Step Two: Layout as an Enhancement

The footer-anchor pattern a particularly neat solution on small-screen devices, like mobile phones. Once more screen real-estate is available, I can use the magic of CSS to reposition the navigation above the content. I could use position: absolute, flexbox, or in this case, display: table.

@media all and (min-width: 35em) {
  .control {
    display: none;
  body {
    display: table;
  [role="navigation"] {
    display: table-caption;
    columns: 6 15em;

See the wide-screen styles in action

Step Three: Enhance!

Right. At this point I’m providing core functionality to everyone, and I’ve got nice responsive styles for wider screens. I could stop here, but the real advantage of progressive enhancement is that I don’t have to. From here on, I can go crazy adding all sorts of fancy enhancements for modern browsers, without having to worry about providing a fallback for older browsers—the fallback is already in place.

What I’d really like is to provide a swish off-canvas pattern for small-screen devices. Here’s my plan:

  1. Position the navigation under the main content.
  2. Listen out for the .control links being activated and intercept that action.
  3. When those links are activated, toggle a class of .active on the body.
  4. If the .active class exists, slide the content out to reveal the navigation.

Here’s the CSS for positioning the content and navigation:

@media all and (max-width: 35em) {
  [role="main"] {
    transition: all .25s;
    width: 100%;
    position: absolute;
    z-index: 2;
    top: 0;
    right: 0;
  [role="navigation"] {
    width: 75%;
    position: absolute;
    z-index: 1;
    top: 0;
    right: 0;
  .active [role="main"] {
    transform: translateX(-75%);

In my JavaScript, I’m going to listen out for any clicks on the .control links and toggle the .active class on the body accordingly:

(function (win, doc) {
  'use strict';
  var linkclass = 'control',
    activeclass = 'active',
    toggleClassName = function (element, toggleClass) {
      var reg = new RegExp('(\s|^)' + toggleClass + '(\s|$)');
      if (!element.className.match(reg)) {
        element.className += ' ' + toggleClass;
      } else {
        element.className = element.className.replace(reg, '');
    navListener = function (ev) {
      ev = ev || win.event;
      var target = ev.target || ev.srcElement;
      if (target.className.indexOf(linkclass) !== -1) {
        toggleClassName(doc.body, activeclass);
  doc.addEventListener('click', navListener, false);
}(this, this.document));

I’m all set, right? Not so fast!

Cutting the Mustard

I’ve made the assumption that addEventListener will be available in my JavaScript. That isn’t a safe assumption. That’s because JavaScript—unlike HTML or CSS—isn’t fault-tolerant. If you use an HTML element or attribute that a browser doesn’t understand, or you use a CSS selector, property or value that a browser doesn’t understand, it’s no big deal. The browser will just ignore what it doesn’t understand: it won’t throw an error, and it won’t stop parsing the file.

JavaScript is different. If you make an error in your JavaScript, or use a JavaScript method or property that a browser doesn’t recognise, that browser will throw an error, and it will stop parsing the file. That’s why it’s important to test for features before using them in JavaScript. That’s also why it isn’t safe to rely on JavaScript for core functionality.

In my case, I need to test for the existence of addEventListener:

(function (win, doc) {
  if (!win.addEventListener) {
}(this, this.document));

The good folk over at the BBC call this kind of feature-test cutting the mustard. If a browser passes the test, it cuts the mustard, and so it gets the enhancements. If a browser doesn’t cut the mustard, it doesn’t get the enhancements. And that’s fine because, remember, websites don’t need to look the same in every browser.

I want to make sure that my off-canvas styles are only going to apply to mustard-cutting browsers. I’m going to use JavaScript add a class of .cutsthemustard to the document:

(function (win, doc) {
  if (!win.addEventListener) {
  var enhanceclass = 'cutsthemustard';
  doc.documentElement.className += ' ' + enhanceclass;
}(this, this.document));

Now I can use the existence of that class name to adjust my CSS:

@media all and (max-width: 35em) {
  .cutsthemustard [role="main"] {
    transition: all .25s;
    width: 100%;
    position: absolute;
    z-index: 2;
    top: 0;
    right: 0;
  .cutsthemustard [role="navigation"] {
    width: 75%;
    position: absolute;
    z-index: 1;
    top: 0;
    right: 0;
  .cutsthemustard .active [role="main"] {
    transform: translateX(-75%);

See the enhanced mustard-cutting off-canvas navigation. Remember, this only applies to small screen screens so you might have to squish your browser window.

Enhance All The Things!

This was a relatively simple example, but it illustrates the thinking behind progressive enhancement: once you’re providing the core functionality to everyone, you’re free to go crazy with all the latest enhancements for modern browsers.

Progressive enhancement doesn’t mean you have to provide all the same functionality to everyone—quite the opposite. That’s why it’s so key to figure out early on what the core functionality is, and make sure that it can be provided with the most basic technology. But from that point on, you’re free to add many more features that aren’t mission-critical. You should be rewarding more capable browsers by giving them more of those features, such as animation in CSS, geolocation in JavaScript, and new input types in HTML.

Like I said, progressive enhancement isn’t a technology. It’s a way of thinking. Once you start thinking this way, you’ll be prepared for whatever the next ten years throws at us.

Wednesday, July 16th, 2014

Smart Fixed Navigation

Here’s an intriguing approach to offering a navigation control that adapts as the user scrolls.

I’m not too keen on the way it duplicates the navigation in the markup though. I might have a play to see if I can find a way to progressively enhance up from a link-to-footer pattern to achieve this.

Tuesday, July 15th, 2014

Navigating the Guardian | Help | The Guardian

A peek behind the scenes of an interesting new navigation pattern on the Guardian’s still-in-beta responsive site.

You can try it out here