How can developers embed equality of access into their web and learning resource design? Saffron’s very own Nabin Purja digs into the overlooked topic.
The web development industry isn’t lacking in online resources. But, it’s critically bare when it comes to practical guidance on web accessibility. While it’s not hard to find typical accessibility standards and guidelines, it’s not a topic that’s widely exposed or explored in online coding courses – no matter how skilled the learners are. This is indicative of one of the main reasons why the standards are not followed.
Accessibility can cover a wide range of issues and with over 7.15 million people with learning disabilities in the UK, this isn’t something that can be put on the back-burner. We need to be aware of not alienating this vital audience. But it’s also important to consider it from all user experiences because thinking about accessibility actually makes the user experience for everyone, better.
When considering web accessibility, developers often only cater for visual impairment and often overlook the many people who are unable to use a mouse, due to various conditions including motor and dexterity impairment and who rely on the keyboard in order to interact and navigate. This is a requirement to meet the Level A (minimum) standard of WCAG guidelines.
As a developer, the first step to solving this is a simple process of keyboard-only testing. Here’s how to get started.
Testing keyboard-only navigation
Running out tests to see if a website is navigable with a keyboard is simple. The essential keyboard commands are:
- Tab – navigate to the next focusable element
- Shift+Tab – navigate back to the previous focusable element
- Enter or Spacebar – activate the currently focused element
There are other commands required for different interactions such as checkbox and dropdown but for now, let’s focus primarily on navigating buttons.
Click on the link below to view a simple demo that will allow you to try out navigating into different elements. You’ll notice that the mouse cursor is not visible when trying to point your mouse into these elements.
When navigating using the tab key you’ll be able to see a highlight border style around the link elements, this is the focus indicator to let the user know which element is currently selected. Only one element can be focused on at a time, the two buttons after the links had no representation of being selected. When we face this kind of scenario, it’s difficult to know where we are and how to progress. This type of issue is very common because often the focus indicator is removed for aesthetic reasons.
Providing better focus indicators and implementing custom focus styles
To prevent the elimination of focus styling, the best practice is to implement custom focus styles. Not only does this improve the accessibility experience, but it also allows us to have consistent styling across browsers whilst also staying within the branding guidelines. The requirement for the custom focus style is to make it stand out with the use of a thick outline and higher contrast colour.
Check out GOV.UK Design System to see how the focus styling is handled by GOV.UK.
Use ‘What Input’ JavaScript library
Even with custom focus styles, designers and developers might still have the urge to remove them. One way to overcome this whilst keeping the accessibility feature intact is to have the focus styles only visible if the focus comes from a keyboard. ‘What Input’ is a JavaScript library that detects the current input method (mouse, keyboard or touch). This library makes it safe to remove the focus styles for mobile users, whilst ensuring that each user gets the right accessibility tools that they need for their personal user experience.
[data-whatintent='mouse'] *:focus {
outline: none;
}Understanding what’s focusable
Poorly structured HTML is another reason for keyboard incompatibility. The key aspect of focus is to be clear that all interactive elements must be focusable and non-interactive elements must not be focusable. By default, the focusable elements are links, buttons, form fields and the like. But is possible to make a non-interactive element to receive focus by adding the tabindex attribute.
Non-interactive elements shouldn’t be focusable
In most cases, adding tabindex in elements such as a container, is not required. It is a common misconception that adding this attribute is needed for screen readers to announce the desired text.
Use native elements
Aside from the button element, a typical method to create an interactive button is to use a div element. But, for it to be accessible as a button, the following is necessary:
- provide
tabindexto make it focusable - assign
role="button" - include an
onKeyPressevent handler to make sure the - click fires on ‘Enter’ keypress
This indicates why it’s recommended to stick with native elements as much as possible. Otherwise, you’ll have to do extra work, whilst potentially risking accessibility for many of your users.
Considerations for keyboard testing
There’s no need for a specific environment or any tools required for validating keyboard accessibility. Checking out other websites with keyboard-only navigation can give some helpful insights. These are the main things you’ll want to consider when running a keyboard accessibility test:
- Check that the focus order is intuitive and logical
- Ensure all focusable elements have an obvious focus style
- Ensure that all interactive elements are functional with keyboard only
- Ensure that focus is never trapped
Making the web a more accessible place
For many, accessing the internet in an easy, logical and usable way can offer freedom that most of us take for granted. By forgetting, or simply ignoring access needs you are potentially making life harder for millions of people, and not just those that have a disability. Becoming aware of the changes you need to make and increasing the inclusivity of your website or platforms can improve UX as well as UI for all users.
Whilst extra coding and elements that don’t necessarily fit the overall aesthetic of a project can feel cumbersome, failure to adhere to all web accessibility guidelines can be hugely detrimental. Research carried out by the ‘Click Away Pound’ in 2019 shows that 69% of users with access needs will click away from websites with a difficult user experience. Ensuring users stay on your work of art, is surely a thing to strive for!
Here at Saffron, we’re hot on Total Quality Management (TQM). We want to ensure and maintain the highest level of quality for all of our users, and with the entire Saffron team responsible for quality assurance from end-to-end we can all hold each other accountable.
Accessibility testing is a key part of our process. Ensuring we develop best practices, have the tools to implement it and the steps to make it most effective – means that all our projects will not only meet, but exceed the guidelines and our clients’ expectations.
Give us a shout to find out more about accessibility and how we can help all your learners get the best learning experience.
