Understanding the key differences between Accessible Design and Inclusive Design
Despite being part of the same family, these two siblings have some very real and important differences.
Accessible Design and Inclusive Design are not new concepts; they have both been around almost as long as the web itself, but they seem to be especially hot topics in recent years and with very good reason. Along with other human-centered concepts such as Ethical Design and Responsible Design, they form a vanguard of design practices and thinking that mark an important shift for designers: A shift away from designing for the companies or brands that pay our salaries, and towards designing for the actual people who use the things that we design.
The surge in popularity of these terms recently seems to have also resulted in a blurring of the boundaries, and confusion around what each means. I often see the terms used interchangeably and have fielded questions from clients and other designers alike over recent months around whether they are in fact the same thing. To allow us to tease apart the confusion and dig into the differences, we first need a greater understanding of each of the terms; what they mean, where they came from and how they have evolved over time. As Accessible Design is the older of the two concepts, and consequently perhaps the most well known, let’s start there.
A World Wide Web accessible to all
Web accessibility guidelines have been around almost as long as the web itself. Tim Berners-Lee (who many consider the ‘creator’ of the modern internet) included comments on disability access in a presentation he gave ar the Second International Conference on the World-Wide Web (WWWII) in Chicago in 1994.
The first web accessibility guideline was compiled by Gregg Vanderheiden and released in January 1995, just after the 1994 Second International Conference on the World-Wide Web (WWW II) in Chicago (where Tim Berners-Lee first mentioned disability access in a keynote speech after seeing a pre-conference workshop on accessibility led by Mike Paciello). Source: Wikipedia
Over the next few years, a wide range of companies and organisations began adding to and updating these guidelines, eventually culminating in the Unified Web Site Accessibility Guidelines, a later version of which would act as the foundation for the ‘Web Content Accessibility Guidelines 1.0’ or WCAG 1.0, published on 5th May 1995 by the World-Wide Web Consortium, or W3C as they are now known. The W3C is an international authority responsible for setting global web standards and best practices. The W3C is headed up by Tim Berners-Lee, and their mission is: To lead the web to its full potential.
WCAG 1.0 consisted of 14 main guidelines, ranked by priority, and covered most of the absolute basics in ensuring that the content and sites beginning to appear on the newly emerging internet could be accessed by as many people as possible. Things like clear navigation structures, not relying exclusively on colour, video or audio and creating structures and content that degrade and transform gracefully. WCAG 1.0 has since been super-ceded by WCAG 2.0, and then in 2018 by WCAG 2.1, but if you are interested, you can read the original version of the guidelines in their full and glorious detail here.
Can people use it?
The dictionary definition of Accessible is: easy to approach, reach, enter, speak with, or use. This definition gives us a clear and concise view of what accessibility should mean in the context of digital design and the web; it should mean that anyone should be able to use the things we design. Whatever it is we are creating, it should be planned, designed and built in a way that means it is for everyone. Everybody should be able to use it.

