Recently, I volunteered to prototype a new global navigation bar for the core Ancestry.com website. This was a huge opportunity for some drastically needed improvements, not only for the code behind the header, but more importantly, the accessibility of the navigational items. Even though we’re early on in this process of creating an accessible navigation bar in HTML, CSS, and JS, I wanted to share some of our goals and challenges and gather any additional insight others may have to offer.
True or False?
Accessibility is only relevant to projects designed for the blind.
False! So false. This is actually one of the most common misconceptions that I’ve come across with new web developers. Accessibility means ensuring that all users are able to experience your product in a way that works for them.
The main navigation bar on a website is one of the most important areas that needs to be accessible. If users can’t navigate your site, guess what – they are not going to use it! In order to cater to your users, you have to know who your users are. Our users at Ancestry.com vary greatly by age and technical skill. After digesting our user stats, we focused in on four key areas of accessibility:
- Keyboard accessible navigation – Keyboard accessible navigation is crazy helpful for people with dexterity issues. Moving and clicking a mouse on a tiny 16×16 pixel icon can prove to be very difficult. This also helps our power users that want to improve their workflow by navigating with access keys.
- Touch device capable – More and more of our users visit the site through touch enabled devices, including phones, tablets, and even desktop computers. Unbeknownst to many developers though, if you have dropdown menus that are triggered by hovering over an anchor element, many users will never be able to access those secondary menu items.
- Mobile users with smaller screens – Given that most mobile devices are touch-enabled, this is still a different group of people due to the screen resolution. A surprising amount of our users (growing daily) are now navigating on devices with screens smaller than 768 pixels wide.
- Assistive technology friendly – Users with sight disabilities rely on screen readers and other assistive technologies. We strive to keep this in mind when building pages, but honestly, our current support of assistive technologies is quite low. We’d love to improve this effort, starting with this new header.
Of course there are other reasons for updating our current header (such as code cleanup, standardizing styles, performance improvements, easier access to most visited pages, better use of screen width, and overall simplification), but I’m going to focus on how we’re trying to improve the four points above.
Before we dive into the details for each of the four areas, take a look at the two different variations:
Keyboard Accessible Navigation
If you try to navigate the current Ancestry.com header through key presses, you’ll quickly notice that you cannot access the submenus, which contain some of our most visited links. This newer version had to fix this.
Task #1 was to make sure that someone could use the “tab” key to make it through the entire list of navigation links. Initially, this wasn’t all that difficult. I only had to make sure the markup was semantic, in the correct order, and no autofocusing-elements on page load. Then, thankfully, most web browsers do a decent job taking you from one link to the next.
The challenge came when we added in the drop down menus. They are handled by a global “callout” widget that moves the contents of the callout into a new element that is a direct child of the
element. This is done to avoid any possibility of z-indexing issues that we had dealt with previously. However, in this case, it complicated the task of being able to tab to each navigational link since the DOM structure is changed when the callout opens. We got around this by adding custom keyup events detecting the arrow and bracket keys. This actually created an additional benefit of being able to more quickly focus on the link that you needed (instead of pushing tab fifteen times, you can now push it four times and then push the down arrow once). So even though our goal was to be able to tab all the way through, we feel the solution we’ve found with the arrow or bracket keys is even better.Task #2 was to make it even easier to jump to the most used pages (such as a user’s tree, Search, DNA, etc.) through the use of access keys. Web access keys are shortcut keys to certain pages or parts of a page.
The challenge with access keys is that all software programs like shortcut keys! This causes lots and lots of potential conflicts. The best recommendation for access keys that I’ve found was from the UK government, albeit over 11 years old. On a side note, here is an awesome read about access keys and keyboard accessibility article by WebAim.
Other than the letter “S” for skipping navigation, they recommend using numbers for your main links. Our main links are different than theirs, so this represents our current implementation on the new header:
- alt + s Skip navigation
- alt + 1 Home
- alt + 2 User’s tree
- alt + 3 Search
- alt + 4 DNA
- alt + 5 Resources
- alt + 6 Shop
- alt + 7 Quick Lookup
- alt + 8 Messages
- alt + 9 Hints
- alt + 0 Account
In order to make our users aware that these access keys exist, we would simply put a hidden link at the end of the page that is shown on focus. Users who navigate with the keyboard would be able to find our access key definitions page.
Touch Device Capable
If you visited our site a year ago on an Android or Windows touch device, you could not access the submenus in the main navigation bar. Those devices trigger the hover and click event at the same time, rendering submenus shown by hover as completely useless. The hover would occur, instantly followed by the click, which closed the hover dropdown, and then proceeded to the clicked link. A simplified version of the markup was like the following:
<div class="linkWithDropdown">
<a href="/a/"">Place A</a>
<ul class="dropdown">
<li><a href="/b/">Place B</a></li>
<li><a href="/c/">Place C</a></li>
<li><a href="/d/">Place D</a></li>
</ul>
</div>And the relevant CSS like so:
.dropdown { display:none; }
.linkWithDropdown:hover .dropdown { display:block; }iOS devices did not have the same issue as they required a tap to trigger the hover (which opened the menu) and another tap to trigger the click event. This behavior was actually fortunate for this current scenario but causes issue in other use cases.
Our fix for this case was to remove all CSS hover styles applied to those elements on touch-enabled devices. This made the first finger tap on all devices trigger the click event. We then stopped the event from changing the page, stored a flag marking that it was open, and then listened for the next finger tap. On the second finger tap, it would then fire the click event again and allow you to go to that page. Basically, we disabled the iOS device tap behavior, made it consistent with Android, then added custom code to mimic the disable iOS behavior, but in a cross-device-compatible-sort-of-way.
Mobile Users with Smaller Screens
Ancestry.com was first built as a desktop experience, assuming a browser with a screen width of 1024 pixels. This was true for the large majority of our users 10 years ago, but is far from accurate today as more and more people are visiting our site from mobile devices. These smaller devices, such as the iPhone, are capable of rendering a desktop experience on their tiny little screen, but result in a far from optimal experience. Enter responsive web design (RWD).
The main goal of RWD is to display the same information to a user, no matter what device they’re on, in the easiest to use format possible. When it comes to navigation, it’s a poor experience to try and click on a tiny, zoomed-out, 10×8 pixel link to get to a page. In my opinion, (formed from many others’ research) links on touch devices should never be smaller than 44×44 pixels. This makes clickable areas much easier to tap. RWD has now been a hot priority at Ancestry.com for well over a year now. We’ve made huge leaps forward, and this new header is no exception. It is fully responsive, meaning it has a fluid layout and adapts its visual layout according to the screen width that is available to it.
Assistive Technology Friendly
This category covers those who use screen readers, screen magnifiers, and other assistive software. Even though this is currently a miniscule amount of our users, I see it as a high priority item. I come from an educational background, where the fact that all people deserve an equal right to learn was engrained into me. The desire to meet this goal has transitioned nicely to the frontend web development role that I’m now in to help all people access the content that a website delivers.
Semantic HTML5 markup is now used to assist in proper categorization of DOM elements. The new header uses the <nav> element as its outer wrapper, <a> elements only when changing a URL, and <button> elements for performing javascript actions. Here is the basic markup of the new header:
<nav class="nav" id="nav">
<a accesskey="2" href="/tree/boyer/">Boyer Family Tree</a>
<ul class="navSubMenu" id="navTrees">
<li><a href="/tree/boyer/">Boyer Family Tree</a></li>
<li><a href="/tree/nielson/">Nielson REAL Family Tree</a></li>
<li><a href="/tree/start/">Start a tree</a></li>
</ul>
<a accesskey="3" href="/search/" id="navSearchTrigger">Search</a>
<ul class="navSubMenu" id="navSearch">
<li><a href="/search/">Search All Records</a></li>
<li><a href="/search/census/">Census & Voter Lists</a></li>
<li><a href="/search/birth/">Birth, Marriage & Death</a></li>
</ul>
</nav>Top-level links are direct children of the <nav> element. Submenus are visually hidden by default, but still available to be read by screen readers. Many callout and tab plugins hide content with CSS via the display property. This can be bad for accessibility as there may not be a way for people using screen readers to find that hidden information. That’s why, rather than setting the display property on those submenu <ul> elements, we use the following CSS:
.navSubMenu,
.screenReaderText { height:1px; line-height:2em; margin:-1px; opacity:0; overflow:hidden; pointer-events:none; position:absolute; width:1px; }Another best practice is to provide users a way to skip the navigation. This is done by placing this HTML as the first item in the <nav> element:
Skip Ancestry.com navigation
Our header is included in a lot of different locations, following several different page layout patterns. We cannot assume that our main content is wrapped by an element with the ID of “skipped-nav,” so we add one directly after the main <nav> element. It’d be better to just wrap your main content with a unique ID, but that wasn’t a plausible solution for us. Relevant HTML:
<div id="skipped-nav"></div>Keep in mind that there are some issues with “skip to content” links in Chrome and Internet Explorer, causing it to fail to focus on the “skipped-nav” element after the navigation. There is a JS workaround for this issue shown in the demo (go here and search for the function “fixSkipLink”).
We have learned a lot during this effort and feel we are getting closer to releasing this responsive, accessible, awesome, new global navigation bar, but we are still very much open for feedback. Since we built it as a Google Chrome plugin – you can try it yourself. If you’re not in Chrome, open it. If you’re in IE, I’m sorry.
Become a power-user and try only using your keyboard to navigate. I think alt+7 will be a favorite shortcut for a lot of users. Please keep in mind that the plugin is a prototype, so there are some bugs in it. Once you’ve played with it for a while, please complete this super short survey to let us know what you think. Since we’re involving users and others early on in the process, we are still very open to suggestions.