Updating the team process to improve Web Accessibility
at NewsKit
But first, an update from me
During the past year, after the fantastic experience at Vodafone, I have been working at NewsUK, joining the NewsKit team!
Here, I have been mainly growing around React.js, CircleCi, A11y, Typescript and contributing to building a new design system; where my team takes the name from.
In this blog post, I want to tell you about NewsKit and how we have been improving the accessibility of our components enhancing the team process.
What is NewsKit?
NewsKit is a design system built on React.js. It aims to provide interactive, flexible, and accessible React components for creating digital products.
We are already using NewsKit for internal projects here at NewsUK, and in the future, it will be released as open-source.
But! Fortunately for you, you can already make use of its potential.
To know more about the library, I would like to point you to “Introducing newsKit a themeable design system for unique media brands”, and the official NewsKit website, where all the documentation sits.
The A11Y challenge
Working in a new company, or in a new team, always brings new challenges and learnings, from pure coding to soft skills.
One of the missions I and the NewsKit team had to face was to build accessible React components.
I wasn’t being exposed to accessibility before this role but I have immediately found it interesting, easy to learn, and satisfying to implement.
When you like something it is always easy to pick up!
During the implementation of our components, we started realizing we could do better from the accessibility point of view.
We noticed some issues with the contrast ratio, keyboard flow, and VoiceOver not giving the expected information to the user.
We needed more planning. More thinking with accessibility in mind before writing any line of code and while doing that. Then, test more with screen readers, and of course, pay more attention to accessibility during the code reviews.
Quick to say but to bring the whole team on the same page takes time and clarity on how to achieve it.
I have then started working on my knowledge around A11Y, and contributing more and more during our meetings with recommendations.
But me doing that couldn’t work and be solid enough. Ideally, everyone had to take part in it, planning, researching, and taking accessibility into account prior to and during development.
The Plan
To make it more clear to myself and to the team I first created a quick map of how I did visualize the new team process, deciding when the accessibility research had to start, how had to be executed, and the ideal outcome.
Just above you can see the map I created. It is quite self-explanatory and does the job. As you can see I have proposed to add two new steps and influence a few others.
In the first rectangle, the phase where a need for a new component comes up. Next, the component design; even if white the design step is fundamental, is where lots of work around accessibility can be already done. Be sure that color contrasts, font sizes, how the user is supposed to interact, etc satisfy WCAG guidelines.
After that…
THE NEW STEPS
The aim of this meeting is for the engineer to understand the functionality, get familiar with the design, and start to think about the HTML structure of the new component, key for accessibility.
After the necessary information have been collected the engineer can now investigate how to make the new component accessible. Thinking about the HTML structure; which Aria properties might be needed, how they work and how to enable them; what the WCAG guidelines say about it, and of course test everything with a screen reader.
(Ideally with all the most used: JAWS, NVDA, and Voiceover)
The outcome should be a detailed document to present and share with the team members. It should explain, step by step, how a user would interact(with keyboard and without), what would be read by the screen reader, and any other relevant WCAG recommendations.
These yellow actions on the left were already existing steps, which now require more attention from the team.
It means double-checking that the a11y recommendations have been taken into account and applied in the code.
The trial
Ultimately we have experimented with this approach for one of the new components we are building, the Modal dialog.
A modal dialog is known for not being always an easily accessible web component. But if built correctly it can be smoothly used.
I tried the process for the first time, documenting and sharing it with the team.
Once started, I mostly based myself on the WCAG guidelines, recollected important learnings from online courses I previously did, and obviously, I have tested with the screen reader.
I will never stress enough how important is to manually test your a11y recommendations.
Be aware of how it sounds listening to the screen reader going through your component, and realize if it makes sense to you.
If it does not make sense for us it won’t make sense for our users either.
Some of the key information the research included were:
- Step by step how a keyboard or mouse user would have interacted with the Modal.
- Where the focus should go on open, on close, and how to set it with Javascript.
- Tab trapping, what it is, and how to achieve it.
- The need to be able to close the modal on overlay click or on ESC press.
- The necessary ARIA attributes, how the screen reader would have guided the user through the Modal.
- Libraries that could help us out, to avoid reinventing the wheel.
This is a very short summary but important to understand how granular I believe we should go. Sharing and discussing these requirements prior to development is fundamental.
The research did bring insight to the whole team, raised more awareness around A11Y, and led us to important decisions about how to tackle this complex component.
Fortunately for you, the Modal has been not released! and do not hesitate to check what else we have already built for you on the NewsKit website!