Accessible [ ak-ses-uh-buh l ] — adjective: easy to approach, reach, enter, speak with, or use.
Accessibility is based upon objective, measurable facts, and is concerned only with technical or logistical truths. Contrast ratios, font sizes, browser versions, alternative text, touch targets: these are all things that can be objectively defined, measured and tested. Accessible Design is concerned only with what is feasible or possible. It cares only whether the designs can be accessed by all, not whether they will be, or even should be. Accessible design has no personal grievances or ulterior motives; It doesn’t care if people like or dislike your product or service, nor is it concerned with popularity. This is the key difference between our concepts.
Do people actually want to use it?
Inclusive design, broadly speaking, is also concerned with the same preposition; that whatever it is we are creating, we create it in a way that means it is for everyone. This time though, the key difference is that Inclusive Design is concerned not with the logistics of whether everybody can use it, but whether everybody actually wants to use it, and ultimately whether everybody feels safe using it.
Inclusive Design is less logical and objective and much more emotional and subjective. It requires much greater levels of understanding and empathy and asks you to put yourself in somebody else’s shoes. While Accessible Design cares only that everyone can hear your message, Inclusive Design asks you to consider your message itself.
Accessibility concerns the structures and containers that hold your information, the channels that carry the information, and the way that your information is formatted and presented. Inclusivity lives or dies based on the information itself, and on your understanding and empathy with your audience. What are you trying to say? Are you speaking from a position of privilege? What points are you trying to make? Is your perspective clouded by bias, unconscious or otherwise? How will your message make people feel? Could your message or design be viewed as discriminatory or offensive? Is your view based solely on your own experiences? Does it exclude certain demographics or people?
Inclusivity [ ɪnˌkluːˈsɪvəti ] — noun: the practice or policy of including people who might otherwise be excluded or marginalised, such as those who have physical or mental disabilities and members of minority groups.
To use a physical analogy; Let’s imagine a very old, very traditional, members-only gentleman’s club, with a grand old clubhouse that is hundreds of years old. Now, let’s say that the Club decided it was time to modernise in order to meet new accessibility requirements, and took the time to fit wheelchair ramps, handrails, an elevator and hearing aid induction loops. After these alterations, the clubhouse would definitely be much more accessible, but as a very traditional club that doesn’t allow female members and has a substantial joining fee, could the club every really be considered an inclusive space?
Conversely, an LGBTQ+ charity’s headquarters would likely be a very welcoming and inclusive space, but if it is a long way from any public transport, at the top of a long flight of steps with narrow halls and doorways, could we legitimately refer to that space as accessible? While these physical analogies might not translate across to the online world perfectly, they hopefully help illustrate some of the key differences between the two concepts.
What can we do as designers?
The good news is that we can all take some fairly simple and painless steps as designers to start improving the accessibility of our designs. Firstly, have a read through the latest WCAG guidelines if you haven’t already. They provide a solid foundational understanding of a lot of the key concepts behind designing with accessibility in mind. Apple’s Human Interface Guidelines and Google’s Material Design Guidelines also both contain a lot of very practical guidelines and easily implemented changes to help make your designs more accessible.
Aside from guidelines, there are also numerous accessibility websites, tools, and plugins that can all help you design with accessibility in mind. References like the WebAIM Contrast Checker to check contrast ratio compliance, and websites like We Are Color Blind that offer some great examples of what works well for people with color blindness. Other tools and plugins include things like Stark, a plugin for Adobe XD, Sketch and Figma that helps you consider accessibility as a part of your everyday workflow. These kinds of tools and plugins should be a non-negotiable part of every designer's toolbox.
When it comes to designing for inclusivity and diversity, my first and most important point is that as a white, CIS male designer in an industry already dominated by other white, CIS male designers, there are a million other people more qualified, relevant and experienced than me to offer practical, applicable advice on improving the inclusivity of your design practice. People like the amazing Jennifer Hom: illustrator, speaker, and Experience Design Manager of Product Illustration at Airbnb, who completely reimagined Airbnb’s Design Language System based on a foundation of diversity and inclusion. People like industry thought-leader Tatiana Mac: writer, speaker, and a leading light in the constant battle for inclusive, accessible and ethical design: she created this incredible conference rider that champions diversity and inclusion at every level.
With that in mind, I guess the only advice I can offer based on my own personal experience would be this: Get comfortable being uncomfortable. As diversity and inclusion advocate Vernā Myers’ says in her top-rated Ted Talk, if you want to overcome your biases, you must move boldly towards them. Confront them. Actively seek out conversations and situations that put you outside of your comfort zone. Listen to, read, and follow authors, designers, and creatives that are radically different from you in all kinds of ways. Embrace change. Immerse yourself in diversity. Build teams that include people of all ages, genders, and sexualities, from all kinds of backgrounds, cultures, and countries. Collaborate with creatives and designers of different abilities and skills, with different views, opinions, and values. The more diverse our teams and collaborations are, the stronger and more inclusive your designs and your thinking will become as a result.