How Kiip Thinks About Accessibility

Imagine you’re trying to submit a document for your housing application while on the bus to work. The sun is shining on your phone screen, the font is too small to read, and you fat-finger all the wrong tiny buttons because of how shaky the bus is. This could’ve been prevented if the site had been built to include color contrast, dynamic content, and larger touch targets. That frustration of when a website is built poorly has become a widely felt experience in today’s internet world. Some of the issues mentioned may not frustrate every user, but it can be debilitating to those with disabilities.

As a Software Engineer at Kiip focusing on usability and accessibility, I work with the design and engineering teams to help reduce those points of friction and build a product that works for everyone!

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
— Tim Berners-Lee, W3C Director and inventor of the World Wide Web

If you read our earlier post from Kiip’s founder, Noah Harlan, on Why We Started Kiip, you’ll learn that our ultimate vision is to help the five billion people on the internet improve their lives with document management. So it’s only natural that we’d also consider the 1 billion people with disabilities! According to the CDC, 1 in 4 adults in the US experience some form of disability, and about 15% of the world population total, according to WHO.

From the start, we acknowledged that our goal to help people wasn’t achievable unless we also recognize and empower those with disabilities as well. So, early on into the process, we really put focus on making Kiip accessible and incorporating accessibility into our design and engineering workflows.

Where to Start?

Understanding and implementing accessibility rules is hard! Our designers and developers want to ship an accessible product, but accessibility can feel intimidating; especially when the WCAG standards are dense and not all of it is completely relevant to the work at hand. The main thing to understand is that it’s not just about meeting a technical standard, it’s about building for all people possible. Once you know the user story, the why we do it, the best practices start to make sense and gain momentum.

That being said, there are 7 elements to accessible websites.

If you’ve read any other accessibility guides, all of these should feel familiar. These different categories are meant to help the varying abilities and barriers that people experience. There are many reasons why people experience diverse abilities. Some may have them from birth, an illness, or develop them with age. Some may not even consider themselves to have disabilities even if they do experience such functional limitations.

So given these elements, how do they actually help reduce barriers? Well, for instance, proper use of colors can help improve the experience for people with low vision or colorblindness to make elements more visually apparent. Having good use of fonts can help those with dyslexia or cognitive disabilities in readability and focus. Keyboard accessibility can help people with seizures, tremors, or even temporary disabilities like a broken arm so they don’t require a mouse. Everyone can benefit from good accessibility.

When designs (and code) provide the flexibility to meet all users’ needs, then they are enabling. Disability is caused by a mismatch between the design and the person. This is often called the “social model” of disability. It’s important to consider the broad diversity of functional needs rather than to categorize people according to medical classifications.

Making the Product Accessible

With the whole team on board, and a couple workshops later, we were ready to start implementing accessibility into our workflows. To do this, we created a development process that worked in parallel with our accessibility goals in mind. It starts with designers creating with inclusion in mind (as seen in our previous rebrand post by Kelly). Then engineers reinforce those designs with semantic markup and go through our Accessibility Checklist based on WCAG guidelines. All of which then get QA tested across browsers and devices, through screen readers, and with keyboard navigation.

The above checklist is in no way an exhaustive list nor guarantees that the site will be completely accessible. There is no such thing as “perfect accessibility” on any site. But this checklist prompts checks for a wide range of disability conditions. It is also relevant to existing elements in our current design system, rather than including things like video WCAG guidelines when we don’t have video content.

Again, as we want to learn and emphasize why these guidelines are important, you can see in the checklist some items provide that context (i.e. under controls, it details why we shouldn’t have small touch targets because of people with limited dexterity). It’s difficult to “just do it” without being told why, so we try to integrate some empathy and understanding into our process as we go.

It’s important that everyone has that empathy too. Accessibility is a team process and can’t rely on one person.

Even for a seemingly little icon in a dialog box, we make sure it serves its intentional purpose through the lens of how an assistive tech user would perceive it. Through engineer review and designer feedback, we work as a team to improve the accessible experience.

These efforts have already started to pay off in the product too! We have become fully keyboard accessible! Keyboard navigation is a fundamental part of creating accessible experiences that everyone can enjoy.

On a more technical note, another thing we do to help ease our process of creating an accessible product is by using Chakra UI for our component library. This is more optional and a tech stack choice. Chakra is a component library with built in accessibility and highly customizable. For example, in building a Menu element, we don’t have to worry about coding in keyboard interaction or proper aria-roles since it’s already built in!

An Inclusive Future

We are learning as we implement. It’s helped our team increase awareness in accessibility and inclusion while building momentum in the direction we aspire to go!

There’s much more to be done as we hope to have an official accessibility statement by the end of this year, more automated testing, and research with specific user groups. We’re always considering and re-evaluating our choices because what we build can have a huge impact on someone’s document application journey. Whether that be in finding housing or seeking emergency services, we are here to help reduce friction and obstacles with Kiip for everyone.