larlet-fr-david-cache/cache/2020/a70068c881eba36604b2f4f8aec54670/index.md

title: HTML: The Inaccessible Parts url: https://daverupert.com/2020/02/html-the-inaccessible-parts/ hash_url: a70068c881

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.