Seemingly small choices like using white text on a yellow background or typeface that is too small can impact whether someone can easily use a website or product. And barriers like this are avoidable—making products accessible isn’t easy but it’s the right thing to do.
To make an accessible product, we have to start at the beginning, Trevor Pierce, Senior Engineer, EUI, says. He works on building accessible design system components because at Elastic, we believe our products should be accessible to all.
We want to empower users and not leave people behind, Trevor says. “I don’t want people to be limited by artificial restrictions.”
Building with accessibility in mind
So, to create an accessible product, we make sure that the color contrast is right, the typeface is big enough, the lines are bold enough, and the layout works. It’s important to use good code, too, Trevor says.
Then the product is put through rigorous testing by both tools and humans. Products are tested on different browsers, zoomed in, using screen readers, without a mouse, etc.
Trevor’s philosophy is to build it as best as we can, he says.
“We put it through the paces”, Trevor says. “Accessibility isn’t a box to check.”
Bhavya Raju Mandya, Senior Software QA Engineer, is part of the team that tests our products before they go out into the wild. Before joining Elastic, she worked with kids with physical disabilities. When she joined Elastic, digital accessibility and the legal requirements around making Kibana accessible were new to her. She jumped into learning about how to test for accessibility issues, automating tests, and the processes around it.
“The truth of it is that we want to do the hard things because it aligns to our values and Source Code and, personally, it's really empowering,” Bhavya says.
Trevor agrees. “For me personally, I want to empower everyone and meet them where they are,” he says. “It’s the most gratifying, welcoming, inclusive responsibility I’ve ever had,” Trevor says.
A collective effort
And the accessibility process is an on-going, collaborative one.
“You don’t get to the top, you’re always walking,” Trevor says. “You’re always moving. Some days it’s a mile, some days it’s a few inches, but you’re moving.”
And while it can take thick skin to hear real-time feedback, that’s what helps to make the product better.
“You can hear it in their [customers and users] voices when we’re on the right track,” Trevor says. “The rough edge has been smoothed out.”
The team takes that feedback and uses it as a learning tool to grow.
We experiment, we learn, we gather, and we adapt,” Trevor says.
It helps that Elasticians are generally excited about working towards this collectively.
“We have really supportive colleagues,” Bhayva says. “People are always posting in Slack and contributing. People are curious.”
For example, a customer recently came to the team about how a certain aspect of Kibana doesn’t meet their country’s accessibility standards. So, while Bhavya and Trevor were aware of the limitation, they set up a meeting to discuss how this can be fixed in the future.
Trevor and Bhavya have approached Kibana in the past about limitations, who were receptive in hearing about how we can work together to ensure a consistent experience for screen reader usage. Recent changes include improving layouts when pages are zoomed in, and screen reader announcement when users navigate to new pages.
While we strongly believe our products need to be accessible by all, this lends itself to our internal culture too. We have internal accessibility guidelines that outline breaks between meetings, sending meeting notes beforehand, enabling closed captioning on Zoom, among others.
Whether it's invisible or visible, permanent or temporary, accessibility issues will affect us, our colleagues, and our users. Making our products accessible is about practicing our Source Code tenet As YOU, Are.
“It’s the little tiny things you can do to make the playing field equal,” Bhavya says.
Join a team that encourages you to come as you are. Browse openings at Elastic.