Access All Areas: Keyboard Accessibility from Design to QA

By now, you should have a good grasp of the term, but let’s quickly revisit what we mean by keyboard accessibility. Essentially, it’s the ability for users to navigate and interact with a website using just their keyboard without the need for a mouse. Ensuring a site meets the standards for keyboard accessibility involves several considerations. We’ll explore these from the perspectives of the various teams involved.

Design

Visual design plays a significant role in ensuring keyboard accessibility by providing clear and intuitive visual cues to the user. Logical navigation order, predictable layouts, proper focus management, and distinguishable interactive elements are all aspects where visual design meets accessibility. Our designer, Emma, is responsible for seamlessly integrating these key aspects into every design. She’s got some useful insights to share.

Logical Navigation Order

We typically read left-to-right, top-to-bottom – the direction that the majority of the world’s modern languages are written in. This natural habit influences what we perceive as a logical flow, shaping our sense of priority when interacting with digital content. Users often infer importance from the content’s position, with the highest priority given to what’s placed toward the top left of a page. Designing with this in mind leverages habitual behaviours, making the user experience more intuitive.

Consistency is also key. Placing design components in the same spot across multiple pages helps users build a mental model, reducing cognitive load and enhancing usability – vital for accessibility. A common example is having navigation at the top of the page, ensuring users can quickly and easily move around the site. This predictable placement makes the user experience smoother and more intuitive.

Interactive Elements & Focus Management

Ensuring that focusable components like links and buttons have unique visual styles is crucial for accessible design. Visual cues, including outline variations or colour shifts when an element is active, assist users in recognising their current location on the page, especially if they are keyboard users.
In a recent project, focus management was particularly important due the varying nature of the content and high amount of CTAs. We used clear, contrasting colours to draw the users attention to the CTAs, and distinct outline styles to highlight when CTAs and form fields were active as users navigated through the site. This ensured that visually impaired users or those using keyboard navigation could interact with the form effortlessly.

Modals & Popups

In much of our design work, we use modals to break up content into more digestible chunks. One design challenge is to clearly indicate that the user is interacting with content layered on top of the main page, not being taken away from it. To achieve this, we can use techniques like semi-transparent fills to push the main content to the background, creating a visual distinction between the modal and the underlying page.

To help users anticipate this behaviour we use clearly labelled button triggers supported by clear and consistent close buttons, typically in the top-right corner to reassure users that they can easily return to the main content.

Navigation

Poor navigation is one of the main reasons visitors will abandon a site. We’ve all experienced the frustration of using a poorly designed navigation system. Designing clear and consistent menus is crucial for both usability and accessibility. When dealing with complex navigation structures, it’s vital to ensure users can easily find and access all areas of the site.

In our projects, especially those with complex website structures, we kick off by creating a sitemap. This helps us identify key pages and determine the overall site structure, which in turn shapes the navigation. Keeping things as simple as possible is the key takeaway here.

Incorporating common navigation features like sub-menus and drop-downs can greatly enhance user experience, allowing users, especially those using keyboards, to skip past sections they aren’t interested in. However, it’s essential that these features are easy to recognise and that they logically group related content.

Development

Ensuring a website delivers on keyboard accessibility requires various technical implementations. The developer must approach the build in a way that enhances the accessibility considerations already addressed in the design phase. Our developer, Colette, is dedicated to creating inclusive web apps that meet the needs of everyone. Here are some handy tips from real-world accessibility implementations.

Logical Navigation Order

Ensuring users can tab around your page in a logical order starts with getting the structure right. Good old semantic HTML and ARIA attributes will get you pretty far. That’s why it’s important to use descriptive tags to convey meaning. Sometimes, though, you might need to manage the tab order programmatically.

In one project, I used Three.js to create a 3D space with various interactive objects. Since these objects were created with JavaScript, they didn’t exist in the DOM, making it tricky to handle the tab order naturally. I had to set up a keydown event to listen for a tab press and programmatically move focus to the active element which triggered a transition giving the user visual feedback on which object was active.

This might be an unusual case, but it shows that sometimes programmatic intervention is necessary to ensure your application is accessible.

Interactive Elements & Focus Management

Ensuring interactive elements have a distinguishable style and provide visual feedback when interacted with is a shared responsibility between designer and developer. Being very closely linked to logical navigation order, once again, semantic HTML is your friend. Using the designated tags for buttons and form elements, etc. along with CSS pseudo-classes like focus-visible and focus-within will take you most of the way.

