logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git
commit: eb4196d68c09e010a5c762b706f9184d9987da85
parent 65fcc627213fea2e408d5e6ecaaefc170ad13f6f
Author: Drew DeVault <sir@cmpwn.com>
Date:   Sun, 13 Feb 2022 11:01:41 +0100

Framing accessibility in broader terms

Diffstat:

Acontent/blog/Framing-accessibility-in-broader-terms.md117+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 117 insertions(+), 0 deletions(-)

diff --git a/content/blog/Framing-accessibility-in-broader-terms.md b/content/blog/Framing-accessibility-in-broader-terms.md @@ -0,0 +1,117 @@ +--- +title: Framing accessibility in broader terms +date: 2022-02-13 +--- + +Upon hearing the term "accessibility", many developers call to mind the HTML +<abbr title="Accessible Rich Internet Applications">ARIA</abbr> attributes and +little else. Those who have done some real accessibility work may think of the +<abbr title="Web Content Accessibility Guidelines">WCAG</abbr> guidelines. Some +FOSS developers[^1] may think of <abbr title="Assistive Technology Service +Provider Interface">AT-SPI</abbr>. The typical user of these accessibility +features is, in the minds of many naive developers, a blind person. Perhaps for +those who have worked with WCAG, a slightly more sophisticated understanding of +the audience for accessibility tools may include users with a greater variety of +vision-related problems, motor impairments, or similar needs. + +[^1]: Vanishingly few. + +Many developers[^2] frame accessibility in these terms, as a list of boxes to +tick off, or specific industry tools which, when used, magically create an +accessible product. This is not the case. In truth, a much broader understanding +of accessibility is required to create genuinely accessible software, and +because that understanding often raises uncomfortable questions about our basic +design assumptions, the industry's relationship with accessibility borders on +willful ignorance. + +[^2]: Including me, once upon a time. + +The typical developer's relationship with accessibility, if they have one at +all, is mainly concerned with making web pages work with screen readers. Even +considering this very narrow goal, most developers have an even narrower +understanding of the problem, and end up doing a piss-poor job of it. In +essence, the process of doing accessibility badly involves making a web page for +a sighted user, then using ARIA tags to hide cosmetic elements, adding alt tags, +and making other surface-level improvements for users of screen readers. If +they're serious, they may reach for the WCAG guidelines and do things like +considering contrast, font choices, and animations as well, but all framed +within the context of adding accessibility band-aids onto a UI designed for +sighted use. + +A key insight here is that these more advanced steps involve making changes +which are apparent to "typical" users as well, but we'll expand on that in a +moment. Instead of designing for people like you and then patching it up until it's +semi-functional for people who are not like you, a wise developer places +themselves into the shoes of the person they're designing for and builds +something which speaks their design language. For visually impaired users, this +might mean laying out information in a more *logical* sense than in a *spatial* +sense. + +Importantly, accessibility also means understanding that there are many other +kinds of users who have accessibility needs. + +For instance, consider someone who cannot afford a computer as nice as the one +your developers are using. When your Electron <s>crapware</s> app eats up 8G of +RAM, it may be fine on your 32G developer workstation, but not so much for +someone who cannot afford anything other than a used $50 laptop from eBay. +Waking up the user's phone every 15 minutes to check in with your servers isn't +very nice for someone using a 5-year-old phone with a dying battery. Your huge +JavaScript bundle, unoptimized images, and always-on network requirements are +not accessible to users who are on low-bandwidth mobile connections or have a +data cap&nbsp;&mdash; you're essentially charging them an extra tax to use your +website. + +Localization is another kind of accessibility, and it requires more effort than +running your strings through gettext. Users in different locales speak not only +different natural languages, but different design langauges. Users of +right-to-left languages like Arabic don't just reverse their strings but also +the entire layout of the page. Chinese and Japanese users are more familiar with +denser UIs than the typical Western user. And subtitles and transcripts are +important for Deaf users, but also useful for users who are consuming your +content in a second language. + +Intuitiveness is another important detail. Not everyone understands what your +icons mean, for a start. They may not have the motor skill to hold their mouse +over the button and read the tool-tip, either, and might not know that they can +do that in the first place! Reliance on unfamiliar design langauge in general is +a kind of inaccessible design. Remember this icon? 💾 Flashing banner ads are +also inaccessible for users with ADHD, and if we're being honest, for everyone +else, too. Software which is not responsive on many kinds of devices (touch, +mouse and keyboard, different screen sizes, aspect ratios, orientations) is not +accessible. Software which requires the latest and greatest technologies to use +(such as a modern web browser) is also not accessible. + +Adequate answers to these problems are often expensive and uncomfortable, so no +one wants to think about them. Social-media-esque designs which are deliberately +addictive are not accessible, and also not moral. The mountain of gross +abstractions on which much software is built is cheap, but causes it to suck up +all the user's resources (RAM, CPU, battery, etc) on 10-year-old +devices.[^climate] And ads are inaccessible *by design*, but good luck +explaining that to your boss. + +[^climate]: Not to mention that the model of wasteful consumerism required to + keep up with modern software is destroying the planet. + +It is a fool's errand to aim for perfect accessibility for all users, but we +need to understand that our design choices are excluding people from using our +tools. We need to design our software with accessibility in mind from the ground +up, and with a broad understanding of accessibility that acknowledges that +simple, intuitive software is the *foundation* of accessibility which works for +everyone, including you and me &mdash; and not retroactively adding half-assed +tools to fundamentally unusable software. I want UI designers to be thinking in +these terms, and less in terms of aesthetic properties, profitable designs, and +dark patterns. Design with empathy first. + +As someone who works exclusively in free software, I have to acknowledge the +fact that free software is pretty pathetic when it comes to accessibility. In +our case, this does not generally come from the perverse incentives that cause +businesses to cut costs or even deliberately undermine accessibility for +profit,[^4] but instead comes from laziness (or, more charitably, lack of free +time and enthuasiasm), and generally from free software's struggles to build +software for people who are not like its authors. I think that we can change +this. We do not have the profit motive, and we can choose to take pride in +making better software for everyone. Let's do better. + +[^4]: Though I am saddened to admit that many free software developers, after + years of exposure to these dark patterns, will often unwittingly re-implement + them in free software themselves without understanding their sinister nature.