I have been asked on many occasions to explain why their beautifully looking custom-made HTML control is not accessible, therefore have decided to put this in a blog post, so many more people can benefit from my explanation.
Note: This article is intended to introduce you to the concept that native HTML controls include a ‘hidden’ accessibility component to them. It is not a comprehensive overview of what accessibility enhancements are included in native HTML controls.
What is a native HTML control
A native HTML control is a control that has been defined in the HTML specification such as a Button. And by defined, I mean, the specification defines all the interactive aspects and use case scenarios of the control which also covers accessibility. Therefore, by using a native HTML control, you’ve already got accessibility covered.
Let’s look at a simple example – a Button. This will give you a better understanding of the impact of using a custom-made control versus a native HTML control on accessibility.
Note: example assumes ARIA has not been used, only styling the elements to look like a button.
Below are a few ways you can go about marking up a Button:
<button>I'm a button</button> <input type="button" value="I'm a button" /> <span>I'm a button</span> <div>I'm a button</div> <img src="/images/im-a-button.gif" /> <a>I'm a button</a>
Now let’s analyse the impact of each markup approach.
<input type="button" /> being native HTML markup for a Button, have all the ‘hidden’ accessibility benefits included. Only difference is that, it’s a lot easier to read/identify the button when working with the page’s markup/code.
<div> being generic HTML content holding elements, they do not include any of the ‘hidden’ accessibility benefits. To user agents and ATs, all they see is just the text within the tags. Thus treats the ‘visually looking’ Button as plain text and hence is inaccessible.
<img src="/images/im-a-button.gif" /> and
<a> being native HTML markup for an image and an anchor (link) respectively; they include ‘hidden’ accessibility information that corresponds to their native HTML role and not that of a Button control, thus greatly affects accessibility for all users.
Note: You can resolve all these issues using ARIA, but that’s beyond the scope of this blog post.
Now you understand the impact of using custom-made HTML controls on accessibility, I hope you will prioritise using native HTML controls first before venturing off to create your own custom control.
If you have a need to create your own custom control/widget or use web components, you may like to take a look at HTML5 Accessibility Chops: Just use a (native HTML) button by Steve Faulkner and my articles: HTML Semantics and Accessibility and Introduction to understanding WAI-ARIA 1.0 Roles.