Chapter 9 of 15

Accessibility

Not optional, not charity: mandatory

Accessibility is not optional. It’s not a nice-to-have. It’s an engineering requirement. It’s generally understood as making your website accessible to people with recognized disabilities: vision, hearing, motor or cognitive. But in reality accessibility is something everybody needs, at least some of the time.

The numbers

Something like 3.4% of all users on the web have limited vision of some kind. They’re not all completely blind — lots of people just need high contrast, really big fonts, or accommodations for dyslexia. Then there are people who are color blind, people with motor control difficulties, people with unusual screen sizes, and people with no screen at all — using screen readers or Braille displays.

Add it all up, and something like 10% of your audience has some kind of accessibility need. Throwing away 10% of your revenue because you were too lazy to add accessibility to your website is a terrible reason to lose money.

Use the platform

The best way to accommodate accessibility is to use browser-built controls as often as you possibly can.

Browsers have form controls: buttons, dropdowns, radio buttons, checkboxes, text inputs. You could replicate all of that functionality using a pile of <div> tags and JavaScript. It’s often easier to style divs than native controls. But you shouldn’t, because non-visual browsers know what native controls mean.

If you’re trying to select from multiple options using an audio browser, it knows that a <select> element has eight options and lets the user choose between them. If you’ve built a fake dropdown out of divs and JavaScript, the audio browser sees… a bunch of divs with some JavaScript it doesn’t understand. That user can’t buy your stuff.

Use <button> for buttons. Use <select> for dropdowns. Use <input> for inputs. Use <a> for links. Use semantic HTML elements for what they’re designed for. The browser, the screen reader, the Braille display — they all know what to do with those elements. They have no idea what to do with a <div> that has a click handler.

Accessibility is baked in, not bolted on

Like security, accessibility is something you build in from the beginning. If you write semantic HTML, use native controls, provide alt text for images, ensure sufficient color contrast, and make sure everything is keyboard-navigable, you’ve already done most of the work. Accessibility isn’t a separate project — it’s the natural result of building things properly.

The good news here, once again, is that agents know all the rules about accessibility. All you have to do is tell them you value it, and they’ll build it right in! A 10% audience gain for doing nothing more than giving a shit.

We’ve now covered most of the front-end, so let’s move down the stack to databases.