Our story on building an accessible, usable site: a technical perspective

Spread the love

Sarvnaz Taherian Ph.D

With around 1.3 billion people living with access needs around the world, and despite making up a major portion of the global population, access citizens face immense barriers in their day-to-day lives. We’re disabling citizens further when we don’t design access into products, services, workplaces and communities.

We’ve recently worked with a client on how we start to shift accessibility and catalyse it into the realm of possibility. By taking this approach, accessibility will take on the form of innovation and creativity, rather than the tick box exercise that it currently is.

It’ll mean that when we design products and services, we’ll unlock positive possibilities for all people, that don’t exist when we look at design through the narrow lens of the “average person”.

Our team at Propellerhead partnered a client for the first phase of development of a future portal for accessibility. This first phase involved creating a small site that communicated who they are, what they do, as well as a blog to publish their thought leadership and events. This was used as our starting point for the technical discovery of how we would approach designing even a simple, static website.

The client already had a design layout and design assets for us to build, and our role was to bring that design to life, and ensure the interactions were accessible to all, regardless of disability.

Firstly, we explored web development platforms such as Webflow to establish which provide the best accessibility and usability experience for people with disabilities. Using platforms such as these can considerably speed up development time and lower costs.

We quickly found that when we delved into them, none of these platforms provided an optimal usability experience, particularly with screen readers. This was critical for the client. So, we created a site from scratch using React, Netlify (CI/CD, hosting), Cypress (integration testing), Contentful (content management), Optimizely (feature toggling, experiments), and Bitbucket (versioning, documentation).

We searched for examples of best accessibility designs and landed on Material UI to guide code design. It’s an open-source project, and provides React components that follow Google’s Material Design guidelines. It has accessibility “baked in” at its core, not tacked on as an afterthought.

Material UI has accessibility baked into it.

We wanted to be able to check our code as we go, so we looked for accessibility testing tools that we could use to guide us. We settled on the axe DevTools by Deque for browser-based a11y testing. Also, Netlify’s a11y plugin for testing in the CD pipeline.

To ensure we were following web accessibility guidelines, we researched existing standards, courses, blogs, and tools, then pulled everything into cohesive guidelines for our internal use. This made it less of a cognitive load and improved the learning curve for us.

We also discovered that the interface design tool Figma has a number of useful accessibility features (e.g validating contrast ratio) that designers can use to ensure design is accessible. We ran accessibility tests using cypress-axe with the a11y rule-set that the New Zealand recommends.

Design tool Figma has a number of useful accessibility features.

We had originally planned to do extensive user testing with people who have different types of disabilities, but due to time and budget constraints, we put on our thinking caps and thought about how we might approach accessibility testing.

As a first step, we employed accessibility testing software (of which there are many) for in-house accessibility testing. The Accessibility Insights extension was a great option for us as it provided automated checks, as well as a checklist to follow to ensure we were meeting global web accessibility standards and hadn’t missed anything.

The Accessibility Insights extension.

To understand how someone with vision impairment would navigate the site, we used Voice Over for the screen reader experience. This was eye-opening, as we learned that when compared to other websites that we visited, the client’s site is providing a truly unique and superior user experience. We’d recommend that you turn on the native screen reader for your OS, and visit your favourite websites. You’re likely to find that it is confusing, difficult, and tiring.

We know that you can’t uncover all accessibility issues from in-house tests (it’s estimated that you can only gauge ~30% of issues). Accessibility doesn’t always mean that a site is usable.

We worked with an accessibility expert who also lives with multiple disabilities. She has a wide range of experience as a web accessibility consultant. Within 2.5 hours we went through all the pages and annotated a backlog of issues that we wouldn’t have uncovered otherwise. We can’t stress enough the importance of obtaining real user perspectives.

The following week, we participated a focus group, where we were able to obtain further feedback and insights from a wider range of users with disabilities.

If you’d like to attend an accessibility meetup, you can join Auckland Digital Accessibility and Inclusive Design meetup group, which holds regular events.

Image: Auckland Digital Accessibility and Inclusive Design Meetup

Hmmmmm, we said to ourselves.

Our research highlighted major gaps in our knowledge around developing fully accessible websites. We pondered how it could be, that we’ve been working in the software and digital design space for decades and we hadn’t integrated full accessibility into our processes.

Unfortunately, it seems as though this is a wider societal symptom, where there hasn’t been a mandate for considering accessibility in the past — it is not a new issue, nor one that only affects us.

We realised that a lot of the design decisions that we make to create websites look interesting, engaging and dynamic may make them completely inaccessible to different user groups! Sometimes, a simple, elegant design is the best solution.

User testing and user research shouldn’t be skipped, even if you have a small budget and timeframe. There are always ways that you can adapt methods to understand what your users need, and how your design is perceived and used.

If we hadn’t done any user testing and research, our code would have been biased based on our own understanding of the problem areas.

The work which has come out of this project is forming the basis of company-wide accessibility guides and training, and it has made us reimagine how we design our code and digital interfaces. For example, how might we create digital experiences that can automatically be accessed with voice user interfaces such as Siri or Alexa?

There is so much potential when you shift from accessibility, into possibility- it’s not a ‘nice to have’, it’s a game-changer.

Read More