One of the things I find frustrating about technical books is that I often use them for a period of time, get an insight or two, go off and work on that insight for a while, and then I put the book down or look at something else until I'm in the mood for another insight, and the process repeats. Much of my technical library gets used this way. As such, I have hundreds of books that I have read part of, dozens I have read all the way through, very few that I have read cover to cover in a short period of time.
That makes it difficult to do timely reviews for certain books, so I decided I wanted to change that. Therefore, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. Some may remember my chapter by chapter breakdown of Alan Page's book "How We Test Software at Microsoft" or Zed Shaw's "Learn Ruby The Hard Way". I'm planning on doing something similar this go around. However, this is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book. It's officially available as of today :).
All right with that out of the way, let's get into it.
ACCESSIBILITY FOR EVERYONE
Inclusive Design Patterns", another book that I want to do a proper review for as well. He points out that dealing with Accessibility is a step out of the comfort zone for many, and admittance that we have, at times, not been kind to some of our users and also to acknowledge that people use their technology and the Internet differently. By thinking and designing inclusively and considering Accessibility up front, we can better serve a more diverse group of people, and that is a worthy end goal in and of itself. I wholeheartedly agree.
CHAPTER ONE: CONSIDERING ACCESSIBILITY
Generally speaking, Accessibility and Inclusive Design don't fall into the lap of one person. There's no single arbiter that determines if a site is Accessible, and if you are part of an organization that is set up that way, let's just get this out of the way now... "you're doing it wrong" (btw, that's me injecting color commentary, Laura didn't say this specifically ;) ). Accessibility doesn't happen in a vacuum and it cannot be addressed separately from the rest of the development of your site or app.
Are there excuses to be made for why Accessibility is not something every organization considers from the outset or places great emphasis on? Absolutely. Some see it as boring, or the connection with the beneficiaries is hard to pin down. We're afraid we'll do it all wrong, and the most likely candidate for peak excuse is "it's too hard and there's too much to do". Laura hits every one of these out of the park. I'm intimately familiar with every one of these resistance statements and yes, all of them can be true, but we can also rise above them if we are so determined.
Ultimately, Accessibility is making a choice to include as many people as possible. For some, that will mean making specific modifications to communicate with assistive technology. Laura uses a simple example to drive the point home with doorknobs. Doors with round knobs are less accessible than doors that have levers that can be twisted. Laura makes the point that even her dog can open a lever handled door (though she frequently wishes that were not the case). A sliding door with a motorized movement and proximity detector to open would be the most accessible and would work for everyone, but may be impractical to implement everywhere. In this case, the lever knob is as inclusive as possible and as practical. It's definitely better than the round knob. Tones at signal crossings, closed captioning, simple and clear signs, and my personal favorite example that I love to hate, IKEA assembly instructions ;).
To successfully approach Accessibility, one of the best ways to put us into that mindset is to develop Empathy. It's easy to dismiss products that don't serve our needs when there's nothing preventing access to us. At that point, it's a matter of taste and aesthetics. However, it becomes a different issue when a product conspires to work against you because of dense text, dependence on mouse or touch controls, use of certain elements or not using them to deliberately or not deliberately but unknowingly locking people out of using them. The fact that I now have to wear readers has had a profound effect in the way that I interact with technology today.
The symbol of Web Accessibility today is the "screen reader". In fact, for many people, the screen reader is the start and finish of many Accessibility initiatives. If you mix Dragon Naturally Speaking into the mix, hey, you're off to the races. Alas, it's not that simple, and there's a lot of other issues related to Accessibility. Screen readers do however emphasize the fact that the mouse is effectively unusable, and that keyboard navigation is essential, and that is a big wake-up call to a lot of people when their mouse or trackpad isn't part of the workflow. See Empathy above ;).
Accessibility has a vocabulary all its own, and it can feel like there's a bit of an "in crowd" mentality to those not familiar with it. I admit to feeling the same way the first time I saw the #a11y hashtag and wondering what it meant. I was happy to be an ally, but then later learned that a11y was a way to say "Accessibility" in a shorter way ('a' with the number eleven between the 'y' because accessibility is 11 characters long). that's clever but it takes asking to understand what it means, and that's a bit of a metaphor for Accessibility in general. We want to make the web and apps accessible, yet sometimes getting into the "club" to understand Accessibility is harder than it needs to be. Laura is throwing down a gauntlet and saying that Accessibility needs to be something everyone on the development team has a stake in and takes part in, hence the book title, Accessibility for Everyone.