But first, an update from me
During the past year, after the fantastic experience at Vodafone, I have been working at NewsUK, joining the thrilling NewsKit team!
Here, I have been mainly growing around React.js, CircleCi, A11y and contributing to building a new design system; which 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!
The critical eye
During the implementation of our components, we did realize we could do better from the accessibility point of view.
From start, planning more on how to make our component accessible, test with screen readers, and paying more attention to accessibility during the development and reviews.
All of this is quick to say but not to implement. Not only the “coding developer” is responsible for building an accessible component, but the whole team is, and make the web more accessible starts from planning.
Driven by this belief, and after have improved my knowledge around web accessibility, I started contributing more and more during our meetings giving recommendations for web accessibility improvements.
But wasn’t enough.
After agreeing with my team lead, I have written and proposed a plan to improve our team process.
I didn’t want to only suggest improvements when I had the chance, during a call, during, or even after the code was written. It can be too late.
In fact, sometimes, fixing accessibility means refactor your code spending more time than initially thought, and therefore money.
Considering a11y from the beginning makes you aware of what you need to achieve and allows you to plan and write your code accordingly at the beginning.
I wanted everyone to take part in it, planning, researching, taking accessibility into account prior development.
First thing first I 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. You can see I have proposed to add two new steps.
The first new part, which happens after the design is ready, includes a meeting between a designer and an engineer, after which we have the A11y analysis.
Just to mention, the design is of course already an important step where accessibility is taken into account. Color contrasts, font sizes, how the user is supposed to interact, etc.
THE NEW STEPS
The aim of this meeting is for the engineer to understand the functionality, appreciate the design, and starting to think about the HTML structure of the new component. Key for accessibility.
After the necessary information has 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, what the WCAG guidelines say about, 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.
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 had the honor to try 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 throught 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.
- 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 lead us to important decisions about how to tackle this complex component.
At the time being the modal is still in development but do not hesitate to check what we have already built for you on the NewsKit website!