I’ve been doing accessibility work long enough that I can confidently say, you cannot avoid lawsuits about accessibility. What you can do is minimize your risk. If you do not have an accessibility effort going on in your company, start one. This guide will help you prioritize where you should be looking first. If you have a program going, this can help focus your efforts into where most lawsuits look first.
The internet today far exceeds what we initially thought it could be. We’ve advanced so far that we can replicate desktop applications running in the browser. Cloud-based software is everywhere. We’ve crafted frameworks to speed up development and solve the hard parts of server-client communication.
But the same problem keeps happening. We keep rebuilding interactive components using custom coding. And we forget all the things we need to do to make them accessible.
Today I’m looking at a why we should be using more native HTML controls and fewer custom ones. I’ll show you what is included if you use a native control.
I sat down to review some code with my colleagues. It was clear that each of these solutions was heavily over-engineered. Each used custom web components, React, Angular, or other framework, and even basic HTML with aria added. All of them should get slimmed down and work to reduce or remove ARIA.
This week I had a bunch of requests from clients surrounding VPATs and ACRs. This article will be a living article where I’ll post extra questions I receive as they come in.