larlet-fr-david-cache/cache/bbc4e316b19a81c3e220cefd6bc73af6/index.md

title: What the Heck Is Inclusive Design?
url: https://24ways.org/2016/what-the-heck-is-inclusive-design/
hash_url: bbc4e316b19a81c3e220cefd6bc73af6

<p class="lede">Naming things is hard. And I don’t just mean <abbr title="Cascading Style Sheets">CSS</abbr> class names and <abbr title="JavaScript Object Notation">JSON</abbr> properties. Finding the right term for what we do with the time we spend awake and out of bed turns out to be really hard too.</p>
<p>I’ve variously gone by “front-end developer”, “user experience designer”, and “accessibility engineer”, all clumsy and incomplete terms for labeling what I do as an… erm… see, there’s the problem again.</p>
<p>It’s tempting to give up entirely on trying to find the right words for things, but this risks summarily dispensing with thousands of years spent trying to qualify the world around us. So here we are again.</p>
<p>Recently, I’ve been using the term “inclusive design” and calling myself an “inclusive designer” a lot. I’m not sure where I first heard it or who came up with it, but the terminology feels like a good fit for the kind of stuff I care to do when I’m not at a pub or asleep.</p>
<p>This article is about what I think “inclusive design” means and why I think you might like it as an idea.</p>
<h2>Isn’t ‘inclusive design’ just ‘accessibility’ by another name?</h2>
<p>No, I don’t think so. But that’s not to say the two concepts aren’t related. Note the ‘design’ part in ‘inclusive design’ — that’s not just there by accident. Inclusive design describes a design activity; a way of designing things.</p>
<p>This sets it apart from accessibility — or at least our expectations of what ‘accessibility’ entails. Despite every single accessibility expert I know (and I know a lot) recommending that accessibility should be integrated into design process, it is rarely ever done. Instead, it is relegated to an afterthought, limiting its effect.</p>
<p>The term ‘accessibility’ therefore lacks the power to connote design process. It’s not that we haven’t tried to salvage the term, but it’s beginning to look like a lost cause. So maybe let’s use a new term, because new things take new names. People get that.</p>
<p>The ‘access’ part of accessibility is also problematic. Before we get ahead of ourselves, I don’t mean <em>access</em> is a problem — access is good, and the more accessible something is  the better. I mean it’s not enough by itself.</p>
<p>Imagine a website filled with poorly written and lackadaisically organized information, including a bunch of convoluted and confusing functionality. To make this site accessible is to ensure no barriers prevent people from <em>accessing</em> the content. </p>
<p>But that doesn’t make the content any better. It just means more people get to suffer it. </p>
<p>Whoopdidoo.</p>
<p>Access is certainly a prerequisite of inclusion, but accessibility compliance doesn’t get you all the way there. It’s possible to check all the boxes but still be left with an unusable  interface. And unusable interfaces are necessarily inaccessible ones. Sure, you can take an unusable interface and make it accessibility compliant, but that only placates stakeholders’ lawyers, not users. Users get little value from it.</p>
<p>So where have we got to? Access is important, but inclusion is bigger than access. Inclusive design means making something <em>valuable</em>, not just accessible, to as many people as we can.</p>
<h2>So inclusive design is kind of accessibility + <abbr title="User experience">UX</abbr>?</h2>
<p>Closer, but there are some problems with this definition.</p>
<p><abbr title="User experience">UX</abbr> is, you will have already noted, a broad term encompassing activities ranging from conducting research studies to optimizing the perceived affordance of interface elements. But overall, what I take from <abbr title="User experience">UX</abbr> is that it’s the pursuit of making interfaces  <em>understandable</em>.</p>
<p>As it happens, <a href="https://www.w3.org/TR/WCAG20/"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.0</a> already contains an ‘Understandable’ principle covering provisions such as readability, predictability and feedback. So you might say accessibility — at least as described by <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> — already covers <abbr title="User experience">UX</abbr>.</p>
<p>Unfortunately, the criteria are limited, plus some really important stuff (like readability) is relegated to the AAA level; essentially “bonus points if you get the time (you won’t).”</p>
<p>So better to let <abbr title="User experience">UX</abbr> folks take care of this kind of thing. It’s what they do. Except, therein lies a danger. <abbr title="User experience">UX</abbr> professionals don’t tend to be well versed in accessibility, so their ‘solutions’ don’t tend to work for that many people. My friend Billy Gregory coined the term SUX, or “Some <abbr title="User experience">UX</abbr>”: if it doesn’t work for different users, it’s only doing part of the job it should be. </p>
<p>SUX won’t do, but it’s not just a disability issue. All sorts of user circumstances go unchecked when you’re shooting straight for <em>what people like</em>, and bypassing <em>what people need</em>: device type, device settings, network quality, location, native language, and available time to name just a few.</p>
<p>In short, inclusive design means designing things for people who aren’t you, in your situation. In my experience, mainstream <abbr title="User experience">UX</abbr> isn’t very good at that. By bolting accessibility onto mainstream <abbr title="User experience">UX</abbr> we labor under the misapprehension that most people have a ‘normal’ experience, a few people are exceptions, and that all of the exceptions pertain to disability directly.</p>
<h2>So inclusive design isn’t really about disability?</h2>
<p>It <em>is</em> about disability, but not in the same way as accessibility. Accessibility (as it is typically understood, anyway) aims to make sure things work for people with clinically recognized disabilities. Inclusive design aims to make sure things work for people, not forgetting those with clinically recognized disabilities. A subtle, but not so subtle, difference.</p>
<p>Let’s go back to discussing readability, because that’s a good example. Now: <em>everyone</em> benefits from readable text; text with concise sentences and widely-understood words. It certainly helps people with cognitive impairments, but it doesn’t <em>hinder</em> folks who have less trouble with comprehension. In fact, they’ll more than likely be thankful for the time saved and the clarity. Readable text covers the whole gamut. It’s — you’ve got it — <em>inclusive</em>.</p>
<p>Legibility is another one. A clear, well-balanced typeface makes the reading experience less uncomfortable and frustrating for all concerned, including those who have various forms of visual dyslexia. Again, everyone’s happy — so why even contemplate a squiggly, sketchy typeface? Leave well alone.</p>
<p>Contrast too. No one benefits from low contrast; everyone benefits from high contrast. Simple. There’s no more work involved, it just entails better decision making. And that’s what design is really: decision making.</p>
<p>How about zoom support? If you let your users pinch zoom on their phones they can compensate for poor eyesight, but they can also increase the touch area of controls, inspect detail in images, and compose better screen shots. Unobtrusively supporting options like zoom makes interfaces much more inclusive at very little cost.</p>
<p>And when it comes to the underlying <abbr title="HyperText Markup Language">HTML</abbr> code, you’re in luck: it has already been designed, from the outset, to be inclusive. <abbr title="HyperText Markup Language">HTML</abbr> is a toolkit for inclusion. Using the right elements for the job doesn’t just mean the few who use screen readers benefit, but keyboard accessibility comes out-of-the-box, you can defer to browser behavior rather than writing additional scripts, the code is easier to read and maintain, and editors can create content that is effortlessly presentable. </p>
<h2>Wait… are you talking about universal design?</h2>
<p>Hmmm. Yes, I guess some folks might think of “universal design” and “inclusive design” as synonymous. I just really don’t like the term <em>universal</em> in this context. </p>
<p>The thing is, it gives the impression that you should be designing for <em>absolutely everyone in the universe</em>. Though few would adopt a literal interpretation of “universal” in this context, there are enough developers who would deliberately misconstrue the term and decry universal design as an impossible task. I’ve actually had people push back by saying, “what, so I’ve got to make it work for people who are allergic to computers? What about people in comas?”</p>
<p>For everyone’s sake, I think the term ‘inclusive’ is less misleading. Of course you can’t make things that everybody can use — it’s okay, that’s not the aim. But with everything that’s possible with web technologies, there’s really no need to exclude people in the vast numbers that we usually are. </p>
<p>Accessibility can never be perfect, but by thinking inclusively from planning, through prototyping to production, you can cast a much wider net. That means more and happier users at very little if any more effort.</p>
<p>If you like, inclusive design is the means and accessibility is the end — it’s just that you get a lot more than just accessibility along the way.</p>
<h2>Conclusion</h2>
<p>That’s inclusive design. Or at least, that’s a definition for a thing I think is a good idea which <em>I</em> identify as inclusive design. I’ll leave you with a few tips.</p>
<h3>Involve code early</h3>
<p>Web interfaces are made of code. If you’re not working with code, you’re not working on the interface. That’s not to say there’s anything wrong with sketching or paper prototyping  — in fact, I recommend paper prototyping in <a href="https://shop.smashingmagazine.com/products/inclusive-design-patterns">my book on inclusive design</a>. Just work with code as soon as you can, and think about code even before that. Maintain a pattern library of coded solutions and omit any solutions that don’t adhere to basic accessibility guidelines.</p>
<h3>Respect conventions</h3>
<p>Your content should be fresh, inventive, radical. Your interface shouldn’t. Adopt accepted conventions in the appearance, placement and coding of interface elements. Users aren’t there to experience interface design; they’re there to use an interface. In other words: stop showing off (unless, of course, the brief is to experiment with new paradigms in interface design, for an audience of interface design researchers).</p>
<h3>Don’t be exact</h3>
<p>“Perfection is the enemy of good”. But the pursuit of perfection isn’t just to be avoided because nothing ever gets finished. Exacting design also makes things inflexible and brittle. If your design depends on elements retaining precise coordinates, they’ll break easily when your users start adjusting font settings or zooming. Choose not to position elements exactly or give them fixed, “magic number” dimensions. Make less decisions in the interface so your users can make more decisions <em>for</em> it.</p>
<h3>Enforce simplicity</h3>
<p>The virtue of simplicity is difficult to overestimate. The simpler an interface is, the easier it is to use for all kinds of users. Simpler interfaces require less code to make too, so there’s an obvious performance advantage. There are many design decisions that require user research, but keeping things simple is <em>always</em> the right thing to do. Not simplified or simple-seeming or simplistic, but simple. </p>
<p>Do a little and do it well, for as many people as you can.</p>