davidbgk
/
larlet-fr-david-cache

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

<p>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 <code>div</code> or <code>span</code> we can have a big Accessibility impact.</p>
<p>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.</p>
<p>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.</p>
<hr/>
<p><code>&lt;input type="number"&gt;</code><br/>
Gov.UK finds <a href="https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/">Number Inputs aren’t inclusive</a>. (2020)</p>
<p><code>&lt;input type="date"&gt;</code><br/>
Graham Armfield finds <a href="https://www.hassellinclusion.com/blog/input-type-date-ready-for-use/">Date Inputs not ready for use</a>. (2019)</p>
<p><code>&lt;input type="search"&gt;</code><br/>
Adrian Roselli points out <a href="https://adrianroselli.com/2019/07/ignore-typesearch.html">Search Inputs aren’t as useful as originally thought</a>. (2019)</p>
<p><code>&lt;select multiple&gt;</code><br/>
Sarah Higley tests with actual users and finds <a href="https://www.24a11y.com/2019/select-your-poison-part-2/">Select Multiple has a 25.3% success rate</a>. (2019)</p>
<p><code>&lt;progress&gt;</code><br/>
Scott O’Hara finds <a href="https://scottaohara.github.io/a11y_styled_form_controls/src/progress-bar/">numerous errors with the Progress element</a>. (2018)</p>
<p><code>&lt;meter&gt;</code><br/>
Scott O’Hara finds <a href="https://scottaohara.github.io/a11y_styled_form_controls/src/meter/">more numerous errors with the rare Meter element</a>. (2018)</p>
<p><code>&lt;dialog&gt;</code><br/>
Scott O’Hara declares <a href="https://www.scottohara.me/blog/2019/03/05/open-dialog.html">Dialog not ready for production</a>. (2019)</p>
<p><code>&lt;details&gt;&lt;summary&gt;</code><br/>
Adrian Roselli feels <a href="https://adrianroselli.com/2019/04/details-summary-are-not-insert-control-here.html">Details/Summary are only good in limited contexts</a> (e.g. <a href="https://daverupert.com/2019/12/why-details-is-not-an-accordion/">Details doesn’t work as an Accordion</a>, which is what I would expect). (2019)</p>
<p><code>&lt;video&gt;</code><br/>
Scott Vinkle goes with a third-party player after seeing that <a href="https://scottvinkle.me/blogs/blog/how-accessible-is-the-html-video-player">the native HTML Video Player is a very inconsistent experience for screen readers</a>. (2019)</p>
<p><code>&lt;div onclick&gt;</code><br/>
Technically this is JavaScript, but the screen reader <a href="https://github.com/carbon-design-system/carbon/issues/986#issuecomment-412968245">JAWS announces “Clickable” when the element or one its ancestors have a click event handler</a>. This is a bummer for trying to make tap areas bigger. (2018)</p>
<p><code>&lt;div aria-label&gt;</code><br/>
Paciello Group educates how <a href="https://developer.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/"><code>aria-label</code>, <code>aria-labelledby</code> , and <code>aria-describedby</code> only work on certain elements… and not <code>&lt;div&gt;</code> elements</a>. It’s not very intuitive to me that <code>aria-label</code> would only work <em>sometimes</em> and it seems like something linters like <a href="https://www.deque.com/axe/">axe</a> should catch. (2017)</p>
<p><code>&lt;a href&gt;&lt;div&gt;Block Links&lt;/div&gt;&lt;/a&gt;</code><br/>
Adrian Roselli finds <a href="https://adrianroselli.com/2020/02/block-links-cards-clickable-regions-etc.html">Block Links in a Card UI have usability issues</a>. (2020)</p>
<p><code>aria-controls</code><br/>
The <code>aria-controls</code> 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 <a href="https://heydonworks.com/article/aria-controls-is-poop/"><code>aria-controls</code> doesn’t do anything</a>. (2016)</p>
<p><code>role="tablist"</code><br/>
After some user testing, Jeff Smith discovered <a href="http://simplyaccessible.com/article/danger-aria-tabs/">the best way to make accessible tabs is to remove <code>role="tablist"</code>, <code>role="tab"</code>, <code>role="tabpanel"</code> from their tabs</a>. FWIW, these <a href="https://medium.theuxblog.com/danger-testing-accessibility-with-real-people-4515f72db648">findings were contested in a 3,900 word blog post by Léonie Watson</a>. (2016)</p>
<hr/>
<p>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.</p>
<p><em>Edit 2/28/2020:</em></p>
<ul>
<li>Added the year to each link to help reflect the potential “staleness” of the information.</li>
<li>Added a note to test with actual users.</li>
<li>Added a link to Léonie Watson’s rebuttal under the <code>tablist</code> discussion.</li>
</ul>