Inclusive Design Patterns

03 November 2016

I preordered Inclusive Design Patterns by Heydon Pickering when it was announced last summer. And this past week I’ve been spending time reading through the patterns and learning more about accessibility. Pickering does a great job going through all the ins and outs of various patterns that you may use in your work and how to make sure they are accessible and work well for all users.

What stood out for me wasn’t just all the little bits and pieces I picked about how to do my job better, but the way in which Pickering makes it easy to understand. This isn’t hard, it’s a matter of thinking about people who don’t use the web the way you do, and then making sure your site works for all. I’ve read a few other books on accessibility, but this one walks step-by-step through common patterns and I found the approach really great. I recommend reading through this, even if you think you already have a good handle on accessibility, I picked up a lot of little things, it was well worth the time.

My highlights are below via chapters, since reading an epub makes page numbers irrelevant. Also, please remember, these are out of context, if you have questions or thoughts, you should read the book.

Introduction

Web pages are not immutable artifacts. They should be tolerant of changing, dynamic content. This content should be managed in terms of discrete components which can be reused as agreed patterns.

The potential audience of a website or app is anyone human. Inclusivity of ability, preference and circumstance is paramount. Where people differ — and they always do — inclusive interfaces are robust interfaces.

…thinking about the structure of data and trying to arrive at an optimal solution is designing and there’s not an Adobe license or copy of Sketch in sight.

The best part is that designing inclusive interfaces, like designing robust data schemas, doesn’t have to be any harder or more complex than making exclusive or otherwise obsolete ones. It’s just different. By looking at common web interface patterns through the lens of inclusivity, this book will help you quickly learn how to apply and reapply conventions that will earn you a broader and less frustrated audience.

The inclusive designer anticipates these problems, because experience tells them that people differ, well, in lots of different ways. Far from being daunted or frustrated, they know that by exploiting standard conventions they can achieve more by doing less. In other words, they know when to design and when to employ what is already designed — a simple HTML button element, provided as standard by the HTML specification. Resizable, translatable, focusable, interoperable, stylable, restylable, maintainable, mutable, simple.

The Document

It is possible to switch languages within a page using the lang attribute on child elements within the <body>. For instance, I may want to quote some French within an English language page…

By employing content breakpoints, you can ensure successful layouts for a range of devices far greater than you would ever be able to manually test with. Unless your superpower is prescience and you can anticipate the device setup of each and every one of your users, this is the only way to go.

You may recall my remark earlier that the browser itself is an interface. To achieve inclusive design you should act as a facilitator, allowing users to configure the way they view and interact with the content you provide them. The fewer decisions you “make for them, the more they can make for themselves.

The key to inclusive design isn’t to target specific groups, it’s to not exclude groups arbitrarily — there’s nothing to gain.

Progressive enhancement is about building a strong foundation of content, logical and robust in form, which is resilient to a multitude of network and scripting failures. It’s not just about JavaScript or CSS being unavailable, but when and how they are unavailable, for how long, and when they should be made available, and in what order.

Throughout this book you’ll hear a lot about accessible names. These are the assistive technology compatible labels for the various elements of your web pages. The accessible name for a document, <iframe> or embedded SVG element is provided by their <title>. It should describe the purpose of the contents of said element.

A paragraph

What’s less known is that very high contrast can actually diminish readability for some users. Sufferers of scotopic sensitivity syndrome14 (or Irlen syndrome) are sensitive to glare, and stark contrast can result in blurred text or text that appears to move around. It is advisable to slightly temper the contrast between your paragraph text and background color.

…in a world of artifice and ornamentation, utility is radical.

A Blog Post

Inclusive design is about appreciating how people really use interfaces, not just fixing technical errors.

