Accessibility - Simple changes to make a big difference.
Why it matters?
Scroll to the bottom of this article to see a demo video of using a form with simulated low acuity.
We use the Internet for everything these days from checking posts on social media, ordering items online, education, entertainment, even ordering repeat prescriptions online. The Internet is also one of the easiest ways to communicate with each other, meaning it is defining and changing the way we communicate. It truly is becoming an integral part of our personal lives. In business, the cloud is changing the way businesses work with and store data with the number of systems using the Internet as a delivery platform on the increase.
Nothing above should be a surprise, but what might be a surprise is the lack of attention to accessibility amongst engineers. I should note, this isn't an article that is intended to have a dig at software engineers. Software Development is difficult and often stakeholders are trying to solve the business problem and requesting features without the user being put at the centre of the design. However, with changes in the law - all public sector websites and applications should meet new accessibility requirements.
A recent case brought against Dominos by a blind man who couldn't order food using a screenreader was upheld by the courts setting a precedence that disabled people could be shut out from large parts of the economy if businesses do not make sites accessible.
They say you must make your website or mobile app more accessible by making it ‘perceivable, operable, understandable and robust’
There are 13.9 million disabled people in the UK. With almost 20% of working-age adults and 8% of children disabled, it is more important than ever to consider making the Internet more accessible. Not all disabilities will make the Internet inaccessible but one significant and obvious disability is sight loss. 2 million people in the UK are living with sight loss and one of those is my eldest daughter who is registered blind.
In a previous project, we were tasked to ensure that our application met WCAG 2.1 AA but it felt like an afterthought in the design. The more I thought about this the more it felt like ticking boxes rather than making a difference.
Simple form example
Consider the following screenshot of a simple form to register your details to sign up for an event.
It looks straight forward enough - a standard form with an image and a submit button. Now, consider the same form as someone who has a visual impairment - In this simulated case using the NoCoffee plugin, they have low acuity and cataracts. All of a sudden the form no longer is recognizable, and extremely difficult to use.
There is now no way to determine what the form is about, the user can probably just about see that there is a button but there is no way to easily see the fields and what they are asking for.
Screen Reading technology can assist users, however, they need help to work properly and a poorly formatted web application will be hard to navigate for the user even with screen reading technology.
Lighthouse is an opensource tool used to highlight issues and improve web applications and one of its useful features allows us to highlight accessibility issues. If we run the audit against the current implementation we are given a score of 54 and a number of errors.
This is a score out of 100, so clearly there is some work required to make this form accessible. The issues highlighted by Lighthouse are grouped for ease and in our particular example it has highlighted the following issues:
- Names and Labels
- Best Practises
- Internationalization and Localization
Lighthouse also encourages manual checking for elements that it cannot check and will highlight areas on the page that pass the checks. Clicking on one of the errors expands to reveal what elements are affected on the page, making it easy to identify and resolve the issue.
Fixing the errors
With the information and tools in place, we can begin to improve our form. Starting with the first issue on the list - Contrast. Poor contrast can make it difficult for users to read.
Expanding the error shows that our H1 element is failing the contrast ratio. Using the standard inspect on the Chrome developer tools we can locate the H1 tag that does not meet the requirements and can see its contrast ratio is 2.67. The recommended ratio for WCAG AA is 4.51 and 7.1 for AAA.
The circle shows the current color selection and anything above the top line will fail AA. Dragging the circle between the lines will pass AA and fail AAA. Meeting AAA can be met by selecting a color below the bottom line.
Updating the color and rerunning the audit shows an improvement in our accessibility score to 57. There is still a long way to go, so let's go and address the rest of the errors.
Names and Labels
Names and Labels have a number of errors which are also easily fixed. There is no document title set for the web application and the images on the page do not have alt tags. Fixing both of these errors allows the screen reader to describe what the page is about and can also read descriptions of the images.
There is one error under this category that is worth expanding on. Looking at the form we have placeholder text to describe what to put in each field. This visually shows the user what to put in each field and the screen reader can also read the placeholder text. However, despite this, there is still an error raised. The problem is once the user starts to type into that field, all context to that field has been lost. Creating labels and using special aria-* labels give me more context to the screen reader and user. In this instance, we use aria-describedby to achieve what we want. Once we update our form and rerun the audit we have increased our score to 86.
A simple change has increased our audit score significantly.
Final few tweaks
The score has improved a lot but there a few final tweaks we can do.
- Setting a language - This can help the screen reader know what language to readout.
- Tab Index - Specifying an implicit tab order is valid but can be frustrating for users relying on assistive technology.
- Remove duplicate ids - Duplicate ids can break the accessibility of labels and form elements. Ids are used to uniquely identify html elements.
- Allow zooming and scaling - Removing the user-scalable=no allows users to zoom and scale using assistive technology.
Once these changes have been made we reach a score of 100. The effort to reach this has been small, but the benefit to users relying on assistive technologies is now greatly improved.
Whilst we now have a score of 100 there is still something missing. As it currently stands our form does not alert users relying on screen readers when a field is invalid. This can be easily resolved by applying the aria-invalid attribute and conditionally setting is based on the state of the errors. We can also add to our aria-describedby label to read out the error message to the user.
This is a simple example to highlight how simple small changes to our markup can make the form accessible to all. Aria labels assist with screen reading technology but it is important to note that a solid HTML semantics is read by browsers and screen readers. Semantics help create a structured page and can assist users by making it easier to find and read things that are of interest without difficulties.
I truly believe that as developers, technical leads, product owners and stakeholders we should be building this in from the start and not considering it as an afterthought. These simple changes can make a real difference to users with additional needs, but true validation really comes from being able to test solutions with real customers.
It's about making a difference not ticking a box.
Hopefully, the article has demonstrated how small changes can enable users not only in business applications, but in applications used in everyday use. Thank you for reading and to conclude the article lets see our final work simulating a user with poor vision and see how we get on.