I call myself an accessibility consultant when I’m not building WordPress plug-ins. But in all reality, you should stop hiring accessibility consultants. The work is awful, and nobody wants to do it.
Seriously – the work is awful. I mean that. Building accessible web sites and applications? That’s awesome. Training you and your team on what’s involved in creating an accessible resource? Also awesome. Creating tools that help you identify or fix accessibility issues? Really, seriously awesome.
Diving into that godawful website that you need to get rebuilt in the next six months because you’re being sued? No, that’s really not much fun.
— david sloan (@sloandr) January 13, 2016
David Sloan observed that the profile of accessibility is an exercise in evaluation and repair. That’s sadly true – and is one of the main reasons that accessibility struggles. When your primary role is to come in and tell people what they’ve done wrong, you’re always going to be viewed to some degree as the villain. It doesn’t matter how nicely you put it – you’re ultimately telling somebody that they did this wrong, and they have to fix it.
(Reading the whole thread referenced in that Tweet is worth while. Only takes a minute; I’ll still be here.)
Isn’t it much better to be taught how to create an accessible web site early on? Education and training are the only really meaningful routes to improving the overall picture of web accessibility in the world.
There will always be a need for accessibility evaluation tools, automated testing, and specialist consultants. It’s not reasonable to expect everybody who develops web sites to be an expert in the concerns of all types of disabilities and assistive technology. What it is reasonable to expect is that a web developer is an expert at using HTML (HyperText Markup Language) – and if we’re going to be absolutely honest, 95% of problems with web sites come from improper use of HTML.
Using practical and semantic HTML answers a huge percentage of accessibility issues.
Today, I was reviewing a web site and I saw a toggle that expanded a search form. The toggle used the ARIA attribute “haspopup”.
However, the toggle was built using an
a element, and didn’t include an
href attribute. As a result, it really didn’t matter that the developer added ARIA – this control isn’t natively keyboard accessible.
That’s a misunderstanding of what the native focusable elements are in HTML. The native focusable elements are buttons, inputs (of all types), and links. Links. Not the
a element, but links. The only difference is in the presence of an
href attribute. If the
a element has a hyperlink reference, then it’s a link. If it doesn’t, it’s an anchor, and doesn’t receive focus in the tab order.
Do you build web sites?If so, you should have already known that, and you shouldn’t need an accessibility consultant to tell you.
Are you looking to build a web site? Don’t look for a web accessibility consultant to review the site. Find a web accessibility trainer to teach your web developer about accessibility best practices.