The Intermittent Book Review: “Inclusive Design Patterns” by Heydon Pickering

Today, I’m going to step out of the arena of providing updates on our home in Austin, Texas and instead begin what I hope will be a continuing journey. What I would like to do here is to gradually review a book, chapter by chapter, via blog posts. For me, the reasons are two-fold – one, I get to share the knowledge I’m learning with others who may also be interested in the same topic. Secondly, and more selfishly, it is a way to help myself remember what I’ve read and trigger my brain to hold that information a bit more tightly.

For the past several weeks I’ve been reading “Inclusive Design Patterns” by Heydon Pickering which you can check out here. It’s a great look into changing the way you think about designing and developing websites to ensure they are accessible to all users while also providing a robust experience to users who may not require the use of any accessibility features.

It’s been a great read so far, but I’m finding myself breezing through chapters thinking, “Wow, this makes so much sense! I need to keep this in mind!” before turning the page, diving into another chapter, and repeating the process.

While I am kicking my brain into gear while reading, I feel that I’m not doing all I can to really commit this stuff to memory.

So, I’m hoping that by writing a review per chapter I’ll retain some more of this information. It’s sort of like writing notes in the margin or highlighting text, but because I’m a maniac who doesn’t like to alter anything in favor of keeping it crisp and clean I’ll just do it here instead.

For this book, I’m actually going to start reading it from the first chapter again so I can log my notes and thoughts as I go rather than attempting to recall what I found interesting when I initially read through it.

I hope you’ll get as much out of this as I do! Without any further ado let’s dive into chapter one!


Chapter One: Introduction

With the help of a couple of examples, we’re able to drill down into what inclusive design really is and how to achieve it from the onset of a project. It’s not about learning a new set of skills, necessarily — instead, it’s more about rewiring our brains to think more inclusively about what we’re building and how we’re building it.

One of the most easily digestible examples here is the use of a button on a webpage. There are countless ways to create a visual button. We could style a div or an anchor tag or a span or really anything. The easiest thing to do is to style A Thing to look like a button.

But does it make sense to do it that way?

The quick answer is: No.

While we can make literally anything look like a button, the only thing that will actually act like a button is a button itself. Out of the box, a button element is able to be tabbed to for users who may not be able to operate a mouse. Button elements are instantly accessible in this way while divs and spans do not afford the same luxury right out of the box.

The best part is that designing inclusive interfaces, like designing robust data schemes, doesn’t have to be any harder or more complex than making exclusive or otherwise obsolete ones. It’s just different.

Heydon Pickering, Inclusive Design Patterns

One thing I do somewhat disagree with in the beginning of this chapter is the idea that achieving pixel perfection in our sites is wasted energy. While I absolutely, 100% agree that there is a world of difference between print design and web design/development, I don’t believe we have to lose pixel perfection in order to make that point. I have certainly worked with print designers in the past who don’t quite understand how or why print design doesn’t translate well to the web; however, this doesn’t mean that a skilled web designer shouldn’t expect pixel perfection when we develop their site.

I don’t think pixel perfection is always achievable with the ever-growing list of devices, screen sizes, and screen shapes available to users. I do think, though, that pixel perfection at specifically defined breakpoints (for instance, desktop and up) is achievable and should be sought after if we’re hoping to maintain consistency and a quality of standards in our work.


The next chapter is The Document, and I’ll be back with a write-up on that…  sometime? This is going to be intermittent! Next time we’ll discuss the document as a whole as well as fonts, elements on the page, progressive enhancement, and breakpoints. See you then!

Comment section

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Created by shashank singhfrom the Noun Project