\nI’m a big believer in iteration and not treating a website as ever being finished. I hope what\u2019s been released this year can act as a foundation, and that the design will evolve in the years to come.<\/p>\n<\/blockquote>\n
In the intervening years, as tools have improved and best practices have matured, I’ve tweaked the design and refactored the code, and developed a component library<\/a> in the process.<\/p>\n
The 24 ways home page <\/figcaption><\/figure>\n A Focus on Accessibility<\/h3>\n
This year I’ve been listening to people like Laura Kalbag talk about accessibility in terms of universal design<\/a>, and followed blogs like Heydon Pickering\u2019s Inclusive Components<\/a>, which covers how to design and implement common interaction patterns with an inclusive mindset. All of a sudden, the thorny subject of accessibility has felt more approachable and less dogmatic.<\/p>\n
With all this knowledge digested, I was keen to see how 24 ways would fare when put under the microscope. In this article, I will cover five areas where I was able to make improvements:<\/p>\n
\n
- Page structure<\/li>\n
- Labelling of elements<\/li>\n
- Keyboard navigation<\/li>\n
- Aural experience<\/li>\n
- General usability<\/li>\n<\/ul>\n
Before I start, a note of thanks. After making an initial set of changes, I asked my friend and accessibility expert Francis Storr<\/a> to review my work. He uncovered a number of additional issues, partly the result of his experience in this area, but also from having tested the site with a range of different assistive tools.<\/p>\n
Rethinking Page Structure<\/h3>\n
The original design had adopted a mobile-first approach. The navigation was deprioritized and placed towards the bottom of the page. To ensure that it could be accessed from the top of the page in non-JavaScript scenarios, I added a skip to navigation<\/b> link. If JavaScript was available, this link was co-opted to reveal a navigation drawer, which would slide in from the top or right, depending on the width of the viewport. This resulted in the following page structure:<\/p>\n
<header class=\"c-banner\">\u2026<\/header>\r\n<a class=\"c-menu\" href=\"#menu\">Jump to menu<\/a>\r\n<main class=\"c-main\">\u2026<\/main>\r\n<nav class=\"c-navigation\" id=\"menu\">\r\n <div class=\"c-traverse-nav\">\u2026<\/div>\r\n <div class=\"c-navigation__drawer\"\/>\u2026<\/div>\r\n<\/nav>\r\n<footer class=\"c-contentinfo\">\u2026<\/footer><\/code><\/pre>\nIn retrospect, this was problematic in a number of ways:<\/p>\n
\n
- The menu button (
.c-menu<\/code>) was not adjacent to the element it controlled (c-navigation-drawer<\/code>). Moving focus around the page like this can be confusing, especially if it\u2019s not managed properly.<\/li>\n- All navigation on the site was grouped together, even though each set of links served a different purpose.<\/li>\n
- \n
The drawer behaviour relied on having a link behave like a button. However, the first rule of ARIA<\/a> states:<\/p>\n
\nIf you can<\/em> use a native HTML element or attribute with the semantics and behavior you require already built in<\/strong>, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so<\/strong><\/p>\n<\/blockquote>\n
Last year, I updated the JavaScript so that this link would be replaced by a
button<\/code>, yet this complexity was a hint that my original solution was sub-optimal.<\/p>\n<\/li>\n<\/ul>\nHere’s the structure I arrived at today:<\/p>\n
<header class=\"c-banner\">\r\n \u2026\r\n <a class=\"c-banner__skip\" href=\"#main\">Skip to content<\/a>\r\n<\/header>\r\n<div class=\"c-menu\">\r\n <button class=\"c-menu__button\">\u2026<\/button>\r\n <div class=\"c-menu__drawer\">\u2026<\/div>\r\n<\/div>\r\n<main class=\"c-main\" id=\"main\">\u2026<\/main>\r\n<nav class=\"c-traverse-nav\">\u2026<\/nav>\r\n<footer class=\"c-contentinfo\">\u2026<\/footer><\/code><\/pre>\nMoving the navigation towards the top of the page meant the button and drawer were now adjacent to each other. The menu button is no longer two-faced; it is and always will be a button.<\/p>\n
A downside to this approach is that the navigation can be heard every time you visit a new page. Again, we can use a skip link, but this time one that points to the content block (
#main<\/code>). Rather than hide this focusable element from certain users, it becomes visible on focus<\/a>.<\/p>\nThis structure may be less ideologically pure, but it\u2019s far more pragmatic. This became a recurring theme. Indeed, having given up any hope of the HTML5 outline algorithm ever being supported by browsers, I stopped using
h1<\/code> for section headings and followed the recommendation that heading ranks should be used to convey document structure<\/a> instead.<\/p>\nImproving Keyboard Navigation<\/h3>\n
As the most interactive component on the site, the menu was the unsurprising focus of my review. The design dictates that the navigation drawer should behave like a dialog, an interface pattern that brings with it a number of assumptions. These are described in detail in eBay’s MIND pattern<\/a>, but essentially a dialog draws focus away from other elements on the page and is modal; only elements within it can be operated while it is open.<\/p>\n
I had previously cobbled together various bits of JavaScript to handle focusing (cobbling which at various points produced the odd bug such as failing to draw focus to the first element in the dialog), but had neglected to indicate the menu\u2019s role. Having fixed these issues (adding
role='dialog'<\/code> when the menu is open), Francis pointed out that screen readers could still access links outside the dialog when it was open. In macOS VoiceOver for example, pressing CTRL<\/kbd> + OPT<\/kbd> + CMD<\/kbd> + L<\/kbd> to navigate links within the menu, would in fact announce every link on the page.<\/p>\nThe solution was to mark everything outside the dialog as “inert”. Rob Dodson describes this in more detail in his video Accessible Modal Dialogs<\/a>. Implementing this can be a little bit fiddly, but a proposal to introduce an
inert<\/code> attribute<\/a> would make this easier to manage. In the meantime, the proposal provides a polyfill so you can use this feature today.<\/p>\nI\u2019ve found that by thinking about an interface in terms of common interaction patterns, and how they should operate in order to be widely understood, has helped me avoid complexity, and write more robust code. In fact, stepping into the world of accessibility has uncovered a wealth of useful resources, with well-written JavaScript examples a plenty. Given my difficult relationship with the web\u2019s programming language, these have proven invaluable.<\/p>\n
Properly Labelling Elements<\/h3>\n
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/12\/24ways.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/12\/traverse.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/12\/continue.png?ssl=1\")