Principles Of Web Accessibility

A set of high-level guiding principles for approaching web accessibility.

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
Get paid
Fishing, not fish
No points for performance
Let evil rot

Perfection is the enemy

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 to work on accessibility. But you are available. Don’t leave the work to absent (and nonexistent) accessibility superheroes.

By default or death

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.

Parity is paramount

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.

Design for implementation

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 must be accessible.

Structure first

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 the more accessible interface to most. Automated accessibility tools are only really good at locating discrete errors. While these may be helpful diagnostically, you will 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 rethinking.

Use your words

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.

Tools are not identities

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 all 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.

Less is less

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.

Get paid

Don’t let your enthusiasm for accessibility work be exploited. Like any work, the more people do it for free, the less it is valued. Accessibility work is not an optional extra, a hobby, or a kindness. It is a foundational part of sound interface design. If you are paid to work and you work on accessibility, it should be defined as part of your role. Accessibility work must be compensated and rewarded like any other work. Where “accessibility is everyone’s job”, it’s often nobody’s. Beware of that rhetoric.

Fishing, not fish

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 replacing 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.

No points for performance

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.

Let evil rot

You will have opportunities to work on products that are inherently exploitative and addictive, trade in hatred or misinformation, or just make the world worse. These kinds of products, and the psychopathic enterprises that beget them, are extremely resistant to reform, no matter what they might tell you. Don’t martyr yourself trying to redeem the irredeemable. Don’t make their failure your own. Protect your reputation and mental health. There’s a lot of inaccessibility out there. Prioritize working with receptive people, on the kinds of products that deserve to exist in the first place.

License

Heydon/principles-of-web-accessibility

ErrorLooks like something went wrong!

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Contributors 9

Error
Looks like something went wrong!

Packages