I’ve always abided in the idea that “HTML is accessible by default and then we come along and mess it up.” In a lot places this is very true and by just using a suitable HTML element instead of a generic div or span we can have a big Accessibility impact.

But that’s not always the case. There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us. I’m trying to do the best I can, use the platform, but seems like there’s a dozen “gotchas” lurking in the shadows.

I’m going to start rounding up those HTML shortfalls in this here post as a little living document that I can personally reference every time I write some HTML.

<input type="number">
Gov.UK finds Number Inputs aren’t inclusive. (2020)

<input type="date">
Graham Armfield finds Date Inputs not ready for use. (2019)

<input type="search">
Adrian Roselli points out Search Inputs aren’t as useful as originally thought. (2019)

<select multiple>
Sarah Higley tests with actual users and finds Select Multiple has a 25.3% success rate. (2019)

<progress>
Scott O’Hara finds numerous errors with the Progress element. (2018)

<meter>
Scott O’Hara finds more numerous errors with the rare Meter element. (2018)

<dialog>
Scott O’Hara declares Dialog not ready for production. (2019)

<details><summary>
Adrian Roselli feels Details/Summary are only good in limited contexts (e.g. Details doesn’t work as an Accordion, which is what I would expect). (2019)

<video>
Scott Vinkle goes with a third-party player after seeing that the native HTML Video Player is a very inconsistent experience for screen readers. (2019)

<div onclick>
Technically this is JavaScript, but the screen reader JAWS announces “Clickable” when the element or one its ancestors have a click event handler. This is a bummer for trying to make tap areas bigger. (2018)

<div aria-label>
Paciello Group educates how aria-label, aria-labelledby , and aria-describedby only work on certain elements… and not <div> elements. It’s not very intuitive to me that aria-label would only work sometimes and it seems like something linters like axe should catch. (2017)

<a href><div>Block Links</div></a>
Adrian Roselli finds Block Links in a Card UI have usability issues. (2020)

aria-controls
The aria-controls attribute is a great way to establish a relationship between two elements and is in tons of tutorials… only one problem… Heydon Pickering points out aria-controls doesn’t do anything. (2016)

role="tablist"
After some user testing, Jeff Smith discovered the best way to make accessible tabs is to remove role="tablist", role="tab", role="tabpanel" from their tabs. FWIW, these findings were contested in a 3,900 word blog post by Léonie Watson. (2016)

Your mileage may vary, test with actual users. I’ll do my best to update this as the situation evolves glacially over the next 20 years.

Edit 2/28/2020:

  • Added the year to each link to help reflect the potential “staleness” of the information.
  • Added a note to test with actual users.
  • Added a link to Léonie Watson’s rebuttal under the tablist discussion.