Before getting started talking about accessibility in digital products, and what the inclusive design methodology actually means, let’s first set the scene…

You’re walking down the street, heading to your favourite café to get a coffee before work. You might have to stop at some lights, press the button and wait for the green man, probably standing on those yellow bumps at the edge of the curb. Maybe you wonder if it’s worth just risking it and crossing early. But eventually the sound starts, the light turns green, and you can safely walk across, round the corner and into the café. You order your oat milk flat white to go, and drink it as you catch the lift into your office to start your work day.

Now, if that was relatable at all, let’s break it down a little. You might not be considering all the environmental aspects in your daily trip to work that have been designed to be inclusive for both the abled and disabled.

Firstly, your wait at the lights includes both sound and texture cues to aid those with hearing and/or visibility impairments. Your favourite cafe offers milk alternatives, so if you cannot consume animal products, you are able to still enjoy your classic order. And your office can be accessed via a lift — whether you are physically able to use stairs or not.

All of these things begin to foster an inclusive environment for all to enjoy. Now, there’s more to it than just those things. But hopefully that’s beginning to highlight that accessibility and inclusion benefit everyone, not just those with disabilities.

When we begin to transfer this across to digital products, the same principle applies — while at its core it’s about making sure anyone can interact with the product — it also benefits everyone who is using it.

But hold up a second Ivy, you’ve been using both “accessibility” and “inclusivity”… So what do you really mean when you use these words? There is nuance in the difference between these two things, which is often not apparent at first glance, that is important to establish as we aim for both accessibility and inclusivity in our work.

So what’s the difference between accessibility and inclusivity then?

inclusive

/ɪnˈkluːsɪv/

adjective

1. including all the services or items normally expected or required. All-in
2. "menus stating fully inclusive prices."
3. not excluding any of the parties or groups involved in something. "Only an inclusive peace process will end the conflict."
4. aiming to provide equal access to opportunities and resources for people who might otherwise be excluded or marginalised, such as those having physical or intellectual disabilities or belonging to other minority groups. "This is a testament to the inclusive environment fostered at our school."◦ (of language) deliberately avoiding usages that could be seen as excluding a particular social group, for example avoiding the use of masculine pronouns to cover both men and women.

accessibility

/əkˌsɛsɪˈbɪlɪti/

noun

noun: accessibility

1. the quality of being able to be reached or entered.
2. "The restoration project involved repairing the roof and improving accessibility."

(Thanks Google and Oxford Dictionary for the definitions)

To summarise what that means for me as a designer, and what it means for EndGame as a company who builds products, is that we aim to ensure all products our teams develop are easy to use and are easily understood by users of any party or group, including those in minority groups. This is often limited in scope due to the nature of our work, but within the confides of how we work and the quality we aim to provide at EndGame, this is what we aim to achieve.

Why say “yes” to making the effort to build what could be seen as a “nice to have”?

Before sharing resources that can help you start your journey, I want to spend some time talking about why it’s important to build inclusively from kick off. To help aid this, let’s first break down some common excuses for why we wouldn’t design this way.

Poor accessibility only impacts a small number of people

or

Disabled users aren’t our target demographic

But, these perpetuate a self-fulfilling prophecy in a way — if you don’t design in a way that enables disabled users to engage, how or why would they? If you never consider them potential users, you’ll never have them as your audience — let alone a targeted user base. This makes disabled people one of the biggest minority groups in society.

