as days pass by

Bruce Lawson has written a rather nice description of the practical value of semantic HTML, and you should read it, especially if you’re a full-stack developer who feels that HTML is the super-easy part of your toolkit and the components are the most important. But there’s one extra argument I’d like to add to his list; less important than some of the others, but a different nuance.

Sometimes, when I find myself doing a bit of extra work to accommodate some users with unusual requirements, I find myself thinking: why isn’t it their job to fix this, rather than mine? This is an unworthy thought, and I don’t like that I have it, and I don’t respond to this thought; doing the right thing so all my users can use my stuff is important. But I do have the thought, nonetheless. Whether I’m adding aria labels for screenreaders, or doing extra work to build sites that layer behaviour on top as additional rather than critical, or checking text contrast ratios, or testing on unusual mobile phones I don’t and won’t have, there’s a sneaky little bit of my brain saying “why is this my problem? if someone wants to buy a weird phone, it’s their problem that websites don’t work right, isn’t it?”

Leave aside here, for now, that there is no such thing as a “normal” experience, and even saying that people differ from the “normal” experience means that you are thinking about things the wrong way because you’re assuming that there is a normality and then there’s divergence and that’s wrong. I know this. You know this too, or at least should.

Here’s the secret. Someone who has a web experience different from what the industry perceives as the norm is normally actually pretty happy to try, for themselves, to make their web experience better. Someone with poor motor control generally will be happy to learn the keyboard shortcuts for their browser, which the “norm” don’t bother to do. Someone who listens to the web rather than reads it generally will be happy to learn how to skip over your header using an option available in their tool but not yours, so you don’t have to add “skip header” links. Someone who is desperate for all bold text to appear in bright green and with sparkles generally will be happy to learn how to customise their user stylesheet to make that happen.

The secret is: if you use semantic HTML, then they do the work, not you. Their browser does the work, not you. If your pages use semantic HTML, you’re not going to get bug reports saying that your web app doesn’t work in a screenreader, or your buttons don’t work without mouse clicks, or your site doesn’t show anything on a Yoyodyne SuperPhone 3 running FailBrowser, because it will and they will and it will. And using semantic HTML elements is no more effort; it’s just as easy to use <main> as it is to use <div id="main">. Easier, even. You get to offload some of that work onto the people who need it, and they are happy to do it, as long as you aren’t actively working to stop them.