What Every Engineer Should Know About Digital Accessibility By Sarah Horton And David Sloan

A few months ago, after blogging about keyboard navigation techniques, Jean Ducrot warned me that my approach might not be very "accessible" because it broke the "linear navigation" of the web page. He suggested that I read the book, What Every Engineer Should Know About Digital Accessibility by Sarah Horton and David Sloan. I've never felt confident about my mental model regarding accessibility, especially when creating highly dynamic Single-Page Applications (SPA); so, I picked this book up and have been slowly going through it over the past few months.

Accessibility is:

A core value, not an item on a checklist.
A shared concern, not a delegated task.
A creative challenge, not a challenge to creativity.
An intrinsic quality, not a bolted-on fix.
About people, not technology.

— Adapted from the Manifesto for Accessible User Experience

Every time I go to read about creating accessible experiences, what I'm hoping for is the "one weird trick" to make it all work. What I'm finally understanding is that this is simply not how accessibility happens. Creating accessible applications isn't (only) about a small set of technical decisions—if this book made one thing very clear, it's that accessibility is an ever-present, front-of-mind consideration that must be woven into the entire product development life-cycle, from ideation and design through to implementation and quality assurance (QA) testing.

Accessibility is a whole-team effort. I used to think that it was an engineering problem—that we engineers had to take whatever designs were handed-off to us and just "make it work". But, the product leads are just as responsible as the engineers. And, they have to be thinking about accessibility as they consider the interaction models being designed into the product.

Part of what makes accessibility such a hard concept for me as an engineer is that it feels challenging to define. One thing that I appreciate about the "What Every Engineer Should Know" book is that they're always zooming back out and considering accessibility from first principles:

Accessible means a person with a disability is afforded the opportunity to acquire the same information, engage in the same interactions, and enjoy the same services as a person without a disability in an equally effective and equally integrated manner, with substantially equivalent ease of use. A person with a disability must be able to obtain the information as fully, equally, and independently as a person without a disability.

— The United States Department of Education's Office of Civil Rights (OCR)

The better we can clearly articulate the high-level goals of accessibility, the easier it is to make lower-level decisions about how we want to build our digital products. In the Guiding Principles chapter, they go on to talk about the notion of "Universal Design", which is embodied by seven core principles:

• Equitable Use: The design is useful and marketable to people with diverse abilities.

• Flexibility in Use: The design accommodates a wide range of individual preferences and abilities.

• Simple and Intuitive Use: Use of the design is easy to understand, regardless of the user's experience, knowledge, language skills, or current concentration level.

• Perceptible Information: The design communicates necessary information effectively to the user, regardless of ambient conditions or the user's sensory abilities.

• Tolerance for Error: The design minimizes hazards and the adverse consequences of accidental or unintended actions.

• Low Physical Effort: The design can be used efficiently, and comfortably, and with a minimum of fatigue.

• Size and Space for Approach and Use: Appropriate size and space is provided for approach, reach, manipulation, and use regardless of user's body size, posture, or mobility.

When I first read this, I got a knot in my stomach. Adhering to these principles feels like such a high bar. But, what I have to keep reminding myself is that my default gut reaction is that of an engineer working in isolation. This is absolutely a high bar if I'm tasked with applying these principles to any and all designs that come my way.

But, that's a huge part of the mentality that this book is trying to subvert. It's not my job as an engineer to "bolt on" accessibility to any and all designs—it's the job of the entire team to first design interfaces that lend themselves to accessibility such that the design team and the engineering team are working in harmony instead of in opposition.

To me, so much of this book boils down to simplicity: what can we do in our product design, information architecture, and implementation to remove distractions and keep things as simple as possible? The more simple we keep things, the easier they are for everyone to consume. And, the easier they are to implement.

I love how the authors describe this in the book:

Overly complex designs can cause accessibility barriers—even seemingly minor issues of inefficiency or redundancy can have a substantial cumulative impact for users who have to use a system regularly or repeatedly. Complex layouts with multiple columns and sidebars and complex tables with nested header rows and expandable content make it more challenging to meet requirements for meaningful sequence and focus order. In turn, this places additional overhead on development and testing to implement designs in the most accessible way. A design focus on minimizing unnecessary complexity helps reduce overhead while also encouraging creative ways to design complex content and functionality in alternative ways. (p. 176)

This text, in particular, was a punch to the gut because I have absolutely been guilty of making overly complex data tables with expandable rows that contain a vast amount of hidden data. And, I absolutely love that they stress this a creativity problem, not a technical problem. Meaning, the "right" solution isn't to take the overly complex workflows and make them accessible—the "right" solution is to make the overly complex workflows less complex. Which will require deeper thinking about navigation and information architecture.

Which, again&mdashl;reminder to self—isn't an engineering problem on it's own—it's a holistic product design problem that the whole team needs to be focused on solving.

This book is not an easy read. A lot of it is actually quite tedious and covers many of the WCAG (Web Content Accessibility Guidelines) specifications. For example (p. 138):

1.4.12 Text Spacing (Level AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

But, the overall effect of the low-level tedium drives-home the need for simplicity and clarity. A big part of how we make our products adaptable to a wide array of needs is to keep them as simple as possible and only as complex as is necessary to provide the required functionality.

A big part of this, I suspect, is letting go of ones ego. And not worrying about how flashy your product seems at first glance. That's a tough pill to swallow; but, also somewhat of a relief.

When I was young, I felt invincible. Now, as I'm getting older, the reality of aging creeps in. My wrists hurt, my back hurts, my knees hurt. My grip strength is getting worse. I read websites at 125% zoom. I don't have the mental endurance that I once had. It's a bit devastating to watch myself slowly deteriorate; but, it's a great reminder that making things more accessible truly makes them better for everyone.

Special Shout-Out on Input Validation

I just want to specifically thank the authors for calling out the need for liberal input validation. As a consumer of many products, I find this to be one of the must infuriating and confounding issues:

For error-checking functionality, be as liberal as possible with input within the specified restrictions of the application and platform. For example, scripts that accept different forms of phone numbers, including plus, bracket, and dash characters that some people might add when writing a phone number, and then strip out those characters, are more supportive of diverse input than scripts that reject any non-numerical input. (p. 164)

I can't tell you how many times I've used a form that will reject a telephone number because it has dashes or will reject a credit card number because it contains spaces. The absurdity and the complete lack of customer empathy simply boggles the mind!

Short link: https://bennadel.com/4738