DesignOps Summit 2021 – Designing Accessible Research Workflows (Phil Hesketh)

Founder of Consent Kit

We’re a compliance first CRM built specifically for design research

Today I’d like to start with accessibility in the context of design research and share how we’ve been approaching it to improve our workflow with participants

During the pandemic we’ve all had to adapt are ways of working to be remote first

  • This shift has forced us to reimagine our workflows – in doing so its highlighted many cracks in the systems we use
  • Systems and tools who did not consider accessibility upfront have excluded many people from using them, leaving them unable to take part and really isolated them from the wider world

There’s a myth in design research that 5 participants is the magic number of people to learn from

  • What’s not a myth is that 1 in 5 of those people will have an accessibility need of some kind

What counts as accessibility is not always be obvious

  • An accessibility issue could be someone walking down the street with the sun shining down on their phone making them unable to see their screen

Accessibility can sneak up on you

  • Declining vision due to age, it gets harder to focus on texts that’s close and harder to tell the difference in colors (ex: grey text on white)
  • Sooner or later all of us develop accessibility needs of some kind

Accessibility in our workflows is really a design problem

  • The series of decisions and actions we take when we create the processes and tools that we use and when we design those processes and choose those tools intentionally with accessibility in mind, it really doesn’t take much to improve the quality of the experience for everyone

Ops is essential for systemic change, and changing how an entire function performs in a business and the impact that can have

Within this role we need to be mindful of not only the tool and processes that we’re using but also how we came make other important factors like creating the space for psychological safety of all our participants and ensuring all our processes are inclusive to everyone

  • Not only do we need an understanding of how people with different needs interact with our products and services but also assessing if something meets a given standard is technical
  • Requires looking at how information is structured on a code level and really understanding how assistive technologies can make sense and interpret what is going on, on the screen
  • Calls for understanding of how we can best communicate and use language in a simple and effective way
  • Accessibility is a moving target

  • Our goal is to enable research that’s ethical and inclusive in a remote first world and to make sure we were doing this we first needed to understand how we’re doing research
  • What steps are we asking participants to go through?
  • What outcomes do we want the participants to have at each step?
  • We need to collaborate with different teams and disciplines to make these changes,
  • Our approach must clearly communicate and define the scope of what we want to do

  • Maps are helpful to align people around a specific topic, and to remove any ambiguity from a discussion
  • Framing things on a timeline helps us to think more holistically about what happens before after and in between the things that we’re talking about
  • A definition of what was and was not in scope for this project

What does good look like?

  • What are we asking people to interact with at each step and where do we need to make those improvements

  • We started to add the products and tools we were using at each step
  • Next big question
    • Of these things how do we know what is and isn’t accessible?
  • W3C created a set of technical standards for web accessibility called the Web Content Accessibility Guidelines (WCAG)
  • Current standard 2.1 (2.2 will be released later this year)

Focusing on the principles emphasizes the need to think about how our users interact with our content

 

  • In theory, we thought a good approach would be to work through each of the screens within each tool used within our process and scale them against the standard
  • In practice it required a lot of work and meant that we had to assess every single view against 48 different criteria’s
  • The criteria’s needed additional reading to understand what they meant and had varying levels of complexity and expertise required to test if we met it or not

There are a lot of great automated testing tools out there (Google’s Lighthouse)

Creating a plan to start making those changes

  • 2 categories to plan for
    • Things we can control directly
    • Things we can’t control
  • In the steps using consent kit:
    • More detailed analysis and recorded them and got the developers involved to understand the size of the proposed changes and prioritized them against the perceived effort before converting them into tickets and feeding them into the products
    • Rudimentary design system → Testing each of the components in there would help us prevent issues from making it into the product
    • Additional testing was required when we put all the components together into a particular journey or view

For the cases where we couldn’t control the outcome

  • Find alternative tools or when that wasn’t possible to try and find ways to mitigate the worst of it

Sometimes you must work with what you have

  • Instead of trying to find an alternative we focused on what we could control

Checking our work

Our interpretation of the standard and automated testing tools, as good as they are, was only going to get us so far.

  • We got in touch with a 3rd party specialist to audit our work and they provided us with a detailed report highlighting several improvements to how consent forms were working and an explanation of why the things were accessibility issues

Focus on outcomes

  • People can be excluded in a non-technical way
  • Informed consent is a good example
    • Our design outcome is really comprehension
      • Can that person understand what is being asked of them in such a way that they are able to make a meaningful decision about whether they should take part or not

 

Getting to the bottom of that

  •  Technical needs
    • conform to a recognized standard (color contrast, navigate by keyboard only etc.)
  • Analog needs
    • What if the person doesn’t have access to a printer or a scanner?
    • What if the person doesn’t know how to sign a PDF digitally?
    • What if they have no access to internet?
    • What if they’re not comfortable using computers?

Comprehension

  • For someone to comprehend what is being asked of them we also need to think about what and how we’re communicating through the content itself
    • What is the research about?
    • What should they expect?
    • What are you recording?
    • Who else is going to see it?
    • How long are they keeping it for?
    • What are their rights and how do they exercise them?
  • Not just to understand but to be able to comprehend them and what do those things mean to them in their own individual context?

  • 45% of adults aged 16-65 read at a literacy level of 1 or below
  • 3% read at entry level 1 or below

Caroline Jarret from Effortmark wrote an article summarizing and translating the results of this survey

  • Low literacy which basically means – not good at reading
    • Just looking at someone’s reading doesn’t give us a particularly useful indication of their ability

At level 1 you can expect someone to be able to:

At level 2 you can expect someone to be able to:

Looking back at the statistic → 45% of adults aged 16-65 read at a literacy level of 1 or below

  • That means 45% of the adult’s struggle to decide if a website is telling them the truth or not and may not even have the writing skills to even complain about it

Unfortunately, low literacy is not just an issue in the UK, these numbers are similar across the globe

Consent forms are often filled with complicated legal language

  • The language in your consent forms do not have to be complicated
  • There are organizations campaigning for plain legal language

Plain Language Network → For resources and examples of plain language being used successfully in legal context

At the beginning of this century Washington state rewrote its entire basic health and safety law

  • Took user centered design techniques and applied it to the law
  • Proves that if the actual law can be usable, surely, we can do the same for our informed consent

Clear and plain language massively reduces people’s anxiety and can really help to build a greater sense of psychological safety

How do we scale bespoke content forms and remain compliant?

  • Can test each individual piece for comprehension
  • Operationally reduced the time needed to sign off and approve individual consent forms from 2 weeks to just a few minutes

  • Canadian digital service and research ops communities consent form builder allowing you to specify the criteria of your study up front before putting up the document for use

Test with real people → This teaches you more in a few moments than you would with any secondary research