Accessibility at BlaBlaCar
Chapter 0 — The preamble
BlaBlaCar offers a transportation solution, our main goal is to make the service usable for as many users as possible without creating complexity. In parallel, assistive tools have become more reachable than ever, we all have some of them for instance in our mobile phone and in most OS environments.
Key figures and usage
According to the World report on disability published by the World Health Organisation (WHO), 15% of the world’s population lives with some form of disability and 253 million people are impacted by vision impairment.
Types of disability that affect interfaces usage are deafness, cognitive, physical, speech, dyslexia and visual disabilities.
Users have diverse abilities, skills, tools, preferences and expectations that can impact how they use a service. For more details and examples see, Diversity of Web Users published by the World Wide Web Consortium (W3C).
Sometimes, users need to change colors, zoom level, use keyboard navigation or enable a screen reader to access content.
Chapter 1 — The knight’s philosophy
Most of the time, one of the greatest enemies of accessibility (a11y) is lack of awareness: we just don’t think about it, and if we do, we don’t know how to apply it properly or we even intentionally skip it because of popular beliefs like:
“It doesn’t impact so many people”, “It’s not for our business model”, “We don’t have time for it”, “Blind users aren’t going to use the platform anyway”…
This is wrong. Following a11y standards is a virtuous circle that has many benefits for the entire service, including better readability for all users, stronger organic SEO, larger audiences and positive communication.
Many small steps can be taken for a limited cost. For instance, picking the right color tones, adding alternate contents, complementary a11y attributes… It’s also easier to make those choices early in the project.
Our role as Front-end engineers is to convince everyone that design for all is a benefit, not a constraint. We have to raise awareness on this topic for people who tend to forget that a11y can reach a bigger audience in the end, especially when you launch your product in multiple countries.
At BlaBlaCar, as you may understand, we are not taking a11y as a dedicated project but as a part of the global quality standard. We try to include it upstream by sharing good practices during the conception process and by using manual & automated tools during development phases.
Otherwise we would be always late, spending time on fixing tasks as if we were running after a train that never stops.
Chapter 2 — The magician’s light
BlaBlaCar context
To give you a bit of context, the BlaBlaCar’s front-end team is progressively re-building the old mobile and desktop website as a Single-Page App. It includes a technical migration to React and UX improvements. As you may already know our brand recently launched multiple design updates for example, a fresh new logo with updated colors, fonts and illustrations.
UX aspects
During a rebranding process, there are some compromises between readability and the design spirit you want to achieve to refresh the brand.
More readable, more comfortable!
That’s the reason why we have two different colors tones: one for brand content and printing; and another for digital use.
Color tones used for interfaces are darker variations of the brand colors:
To check readability and define good combinations between text and background colors, we used contrast color finding tools for example, Tanaguru. It really helps defining allowed colors combinations and guidelines. For example, if the contrast is not high enough, we added some usage conditions like a minimum font size and a requirement to make the font bold.
Globally we try and follow Use of Color level A and Contrast Minimum — level AA by the W3C. Our contrasts are evolving as we try our best to improve them on a continual basis.
In addition to enhancing the readability, we heavily simplified our UX templates during our rebranding: fewer elements on each page, larger font sizes, such as larger interactive components buttons, inputs…
Color blindness tools
To preview our design as seen by colorblind users we used Skala Preview, which supports all major types of color blindness, including protanopia, deuteranopia, tritanopia and monochrome.
Dancing letters
That’s what dyslexic users can see (GitHub source):
To avoid this as much as possible, we avoid using blur, justify or adding extra space between letters. Pure black text on a pure white background and long paragraphs can also be problematic for dyslexic users. For more details on surprising UX bad habits see, 6 Surprising Bad Practices That Hurt Dyslexic Users by UXMovement.
Chapter 3 — Guardians of the temple
Tech aspects
As you know, we are currently rebuilding the web part from scratch into a Single-Page App. This project uses a design system library named Kirk (see Design System for the web by Jérôme Smadja on this blog) which is our starting point to take into account all a11y aspects. Having standard-compliant components is the first step to deploy good practices efficiently to the rest of the application.
Dev tools and building process
When building a new component, we obviously start to look more in depth at standard recommendations: ensuring we apply the right semantic markup with appropriate attributes (aria, roles, alternate contents…), thinking about updating states attributes with JavaScript for more complex components (dropdowns, modals…).
To help us avoid basic a11y errors, we use ESLint rules, with Airbnb ESLint configuration. We also have unit tests on content and attribute states (aria-hidden=”true/false”, no empty value for icon title…) to make sure a11y is verified for all changes.
So if dedicated elements are required, Front-end engineers can’t forget it.
Respecting Web Accessibility Initiative (WAI) rules isn’t a strong enough guarantee that the interface will be usable and comfortable for all users. To check component implementations in features, we do some manual tests with keyboard navigation and with screen readers enabled (we commonly use VoiceOver).
Regarding end to end tests, we could implement some global use cases and scenarios on our principle flows, to be sure we don’t have any accessibility issues.
Monitoring a11y quality level (not implemented yet)
After a discussion with Kaelig Deloumeau-Prigent (Shopify) we recently became interested into upgrading our accessibility checking tools using Pa11y Webservice. This would allow us to monitor our a11y quality at all time and see the evolution.
Conclusion
The goal was to share how we try to improve and maintain the accessibility level of our service. As you see, we remain pragmatic on this topic, so your feedback is very welcome. We also hope this article helps to wake up the accessibility knight in you and that you found useful information for your personal quest. We’ll keep you posted on updates about our exciting Single-Page App project!
See you soon for the next chapter!
