Understanding and improving accessibility: an example from Content Workflow

What is accessibility and why does it matter?

You have likely come across the word ‘accessibility’ in your daily life, whether that is on the internet or in a daily scenario.

When talking about accessibility in a web context, we are mostly referring to making our web content accessible to disabled users. We can also refer to inclusivity and usability. The three of these terms combined in a real life context make up what most people are probably familiar with accessibility meaning.

For example:

We might think of a library. That library could be made accessible by adding ramps at the entrance for wheelchair users and other people who may struggle to use the stairs. It could be made inclusive by making sure that staff are diverse and represent the community they serve, as well as offering a variety of services that may suit people in different circumstances e.g. outreach for improving digital literacy. Finally, it could be made usable by being well signposted and offering easy to use devices and processes for services.

Photo by Will van Wingerden on Unsplash

Making the web accessible is important because it ensures a greater amount of people can easily and independently make use of the internet. Accessibility also has a ripple effect that will benefit other, non-disabled users too. This can lead to a more inclusive and usable site or product. It’s not only our human responsibility to try to create a better experience for fellow users, but it is also becoming our legal responsibility to make sure we are creating accessible products.

Improving keyboard accessibility — an example from Content Workflow

Here at Bynder, in the Content Workflow team, we have been doing some dedicated work on improving our keyboard navigation as part of wider efforts to improve accessibility across the company. Many users may prefer to use, or need to use, a keyboard. It is also part of the most basic level of the Web Content Accessibility Guidelines (WCAG) that web pages should be keyboard accessible. These guidelines were created by the World Wide Web Consortium (W3C), a non-profit organization founded by Tim Berners-Lee, who created the internet. They are an important piece of the accessibility puzzle and act as the first line of reference for developers in their accessible coding practices.

Being keyboard accessible generally refers to the ability to:

• use the Tab button to navigate around the page
• use Enter or Space to make selections or interact with elements like buttons
• use Escape to leave certain areas of the page
• use the directional arrows to navigate certain areas of the page e.g. dropdown menus

Who might need to use a keyboard?

According to the WCAG, content should be:

• perceivable — content can be perceived, whether that be visually, through auditory means, or any other sense that may be used
• operable — can be used and navigated
• understandable — can be understood in the sense that users understand how to use the content and what to expect
• robust — it works and does so across an array of devices

The ability to navigate with a keyboard would fall under the principle of being operable.

There may be many reasons why somebody can only use a keyboard. In the realm of accessibility, this is likely to be related to a disability. This could be a permanent disability, such as a missing limb or tremors that make it difficult to interact with a mouse. It may also be due to a temporary disability, such as a broken arm.

Many non-disabled users may also choose to use a keyboard. This could be for many reasons, from simply not having a mouse in their setup, to lacking the space for extra peripherals in their workspace. By creating keyboard accessible content, we make our content more usable and inclusive as a by-product of making it accessible 😊

How we did it

To begin, we had data that represented the most common accessibility issues in our product. This data was gained from an external accessibility audit, but it is possible to test your product in a variety of ways. This includes: user testing by disabled users, automated tools, manual testing with common assistive tools e.g. JAWS or NVDA.

The most common issue for us was keyboard navigation. Some of these issues could be solved quickly. For example, if you are using a native, HTML button, you get the ability to use the keyboard for interaction as a default behaviour. Developers sometimes choose to use other elements as buttons but forget to add the extra functionality needed to make it perform like a button — this includes making it behave as expected with a keyboard. Other examples of this kind of non-semantic development include: using an anchor tag <a> as a button, even though this element exists natively, or using the table tag to style a section or even entire page instead of making use of modern styling tools like flexbox and grid.

Other issues required a little more work. For example, in some cases we discovered it was not possible to leave a modal — more commonly known as a pop-up or dialog — when using the Escape button. This can be a common mistake as many mouse users will not notice any issue. Below is an example of a modal that our users may come across.

Our insert image modal

To fix this, we needed to ‘listen’ for users using the Escape button when inside the modal so we could close it and return them to their original position. One factor that made this interesting as a problem to solve is that we also had to calculate where the user was originally so we could place them back there when the modal closed. This helps to avoid causing confusion to the user or accidental interactions.

We also added further support where we felt it would be beneficial. For example, we made sure that whenever keyboard users were navigating our pages, they would have a visual indicator that an element was in focus and therefore could be interacted with. We also make use of tooltips when icons are focused with the mouse or keyboard.

An example of a tooltip in action

Additionally, some users may be using a keyboard and a screen reader. A screen reader is a type of assistive technology that reads the content of a page to its user. A commonly used screen reader is NVDA, an open source, Windows-only programme. You can see a demo of this in use via Google’s a11ycasts series. Screen reader users may have low vision or no vision at all. To make sure this technology works as intended, it is on us as developers to make our content descriptive so it can be interpreted correctly.

One way we can do this is by adding extra information to be read to the user when they focus on certain elements. This can be achieved in many ways, such as by using ARIA attributes on elements to add additional information for screen readers only, labels for inputs, and alternative text on images. Some extra support we added in this area was adding human-readable labels to some of our menus to make sure users knew what buttons did. Below, we can see what the accessible label is on a cross button attached to a search filter.

We can see the accessibility tree in our developer tools which gives us access to accessible names

Finally, we encountered a situation in which tabbing was not possible as a menu needed to be disabled at certain points. This meant that keyboard users would not be able to tab to it. To circumvent this, we implemented keyboard shortcuts and documented these inside our product so users have a list to reference. We kept these shortcuts familiar e.g. Ctrl + C for copy or Ctrl + B for bold. For other actions, such as opening our AI tool, we had to be a bit more creative as this is not something with a precedent. We chose to use a shortcut that used the letter ‘A’ in its combination to make the association with the acronym.

Our testing approach

We are using a number of tools combined to help us test for accessibility issues. These include:

• Playwright
• aXe
• React Testing Library
• Storybook with aXe and Playwright

Playwright and React Testing Library both allow us to emulate our content, with Playwright going as far as to emulate whole pages with navigation. aXe is a hugely popular and well-respected tool from Deque, who focus on creating accessibility testing products. Their combination library aXe-playwright can be used standalone and is often used by other libraries, such as Storybook. Storybook accessibility tests allow us to test components in our design system for any violations. Some of our team also use aXe’s accessibility linter add-on in our coding editors to catch basic errors quickly.

aXe linter in action in VS Code

Whenever new code is added to our codebase, we have automated tests in place that visit our content’s pages, or look at particular components in some cases, and check if any accessibility violations have occurred. In aXe’s tool, we can check our code against WCAG rules. If any rules are broken, tests will fail, and the developer will get a message telling them how they can fix the issue. This is how that output might look:

Output from our tests that use aXe core

We can see in the image how serious the issue is, where it is occurring, and ways we can fix it. This way, we can avoid adding additional inaccessible code to our codebase.

What’s next?

Although we have done a lot to enhance our accessibility, we know there is always room for improvement. We still need to be rigorous in our manual testing and through practices such as having our team mates review our code, but the tests described in the previous section can help us catch small, common errors that can affect the quality of a user’s experience.

How will we get better?

It’s important that we keep working on our accessibility practices and treat it as important as the rest of our code. To improve, we are always sharing resources and knowledge as a team. In practical terms, some things we aim to work on going forward are:

• bringing in accessibility considerations from the design stage
• incremental updates and improvements to our components and pages
• implementing reliable cross-browser testing to ensure we have no issues across the board
• rebuilding some of our components over time if there are better and smarter ways to handle accessibility problems that may occur as web development is moving and growing all the time
• working on making our product more mobile responsive and therefore more inclusive