A set of high-level guiding principles for approaching design and remediation for an accessible web.
- Perfection is the enemy
- By default or death
- Parity is paramount
- Design for implementation
- Structure first
- Use your words
- Tools are not identities
- Less is less
- Fishing, not fish
- No points for performance
- Help evil to fail
Nothing is—nor can be—100% accessible. Anyone who claims their offering is completely accessible is a liar, or they don't understand accessibility, or both. Usually both. It's okay to deliver inaccessible work, so long as it’s more accessible. Do what you can within the constraints given. If the constraints are unreasonable, challenge those first. You may not feel confident you are always the best person available for contributing to accessibility. The important thing is that you are available. Don’t leave the work to absent (and nonexistent) accessibility superheroes.
Accessibility fundamentally does not work as a plugin, add-on, or opt-in state. If an interface offers the option to enable accessibility, it is inaccessible. A low-contrast switch that turns on high contrast? Game over. Categorically, accessibility overlay software does not and cannot work. Adding accessibility stuff on top of inaccessible stuff does not address what needs to be addressed. The specific features offered by such third-party interlopers are immaterial. Resist the ideology of post hoc accessibility at all costs. A Minimum Viable Product (MVP) without accessibility is not—even minimally—viable.
The point is not to create a better experience, or even a good experience. It’s to ensure a comparable experience between different people. Interfaces should not be challenging to some and not to others, but some interfaces are necessarily complex and some content is inherently esoteric. You do not get to choose who is interested in—or can cope with—what. If an image serves as a joke, the alternative text should not give the joke away or explain why it is funny. It should tell the same joke by alternative means. The joke may be offensive to some or inexplicable to others. These are shortcomings of inclusivity, not accessibility.
They say form should follow function. But most organizations design first and develop second. The design phase consists of purely graphical ideation and leaves too many implementation questions unanswered. Consequently, developers are encouraged to prioritize visual approximation over usability. Drag-and-drop interfaces need to be operable by keyboard. This means buttons need to be provided. Those buttons will need to appear in the so-called design. As an accessibility practitioner, you must contribute early and at a conceptual level. Because form must follow function and the function needs to be accessible.
A poorly structured interface can technically pass WCAG. A well-structured and intuitive interface can have multiple discrete WCAG errors. Chances are, the latter is more accessible to most. Automated accessibility tools are only really good at locating discrete errors. These may be helpful diagnostically, but you need to take a holistic view. What will confuse or overwhelm people? Where will people get tripped up? Don’t waste time ticking off individual success criteria when the underlying structure needs redesigning.
A considerable proportion of web accessibility is about providing text labels. Buttons, links, and inputs must all have labels. Page titles and headings are also important types of label. Status messages are critical for labelling state. Including a label may placate an automated accessibility testing rig, but the label’s wording makes the real difference. Good writing cannot be automated. Artificial Intelligence cannot anticipate your intent. Develop your writing and editing skills or include writers and editors in your process.
Disability is no more uniform than ability. Different screen reader users use different screen reader software in different ways for different reasons in different circumstances to meet different needs and preferences. That is, if they are using screen reader software at all. There is no persona that can adequately exemplify a screen reader user or their behaviour. There is no screen reader user who speaks for screen reader users. So don’t design for screen reader users (or any other fictionalized homogenous group). Design to support the capabilites of screen reader software. People cannot—and should not—be quantified, but inputs and outputs can and are.
The mantra less is more is incorrect. Less is just less and that’s a good thing. Too much of interface engineering is done because others have done it or just to prove it can be done. Stop. The more we do, and the more complex the output becomes, the more likely it will fail. And not just by producing discrete errors and breakdowns; more importantly by resisting comprehension. Most components, in most cases, should just be content. Content should rarely be hidden behind a button. Turning headings, paragraphs, and lists into an accessible tab interface is not an enhancement. It’s a degradation with bragging rights.
Designing accessible products and interfaces starts with designing the organizations and communities that deliver them. You can deliver accessible work today but who will do it tomorrow? Who or what might undo it tomorrow? Accessible design might mean building a frontend team consisting of developers well-versed in the frontend. It might mean retiring a CMS that prohibits accessible output. It might mean briefing editorial staff in how to structure their content. If you’re fixing inaccessibility yourself, by yourself, your impact will quickly fade.
Companies tend to prioritize looking like they are addressing accessibility over actually doing it. They hire accessibility professionals and don’t give them the necessary resources. They commission research with disabled participants and refuse to interpret the feedback. They pay for audits and don’t implement the recommendations. They tell you color contrast needs to be assessed but won’t budge on any color relating to their sacred brand. If you want to make a real difference, demand praxis in place of performance.
Not everything inaccessible should be made accessible. SOme things shouldn’t exist at all. If a product or application is inherently exploitative or addictive, trades in misinformation or hatred, or just makes the world worse, do not help it to succeed or avoid litigation. Proprietors of such products do not deserve any customers or users, least of all disabled or otherwise marginalized ones (who may be disproportionately affected by their practices). Where you draw the line between acceptable and despicable is a question of personal morality. But drawing the line makes your offering as a practitioner coherent.