Skip to main content

Inclusive Design at Matillion: Building for Everyone

 

 

Matillion is committed to making sure our products and services consider diversity, equality, and inclusion at every stage of our lifecycle, from our hiring process to product delivery.

At Matillion we care about our people and our communities, which means that we view it as our responsibility to consider the broad range of people who use our products. We are customer obsessed and do not want systemic barriers to hold anyone back when using our products. With this in mind, we set out to use Inclusive Design as a fundamental element of our user experience.

 

With my background in Computer Science, Education, and Design, and as an advocate for Web Accessibility and Inclusive Design, I believe I can bring a unique perspective on the topic. 

What is Inclusive Design?

My favorite definition of Inclusive Design is:

The process of intentionally considering the needs of users who likely experience exclusion on a daily basis due to being part of a minority or oppressed group. 

As this powerful quote by Corey L. Jamison and Frederick A. Miller states:

“If we do not intentionally include then we will be unintentionally excluding.”

Therefore, it is important that we build with inclusive design in mind. However, before we dive in, I do want to briefly outline the differences and similarities between Inclusive Design and Web Accessibility, as these terms are often misinterpreted by developers in the community. As shown on the Venn diagram below, Web Accessibility focuses on people who have specific physical or cognitive disabilities, using  laws and standards for guidance. 

 

However, Inclusive Design takes a more holistic approach by building for everyone regardless of background, race, age, gender, language, culture, ethnicities, socio-economic background, religion, physical or cognitive disabilities. 

 

 

Although there is a lot of  crossover between the two philosophies, this blog will focus on the realm of Inclusive Design. But designing for accessibility is still an integral part of designing for inclusion.

 

Why is Inclusive Design important to Matillion?

 

A primary goal of every individual who contributes to the process of building a digital product should be that it can be used by every person. In order for this goal to be reachable, we need to  shift away from the preconceived ways of thinking–in other words,  our idea of a “typical” user–and instead look at individuals as unique, diverse people who have differing abilities at different times in their lives, based on their environments. According to Return On Disability, only 4 percent of businesses are focused on making offerings inclusive of disabilities (Donovan, 2022). Matillion wants not only to be on the right side of this statistic, but also to inspire other engineering teams to do the same.

 

Engineering responsibility

 

As front-end developers, it is our job to make sure the standard of web development does not shrink with the rising popularity of quickly spinning up a create-react-app. The most noticeable thing when reviewing the code of ALL developers is that the vital aspect of accessibility is often missing, which leads to web applications creating exclusions. For example, a case study commonly referred to in the Accessibility Community is the case by a blind man named Guillermo Robles, who sued Domino’s because he was unable to order food on their website or mobile despite using screen-reading software (Higgins, 2019). Despite the horrifying statistic that states over the last four years, 98.1% of top websites homepages have WCAG 2 failure with only a slight improvement during a small portion of that time (WebAim, 2022). 

As front-end developers, it is our primary role to build the user’s interface of a site or application. With this in mind, it is important to consider that end-users can range from permanent, temporary or situational disabilities. After all, each of us will fall on different parts of the spectrum throughout our lifetime. As Cindy Li says,

 

“We are all just temporarily abled.”

 

The Social Model of Disability: A new way of thinking

 

Something that really helped me change my way of thinking is the Social Model of Disability (Social model of disability | Disability charity Scope UK, 2022). The Social Model of Disability is a way of thinking created by people who have a disability to showcase how society creates barriers for people with disabilities to participate in daily activities independent of their ability to participate due to their impairments or differences (in other words,  the world around them is seen as disabling regardless of their ability). The way society functions leads to exclusion of people with impairment. 

 

For example, Dr John Stalin who was an English professor at the University of Texas developed retinitis pigmentosa which caused his sight to gradually deteriorate until he was blind. He had a deep knowledge of using screen readers to interact with computers. Many sites were not accessible to John despite his knowledge. In 2005 John was diagnosed with Leukemia. He had to research life-and-death decisions on treatment options but the information provided on many sites on treatment options were not accessible. John was blocked from accessing vital life-saving information. He kept up with family and friends by writing daily blogs of the challenges he faced through a blog platform called Leukemia Letters. It helped him stay connected to his family, friends and colleagues however the software updated and this update made the software inaccessible to John. Once again blocking him from communicating with those closest to him and who cared about him deeply (Course | edX, 2022). Other key barriers that the social model discusses are attitudinal barriers, physical barriers and information/communication barriers, each one emphasizing how individuals interact and experience the world around them. 

 

On the front end of Matillion – How we practice Inclusive Design

 

As part of Matillion’s Platform Front-end Development team, we strive towards Web Content Accessibility Guidelines (WCAG) 2.1 Level AA compliance. WCAG are broken down into four principles: 

Perceivable

As a user, I have access to all content on this page. For example, if there is an audio or video on the page and I am part of the deaf community, that information is not accessible to me without transcripts. It is not perceivable to me.

Operable

As a user, I should be able to navigate a web page using my mouse or keyboard. For example, if I tab through a site and cannot focus on a component on a webpage, this prevents me from carrying out my user journey.

Understandable

As a user, I should be able to understand the language on a page to perform an action. For example, if there is a button on a form page, it should provide the description of what the button is doing. 

Robust 

As a user, I should have access to all content on a webpage. For example, by using assistive technology. 

 

Across our products we are: 

  • Prioritizing Semantic HTML.
  • Making sure that all links have a semantic value so that, for example, buttons explain the action rather than having a generic value
  • Exploring screen readers such as VoiceOver on Mac to view what elements on page are read out to our customers if they use a screen reader
  • Adding ARIA to add meaning and context so that  assistive technology can  translate appropriate information
  • Incorporating alt tags to describe an image being shown
  • Thoughtfully exposing status and error
  • Checking that all the external/open source libraries that we incorporate into our product have either in-house or custom-made accessibility features, for example Autocomplete and Multiselect using Downshift. For more information on how Downshift caters to the  accessible library, axe-con 2021 speaker Silviu Alexandru Avram goes into further detail here.
  • Ensuring that the vocabulary we use is understandable.
  • Using resources available to us:
  • Making  sure that when a component is in focus,  there is a visible outline for our users,  for example with  our button component.

 

 

  • Investigating local browser tooling extensions such as Google Lighthouse, AxE and FireFox Accessibility Extension to make sure our products meet these standards.
  • After investigating the local browser extensions, we shifted left through the power of automation by testing as we build,  integrating axe-core using cypress-axe into our Component Library to test our components for violations in isolation.
  • Using  Google Chrome 98 latest accessibility feature release to toggle between the DOM and Accessibility Tree.

 

Not only are we standardizing practices internally, but we also understand it’s our job to contribute to the community by keeping up with the latest practices and spreading that knowledge to raise awareness. Outside our code base we have done the following:

 

What’s next?

I hope this blog is able to raise awareness on the subject and help others to explore how companies can incorporate and standardize best practices into their everyday tasks, and contribute to the social responsibility we have as engineers to make our products useful for everyone. 

 

Learn more from Viv about accessibility and inclusive design

 

Watch the video of Viv’s talk about accessibility and inclusive design here