First of all, though, it needs to be stated that — like drop-down menus — if you don’t need a menu button, don’t involve one. As a rule of thumb, if the menu has fewer than five items, just lay them out; make them available to the user at all times. In desktop viewports, there’s rarely any reason to hide a navigation menu away, regardless of the number of items it contains. Hiding functionality away from users and requiring them to perform an additional action to reveal that functionality is always a last resort.

Communicating the state of functional elements within web interfaces is an important part of making those interfaces inclusive of anyone using assistive technology and who is therefore dependent on the accessibility tree22. Remember, the accessibility tree is a version of the DOM that exposes the role, property, value and state information the author provides to assistive technology software.

…mindful of the need for accessible labels, potential problems with Windows’ high contrast mode and ease of touch operation….

Inclusive Prototyping

They’re here to help you practice thinking inclusively as you formulate your own patterns to solve your own design problems. It’s investing this thought in the early stages of the design process that leads to a robust product.

Almost all of the successful projects I’ve worked on as a designer and developer have included interactive paper prototyping in the early stages of the design process.

The trouble with high-fidelity mockups and prototypes is that they tend to look finished. People are polite and you won’t get honest feedback about something that looks like it’s had a lot of work put into it. That it’s made of paper at all means it’s clearly only an allegory of the real app, so feedback about aesthetic particulars is kept to a minimum. Focus remains on whether the idea solves the problem well.

It’s easy for the user to feel tested, so make it clear that you are not testing them but the app itself. If they don’t know how to operate it, make it clear in advance that it’s not their fault, but yours as the designer.

I’d recommend several individuals (or teams) work on the same component so there are different solutions to compare. Second, accessibility should be a prerequisite for consideration. If a solution isn’t keyboard-accessible, uses a poor structure or is not explicable by screen reader, it’s out.

A List of Products

…while second guessing who might want to use our products is a game we have to play, making assumptions about how folks use them can only alienate potential fans and customers.

No matter what the content or the commercial offer, there is no reason to second-guess how the user might operate the interface. In fact, doing so can only reduce the quality of the product. To save money, you are going to want to make just the one interface, not a different one for each imagined user group. So, you make it inclusive. You make inclusivity a quality of the product — not an expensive additional feature.

I have qualified the .call-to-action class with the element name a. You may have read elsewhere that this is redundant, but it serves an important purpose: it restricts the use of .call-to-action styles to the a element. By using .call-to-action on a <button>, or an inaccessibly interactive <div> element, the style will not be invoked. This effectively prevents a developer from using the wrong element for the job. In the excellent article “How Our CSS Framework Helps Enforce Accessibility14,” Ian McBurnie details a number of similar provisions.

Another way that <button>s are differentiated from links is that they don’t have a pointer cursor style. In “Buttons shouldn’t have a hand cursor15,” Adam Silver explains why manually adding cursor: pointer to <button> elements is a usability mistake. It is not standard behavior to invoke this cursor style on <button>s, and it’s risky to break with long-held convention.

Complaints toward online services are almost always from people unable to actually use an interface, but a 100%-compliant interface can still be entirely unusable. By the same token, an interface with the odd superficial error may be so simple, well structured and clear that it’s still a pleasure to use.

Inclusive design has a different take. It acknowledges the importance of markup in making semantic, robust interfaces, but it is the user’s ability to actually get things done that it makes the object. The quality of the markup is measured by what it can offer in terms of UX.

Infinite scroll hijacks the user’s scrolling action to perform an unexpected behavior, commandeering user control and diminishing the user experience. The “Load more” button invites the user to take an explicit, labeled action at their convenience and therefore conforms to the second of Henny Swan’s UX principles, to give users control.

A Registration Form

The placeholder attribute is a relatively new addition to the HTML specification. It was created in response to developers wanting to give hints for the type of content the user should provide. The key word here is hints: the placeholder is not a labeling method by itself and should only be used to provide supplemental information.

Structures of HTML, like the structures of natural language it annotates, should be judged in similarly nuanced terms: what helps or hinders; what’s too little or too much.