In New Zealand alone, almost a quarter (24%) of the population is disabled (https://www.odi.govt.nz/home/about-disability/). With this in mind, it’s important to recognise that members of your target audience can be impacted by temporary and/or situational disabilities — so even the statement that “disabled users aren’t your target audience” is flawed.

Temporary or situational disabilities, as the names suggest, are non-permanent disabilities. Here are some handy definitions to help explain:

·     Situational disabilities are when environmental factors influence our ability to perform usual tasks with the same ease. Examples include trying to hear someone over loud music in a club (situational deafness), or trying to see a phone screen with sunlight glare on the screen (situational visibility impairment).

·     Temporary disabilities are typically injury based — perhaps you have broken an arm and it needs to be in a cast for two weeks, making it particularly difficult to use for that time and restricting your mobility.

(I welcome you to read through Microsofts Inclusive Design Guidebooks for a more detailed breakdown of these.)

When we begin to think of these situations, it really begins to highlight (at least in my opinion) why designing accessible and inclusive products from the get-go is really important. Otherwise, you exclude around a quarter of your potential users (without including non-permanent disabilities), and open the door for competitors to rise.

So how do we do it then?

Building inclusive products is a journey. And as with any journey, it’s easier to plan it right from the start, rather than coming up with a plan half way through production — or harder still, retro fitting it after the product has already gone live.

However, just because it’s harder to retro fit, or start after development is progressing through the build, it doesn’t mean it’s not important to do. In fact, the priority for inclusive design is just as important if you are already in production, especially when users are using it.

And while it might seem like an intimidating thing to do, this ✨ making things inclusive ✨ task, it’s important to know, we are not alone in our journey. It’s an important task that many professionals around the world are currently advocating to improve, and because of this, there are many resources online to help aid us in this endeavour. This is because building inclusive, accessible products matters. It matters to so many people, all across the globe, that there is an almost endless supply of guides, tools, and tutorials available and there are industry standards to aim for.

At the end of this post, I’ll include a collection of resources for further reading — with a lot of these aiming to help assist whether you are just starting out or progressing through your inclusion journey and hopefully these will provide some context and help for how to approach these things within your own team.

If you have an existing product, or are part way through development and want to start implementing inclusive design, the first step in your journey should be an accessibility audit. Conducting an audit is a great way to identify your starting point for any existing product — and it’s vital to identify where you’re starting from in order to properly formulate a plan.

The next step is to figure out your game plan — all together the task of building for inclusivity doesn’t really end. As long as you are building a product, you will need to be thinking about how to increase inclusivity, so making sure you think of bite-sized pieces for your approach. Often in the development space we work in agile/agile-adjacent environments, but that lends nicely to breaking the work down and making sure you’re not taking on too much at any one point in time.

The next step might not be too surprising, but it’s important to come together as a development team and work out priorities of approach. As part of this it’s really important for the whole team to be clear about the task at hand. As an inclusion advocate, you might be using high level terms to discuss approach but if you are not specific and clear details can get lost in translation.

Imagine sitting in a room and speaking about fruit. This leaves plenty of room for individual interpretation — are you talking about grapes? Or oranges? Or maybe you’re trying to talk about tomatoes?

The key thing to realise when it comes to building inclusive products however, is that you need buy-in from the whole team. It’s not a one person task, it requires effort from everyone in the team to work hard together on a shared goal in order for it to be successful. So coming together and opening the door for communication between all team members is vital.

The way we approach this at EndGame is we involve designers in our quality assurance process — basically this means after the developers have built the interfaces in code, ready for users to experience, we get the design team to do one last check to make sure we all were thinking about oranges in those earlier conversation(s).

Together, as a united team, this is how we build inclusively — we ourselves are inclusive and open about our approach to the difficulties of making inclusive products. And we share resources and knowledge to empower everyone on the team to be able to confidently know, that no matter how pedantic anyone in the room may be, tomatoes shouldn’t be a feature in your fruit salad, and we are working together on our shared goal.

Things to remember

If you made it this far, thank you. Inclusive design is a journey, one that once you’ve started I hope you will continue on throughout your career. The main take away I hope you leave with is a more detailed understanding of is the why for inclusive design and, of course, that you use the handy dandy links below to help you in your journey as you make progress and advocate for this in future.

Handy dandy resources to kick start your journey

• https://www.w3.org/TR/WCAG21/ : The full WCAG 2.1 guidelines — these are the standards that EndGame currently aims to meet with their customers products
• https://www.w3.org/WAI/WCAG21/quickref/ : customisable resources to help making the WCAG guidelines more approachable
• https://inclusive.microsoft.design/ : Microsoft has some great resources for getting more informed about what inclusive design is and I recommend everyone checks them out — they explain everything very plainly so it has a low barrier to entry
• https://digital.nhs.uk/about-nhs-digital/standards-for-web-products/accessibility-for-digital-services/accessibility-audit-checklist: A checklist for performing an accessibility audit to test WCAG 2.1 compliance (requires some technical expertise to use however)
• https://www.nngroup.com/ : An incredibly useful site for articles on user experience — with high importance on only sharing articles founded on research
• WCAG for designers: A website put together by a passionate designer aiming to provide a cheatsheet for others so that wCAG compliance is baked into the design process
• Learn Accessibility: a go-to breakdown of what accessibility is and how to implement accessible practice in web products
• The Accessibility Cheatsheet : a breakdown of the WCAG guidelines in plain text and code to help make implementing accessibility more approachable
• a11yProject: resource sharing website for accessibility related articles
• W3C Accessibility checklist a WCAG 2.0 and/or 2.1 checklist to help make sure you are compliant with the guidelines — this offers a breakdown of what the requirements are and how to test them
• Ethical Design - A resource sharing site for ethical products
• WCAG 3.0 Working Draft for those who want to read ahead to the WCAG 3.0 guidelines — you can find them here in their entirety
• Accessibility Handbook  is a practical accessibility handbook for designers, it absolutely oozes with personality from the writer
• https://www.odi.govt.nz/home/about-disability/disability-etiquette/ : More information for disability etiquette in New Zealand
  ‍

As always, if you have any queries or questions about how we work here at EndGame — feel free to drop us a line or pop into the office for a chat.