Inclusive Components
Inclusive Components
Heydon Pickering
Heydon Pickering 2018. All rights reserved.
Introduction: A personal note
I am not a computer scientist.
I have no idea how to grow a computer in a test tube, or how to convert the mysterious breast-enlarging substance silicon into a semi-sentient logic machine. Or whatever it is computer scientists do.
Thats not to say I havent been around computers since, well, Lemmings. In fact, my Dad helped me build my first computer, because building computers was a thing back then. It just turns out I can use my computer without having to know the entire history of computing, or by remembering where each board and connector inside the beige metal box goes, or why. Some very clever peoplemostly womengave us computers. Good, thank you. Now lets get to work.
Me in, I dont know, 1988 probably?
Its been a good decade since anyone assumed I would know how to fix their computer just because I bought my computer before they did theirs. Which leads me to think weve moved away from that era where everyone was clumsily divided into computery and not computery. But that makes it all the more astonishing that the world of professional web development is so fond of that binary.
The ascendant Full Stack Developer is someone who does all the code things. They are codes gatekeepers. Considering the sheer scale of our project to digitize the entirety of human experience into multivarious simulacra, I think thats rather a lot for any individual to take on.
You can do all the code, but only if you dont do it all well. Theres just too much to learn to be an expert in everything. So when we hire generalist coders, we create terrible products and interfaces. The web isnt inaccessible because web accessibility is especially hard to learn, or to implement. Its inaccessible because its about the code where humans and computers meet, which is not a position most programmers care to be in, or are taught how to deal with. But theyre the coders so its their job, I guess.
Like I said, Im not a computer scientist, but I learned to code because I started to work with the web. It was my responsibility to learn how to code, because code is what the web is made of. But the code of the web is not all the code of classical computer science, and should not be judged on the same terms. HTML is the code of writers, and CSS the code of graphic designers. Writers and designers are best positioned to write those kinds of code.
This book, an anthology of updated and expanded blog posts originally written for inclusive-components.design, is designed to help you catch up on the kind of coding not taught in Java 101: the code of communication, interaction, and most of all accommodation. Theres a lot of code in this book, but its all code bent towards one specific goal: making interfaces more usable to more and different people. Thats the only code I really know.
I dedicate this book to all the artists, designers, and humanities scholars who contribute code to the web. I also dedicate it to full stack developers, because you folks may have bitten off more than you can chew. And its not your fault, its the culture of expectation around you. Hopefully this will help to keep your heads above water, at least in terms of inclusive interface design.
Thank you to all the people who have read and shared the articles from the blog, and especially to those who have helped fund its writing. Writing is my favorite thing, whether its natural language or code. Im just lucky that English is my first language, because it takes me forever to learn the syntax of anything. If you wish to translate the book, please contact me using heydon@heydonworks.com, find me on Twitter as @heydonworks , or on Mastodon as @heydon @mastodon.social .
Yours Heydon
Toggle buttons
Some things are either on or off and, when those things arent on (or off), they are invariably off (or on). The concept is so rudimentary that Ive only complicated it by trying to explain it, yet on/off switches (or toggle buttons) are not all alike. Although their purpose is simple, their applications and forms vary greatly.
In this inaugural chapter, Ill be exploring what it takes to make toggle buttons inclusive. As with any component, theres no one way to go about this, especially when such controls are examined under different contexts. However, theres certainly plenty to forget to do or to otherwise screw up, so lets try to avoid any of that.
Changing state
If a web application did not change according to the instructions of its user, the resulting experience would be altogether unsatisfactory. Nevertheless, the luxury of being able to make web documents augment themselves instantaneously, without recourse to a page refresh, has not always been present.
Unfortunately, somewhere along the way we decided that accessible web pages were only those where very little happened static documents, designed purely to be read. Accordingly, we made little effort to make the richer, stateful experiences of web applications inclusive.
A popular misconception has been that screen readers dont understand JavaScript. Not only is this entirely untrueall major screen readers react to changes in the DOM as they occurbut basic state changes, communicated both visually and to assistive technology software, do not necessarily depend on JavaScript to take place anyway.
Checkboxes and radio buttons
Form elements are the primitives of interactive web pages and, where were not employing them directly, we should be paying close attention to how they behave. Their handling of state changes have established usability conventions we would be foolish to ignore.
Arguably, an out-of-the-box input of the checkbox
type is a perfectly serviceable on/off switch all its own. Where labelled correctly, it has all the fundamental ingredients of an accessible control: its screen reader and keyboard accessible between platforms and devices, and it communicates its change of state (checked to unchecked or vice versa) without needing to rebuild the entire document.
In the following example, a checkbox serves as the toggle for an email notifications setting.
for= "notify" > Notify by email
Screen reader software is fairly uniform in its interpretation of this control. On focusing the control (moving to it using the Tab key) something similar to, Notify by email, checkbox, unchecked will be announced. Thats the label, role, and state information all present.
On checking the checkbox, most screen reader software will announce the changed state, checked (sometimes repeating the label and role information too), immediately. Without JavaScript, weve handled state and screen reader software is able to feed back to the user.
Screen readers are not just for the blind
Some operate screen readers to assist their understanding of an interface. Others may be visually dyslexic or have low literacy. There are even those who have little physical or cognitive trouble understanding an interface who simply prefer to have it read out to them sometimes.