When we use native controls for web components, instead of creating our own using Javascript or images, we confer a number of benefits to our code.
For example, we can make a button out of many different constructs: an image, a div, a span… If we use <button> all of the accessibility and browser functionality that comes with native controls will automatically be implemented for us.
If we use any other construct, we have to do the work of adding expected functionality and accessibility ourselves.
It’s worth noting that project risk and accessibility defect risk are different things. Going back to our button example, we might think, “well, this is a low-use area of the site and it doesn’t get redesigned very often… the risk of us having to change out that button’s styling regularly is pretty low, so I could go with an image straight from the designer’s prototypes instead of writing all this CSS…”
And that would be true: the project risk of having to change the button is low.
However, the end user of the page with the button might need to change that button. Maybe they need to raise or lower the contrast. Maybe they need to raise or lower the font size or overall size. Maybe they need to make it more colorblind-accessible.
If you’ve made that button out of an image, there is nothing your end user can do to solve their problem other than call and yell at you.
If you’ve made that button out of a <button> tag with appropriate CSS, the end user (or the developer of a plugin, etc.) can manipulate the display of the button so that it works for them — without calling you.
Whenever possible, use native controls.
Additional Resources
- Read “Why does it matter if our HTML is semantic?” in Frequently-Asked Questions