There is an all-in-one article including every part from this series (if you want prefer to read it all at once instead of "by installments")
We've heard many times developers say, "HTML is accessible out of the box," almost as if the definition of HTML in the dictionary was:
HTML
Accessible.
But that is not always the case. There are HTML elements that are not accessible by themselves or may present challenges to the users.
For example, elements like <video>
or <audio>
have controls that are not fully keyboard-accessible and that differ considerably from browser to browser and cause frustration. Or the <input>
element has many types that open pop-ups, which may not be accessible for everyone.
There are many components and structures that are not native HTML elements (e.g., tab panels), and once we start combining HTML, accessibility issues may pop up from the interaction.
The definition of HTML in that imaginary Hitchhiker's Guide to the (Web) Galaxy should be updated to something more appropriate:
HTML
Mostly accessible.
That looks much better, and it is definitely more accurate to reality.
Top comments (1)
Yeah, anything becomes expensive if you're rushing a half baked solution into an inflexible app that wasn't ready for it.
True for unit tests, cloud native, any architectural pattern, etc