A simple example of consciously managing interactive elements is a small filter I built for a virtual hospital site. Each ‘room’ contained various categorised hotspots, but only the ones in the active category were visible. Radio inputs are the perfect solution for filtering. In my case, though, the input was hidden so I had to be extra diligent to use all the correct tags and attributes for it to function correctly. I also had to update the tabindex on all the hotspots to either 0 or -1 depending on whether it was visible or not. It was a bit of a juggling act but it works seamlessly for keyboard users.

Modals & Popups

Modals can be great for displaying important information without pulling users away from the main content. However, they can be tricky for keyboard users if not handled right. There is a lot to manage – making sure focus moves to the modal when it opens, keeping focus trapped within it while it’s active, and returning focus to the previously active element when it closes. Just that alone deserves a dedicated blog.

Almost every project I’ve worked on as a developer has involved some sort of modal, and I’ll admit, I haven’t always nailed the keyboard-specific functionality. I’ve been guilty of overlooking things like focus trapping, allowing the modal to close with the escape key, and using the correct ARIA attributes. But it’s never too late to get it right. The best advice I’ve got is to try using your site with just a keyboard.

Navigation

Navigation is a fundamental part of any website, so it’s really important to get it right. On smaller websites with simple navigation, there’s not a lot to it. Make sure you’re wrapping your links in semantic nav tags and perhaps provide a keyboard-tabbable link to let users skip straight to the main content, and hey presto. Navigation is a broad category though and I’ve worked on many a mega menu that required proper keyboard consideration.

One example was a site with a full-page burger menu organised into tabs. That’s a lot to think about, so my advice for a task like this is to break it down into more manageable chunks. First, I focused on just creating a burger menu button with the correct ARIA attributes to control a hidden nav element. A full-page nav has all the same keyboard requirements as a modal because, well, it is just a modal by another name. I worked through the requirements step by step, adding pieces and testing along the way until eventually, everything was in place and keyboard navigable.

QA

The final piece of the puzzle before we send anything off to a client for review is our internal QA (Quality Assurance) phase. This step is crucial for ensuring that everything we deliver meets accessibility guidelines, keeping us honest and accountable. Our QA Engineer, Jordan, gives us the lowdown on testing for keyboard accessibility.

Testing Keyboard Accessibility

Ensuring keyboard accessibility is in compliance with WCAG 2.2 standards is critical for creating inclusive web experiences. One of the primary steps in QA is to verify that all interactive elements on a webpage, such as links, buttons, form fields and menus, are accessible via the keyboard. This means ensuring that these elements can be reached using the tab key, activated with the enter or space keys, and that focus indicators are visible to users as they navigate through the page. The visual focus indicator is crucial as it shows users where they are on the page, enabling them to interact with elements effectively whilst also ensuring that they do not become disorientated.

To assess compliance with WCAG 2.2, testers should also ensure that the tab order is logical and intuitive. The tab order should follow the visual flow of the content, typically left-to-right and top-to-bottom, to provide a predictable navigation experience. Additionally, it is important to check that all content and functionality accessible by mouse is also accessible by keyboard. This includes verifying that drop-down menus, modals and popups, and other dynamic content can be operated using keyboard controls.

Another key area is testing for keyboard traps. Keyboard traps occur when a user cannot navigate away from a particular section or element using the keyboard. This can be particularly problematic in modals and popups. Ensuring that users can freely navigate out of such components and that the focus returns to a logical place in the interface is essential.

QA teams should employ both automated tools and manual testing methods. Automated tools such as tabA11y can quickly identify incorrect tab order or an absent ‘skip to main content’ button. However, manual testing is indispensable for a thorough assessment, as it allows testers to experience navigation first-hand and identify subtle usability issues that automated tools might miss.

Next steps

These are some bite-size insights on how we tackle real-world accessibility considerations. There are many resources available that will give more in-depth information and practical help on how to design, develop and test the keyboard accessibility of your site. One great resource that provides advice on specific patterns is the ARIA Authoring Practices Guide. Here you can find more information, working examples and code snippets for various common components. 

Another excellent resource is the Inclusive Components Project by Heydon Pickering, accessibility editor for Smashing Magazine (itself a great front-end resource). It’s been around a little while now but it still holds up as an accessibility-focused pattern library.

We’d encourage you to draw from the examples in libraries like those mentioned above to help you piece together all the elements to ensure that your components meet keyboard requirements.

Article 1: Access All Areas: Insights on Web Accessibility

Article 2: Access All Areas: Essential Aspects of Web Accessibility