Halvor William Sanden

Programming unique accessibility

Arguing against accessibility isn’t only about the inability to see things from the perspective of others. It might also come from mistaking universal accessibility for tailoring, thinking the interface will be less convenient or harder to use for some.

A car might be custom-built for one person, which is OK since it is that person’s car, compared to public transport intended for everyone. On the one hand, enabling is done through tailoring; on the other, it’s universal design.

While vehicles and web interfaces aren’t remotely the same, they are both for an unknown variety of people. We can’t claim to know the situation of our users.

A luxury to work with #

Making interfaces is an easier task to have than building things like entrances, trains and houses. Physical constructions are fixed; they reach a level of completeness and are time-consuming to change. And they are the same for everyone unless we construct designated versions or areas.

HTML and CSS interfaces don’t work like that, and analogies to interior or architecture fall flat. A room will always be a compromise for the different needs it is supposed to cover. The ramp to get into the apartment doesn’t change to steps depending on the person entering. The shower chair doesn’t appear depending on a person’s age, number of legs or hours of sleep. But the browser-based interface can change based on the user.

Personal, not visual #

An interface is not made and then distributed; it only exists when rendered and used – which is why sketches always fall short. We don’t build interfaces with a specific visual goal, but with user purpose in mind, ideally programmed to work with every user’s needs.

Making accessible interfaces requires approaching them as sets of instructions programmed to run in browsers for predictable but uncontrollable outcomes that belong to the user more than ourselves.

A representation generated with default settings is no more official or correct. Font size 200 %, different screen sizes, keyboard navigation or extra contrast aren’t additional features; they are part of the nature of the interface. If we build it right, it’s just there.

Usability for more #

Accessible interfaces aren’t necessarily about disability. Some even don’t like the label, and that’s understandable. We are not our body parts, abilities or current situation. Interfaces respect that by having the ability to adhere to the settings and technology of the users.

Accessibility is usability for more people without negatively affecting any other users. The programming that goes into making an interface usable for people with one type of disability is, in many cases, the same programming that goes into making it for a power user. Work done with accessibility in mind is indistinguishable from usability work.

Always do better #

We tend not to notice the things we don’t need ourselves, making it essential for those that make interfaces to know beyond their own experience.

If older people are disabled, then kids are also disabled. For most of them, things like cognitive abilities, eyesight, and motor skills aren’t in peak condition. The point isn’t that there are no disabilities, but that we can’t build the world for healthy people, around 175 cm tall, with a shoulder-width of 50 cm and perfect eyesight, and slap adjustments on top of someone’s ultimate interface vision. Interfaces like that don’t exist because that’s not what interfaces are.

The more we program for accessibility, the better the interface becomes for everyone. Continuously trying to do better, makes us better at making interfaces because we unlock the unique properties that they have.