Interview with Heydon Pickering: Inclusive design thinking: Embedding accessibility into the design process

Heydon Pickering – Designer and author

About Heydon

Last year, Léonie Watson stated «So accessibility is probably in a holding pattern for the time-being. It could be worse, but it could also be better, and as designers and developers we’re working hard to make that happen». What is the current state of accessibility on the web? Did we work hard enough to make it happen?

Léonie may not know it, but she was instrumental in getting me enthused about tackling the accessibility of modern web applications. As a front-end developer, I was working on an app running on an early version of Angular. I was determined to make this curious, idiosyncratic web page thing (with views and hijacked links etc.) to work for screen reader and keyboard users.

I tried some weird stuff with focus management between views and WAI-ARIA live regions. Then I reach out to Léonie and she tested it for me. To my surprise and excitement, she was able to report that the content and functionality were accessible as I’d intended. That experience led me to write Apps For All for Smashing Magazine.

I agree that accessibility is somewhat in a holding pattern — at least in the sense that there’s such an emphasis on remediation rather than design. Our industry has a funny habit of compartmentalizing design and development. Accessibility is then treated as a kind of third wheel. What we (and by ‘we’ I mean anyone with a design/development background who’s sick of fixing applications for accessibility after the fact) are all trying to move towards is embedding accessibility and, more broadly, inclusive design thinking into the design process.

For that to work, we also need to accept that development and design are not different disciplines themselves. Design is thinking and development is doing. Inclusive design means thinking about Web users — of which there is a huge diversity in terms of abilities and preferences — and developing solutions to accommodate as many of them as we can.

Are we working hard enough? I don’t know. What we need to do is work smarter. Remediation is REALLY hard work, because it’s fixing what’s broken. It’s actually easier (and cheaper!) just to design with different needs in mind from the outset. That’s what I’m working on teaching folks who design interfaces.

Where do you see the biggest potential in improving accessibility on the web?

New Web technologies often offer both opportunities and challenges for web accessibility.

Web Components are a good example. The Custom Elements spec’ allows you to create new elements. Where these replace existing semantic elements, you lose all the standard behaviors that went with those elements: essentially, <my-button> is just <div> unless you intervene and add a WAI-ARIA button role, tabindex=”0″ and support for keyboard activation with Enter and Space. However, if you extend the accessible HTMLButtonElement prototype and add new behaviors — such as a toggle state using aria-pressed — wrapping this functionality up in <my-button> makes it much easier to include the toggle in an interface without having to worry about adding accessible state support separately. In other words, it makes it easier to author an accessible interface with rich semantics and behavior.

More important than discrete technological innovations is the mindset with which we approach accessibility. The biggest potential of all, I believe, is to be found in moving tentatively away from accessibility compliance and towards accessible UX. The former is a lawyer appeasing, box ticking exercise and can result in technically accessible interfaces which few people are able to (or want to) use. The later appreciates that everyone needs a usable interface, but acknowledges that different people use interfaces in different ways.

Some people use interfaces with a screen reader, or a bluetooth keyboard, on a train with a poor network connection, or pinching the screen liberally to zoom in and out. With a potentially vast audience offered by the Web, differences in ability, education, preference and circumstance are legion. The key change in mindset is to want to embrace flexibility and user control. There’s no one experience to be had; there are many. This often means doing little, or not undoing what devices and browsers offer as options and settings.

What is the role of server-side rendering with regards to accessibility? And will we see an increased adoption of universal/isomorphic applications?

When we talk about accessibility, primarily we’re in the realm of disability — ensuring access for people with disabilities. Some have moved to saying accessibility means access for ‘everyone’. I’m not willing to embrace this, because it’s essentially the “#AllLivesMatter” of interface design. There should be an emphasis on disability because it is something that folks simply can’t help. Supporting a disability is more important than supporting a browser.

In the case of server-side rendering, there is a robustness and performance that improves access to everyone — although, more so to people on poor networks. I hope we see more of this, although I think isomorphism is a very complex way to achieve what progressive enhancement can do in its place, in many cases.

Because server-side rendering improves access, you could call this architectural soundness an accessibility provision, but I prefer to preserve this term. When addressing approaches to design that take in reliability and performance as well as disability support, I use the broader term “inclusive design”. My new book, Inclusive Design Patterns (https://www.smashingmagazine.com/2016/06/inclusive-design-patterns/) therefore talks about everything from keyboard accessibility and color contrast, to non-blocking assets and responsive images. It also highlights the multitude of techniques that, by supporting discrete disabilities, can make sites more usable to a number of other users. Alternative text, for example, means there is a visible description of an image if and when it fails to load.