A TPGi Halloween special: the horrors lurking in your HTML

It’s the time of year when many of us are spending our days pigging out on bite-sized candies and settling in for a marathon of our favorite horror films. In the spirit of a fun scare, I would like to share with you some spooky stories from my day-to-day work that happened to people just like you. These people had websites that needed an accessibility audit, which meant taking a hard look at their DOM-rendered HTML. Most of them hadn’t really looked at their DOM HTML in years. And so they didn’t know the horrors that lay beneath.

Let’s start with Hitchcock Bank¹. This bank had a page with a simple graphic of a stack of books for a purely decorative purpose. Something like this, but about 50 books large:

And yet, this simple graphic of books facing in alternate directions concealed a truly terrifying secret, which I found while I checked to see it had an appropriate alt attribute:

<img src="book.jpg" alt="">
<img src="book-reverse.jpg" alt="">
<img src="book.jpg" alt="">
<img src="book-reverse.jpg" alt="">
<img src="book.jpg" alt="">
<img src="book-reverse.jpg" alt="">
<img src="book.jpg" alt="">
<img src="book-reverse.jpg" alt="">
…etc.

There were 50 pictures of individual books that had to load every time the page loaded. And they were JPEGs, not SVGs or PNGs! But since they all had an appropriate empty alt attribute, I couldn’t write it up as a WCAG violation! Some poor engineer at Hitchcock Bank was doubtlessly pulling her hair out trying to make the page load faster with some slick JavaScript tricks but had never bothered to check her HTML.

Speaking of scary page loads, this next horror is practically ubiquitous. Most in-house websites run on a major framework like React and Angular these days, which demand engineers componentize everything to death as a best practice. One horrifyingly common result is HTML that looks like this:

<div class="skin-for-component-1">
 <div class="div-just-because">
  <div class="skin-for-component-2">
   <span class="skin-for-component-3">
    <div class="no-css-in-this-class">
     <div class="one-more-div-for-good-measure">
      <div class="what-the-dev-actually-wanted">
       Bit of text!
      </div>
     </div>
    </div>
   </span>
  </div>
 </div>
</div>

Every one of those <div>s and <span>s has to be rendered individually by the browser. Take the time to cut out or combine some of them and your page will go faster than a final girl outrunning a murder monster.

And finally, a different kind of horror: mortification. Meet the Romero Corporation. This company was started 8 years ago when it was only CEO George goofing off in his garage. But now Romero Corp. has over 100 employees and a whole page of staff bios talking about everyone’s commitment to diversity and professionalism. And yet, when Romero Corp. was audited, that home page code was mostly unchanged. And it contained comments like this:

<!--This page was written by George, a.k.a The Fart Master, who is very drunk right now.-->
<!--Also, here's a misogynist joke I thought was really funny 8 years ago!-->

Similar embarrassing things can also sometimes be found in file names:

<img src="ugly-jerk.jpg" alt="CEO George Romero">

AND IT COULD HAPPEN TO YOUUUUUUU!

Ok, scary stories over, go turn all the lights on in the house. Once you’ve finished, let’s talk about the moral here. For many of our clients, an accessibility audit is the first time they have ever closely examined their DOM-rendered HTML. I wish I could say “here’s another reason for an accessibility audit,” but in reality some accessibility engineers don’t have the background in web development required to spot shoddy HTML. When they do, it’s not their job to point it out. And so, here are my recommendations:

1. Schedule an annual HTML de-mucking. And by that I mean the HTML that actually renders in your DOM, not the .html file in your project, which can act as a hockey mask concealing terrors beneath. You might find frightful things I didn’t even mention, in which case be sure to leave a comment to give future readers a fun scare.
2. If you ever decide to get an accessibility audit, be sure to tell the company that you’d love to hear any feedback on the state of your HTML that the accessibility engineers want to give, accessibility-related or not. This also applies to UX horrors, which is a subject for another blog post.

Dawn is approaching and I need to get back in my coffin, so one final thought before I leave you. HTML tends to be the most neglected of the JavaScript-HTML-CSS triad that makes every website work, much to the consternation of accessibility engineers everywhere. Put a little elbow grease into your HTML and you’ll find your site will run quicker, debug easier, and become more accessible by virtue of simply being built well. And isn’t that what every engineer wants – to build things well?

Happy Halloween everyone!

¹Not real clients, but real stories.