I’m trying to be learn more about accessibility these days. Thinking about it more, reading about it some, and generally being aware as I write code what I should and shouldn’t do in that arena.
I am grateful for the folks in our community who work tirelessly to make sure that I can easily find information about it online. The A11Y Project is constantly getting updates from the community to help me understand what are best practices. I just read Heydon Pickering’s book, Apps For All: Coding Accessible Web Applications, a short, but really good book to remind me of how I should be writing HTML.
I’m also speaking up more in meetings and on my project teams. When I see something that just doesn’t quite jibe with what I’ve been learning about accessibility, I bring it up. I also ask trusted friends about it too, to make sure I’m not crazy, but that it’s actually a best practice; because it matters. Sometimes the little things, such as removing an outline on focus or using empty links instead of button, are the things that can add up to a bad experience for people using the site with a keyboard or screenreader.
Unfortunately, sometimes I get pushback—especially when working on a minimum viable product or a quick project. There is always the answer of, “we’ll fix it later.” But will you? I’ve been working on applications and projects long enough to see that going back to refactor can be even tougher to make time for.
I try, when getting that pushback, to remind people of the fact that it’s hard to make the time for code refactors. Taking a little bit of time to do things right the first time around saves time in the long run. Eventually, I usually share the consequences some companies have faced when they don’t take accessibility seriously. I don’t always win the battles, but often reminding colleagues that there will be a wide range of people using the site—some of whom may not use it exactly as we do—is worth it. Hopefully, next time they’ll be more willing to take the time necessary up front.
I know this has been said before, but as I’ve started reading more and more on accessibility and trying to learn more about it, I’ve found it to be rewarding. Working on a project where all users can access and use it well, that’s satisfying. One of my most satisfying moments professionally was hearing from a blind user who was thankful they were able to use our app. And if you don’t think about accessibility, well, that can just lead to a world of hurt.
Great article, I’ve been adding accessibility guidelines piece by piece to my projects, I didn’t have any feedback yet, but I’m pretty sure it worths the extra time/effort.
Susan, a really refreshing article. Your story rings true for many (including myself). Things are improving everyday! I can recommend another really good read, A Web For Everyone by Sarah Horton and Whitney Quesenbery (Rosenfeld). It is a beautiful book and very accessible. I’ll be checking out Apps for All. Thanks so much for sharing.
Really important stuff – accessibility really should be mainstreamed.
Good article, thanks Susan. I make a regular effort to make sure that the code I write is accessible and usually have the leisure of time to do that before it gets launched, but even so, once I go beyond tidy html and into the world of ARIA, things can get confusing pretty quickly.
Thanks for the recommended book and to Taliesin for the other recommendation too, it’ll be good to start the new year with those.
Good article, Susan. I was fortunate to have over two years experience at the American Chemical Society, whose Board made it a requirement to develop to WCAG 2.0 during our re-platforming of acs.org on Adobe AEM. It was interesting to see it as a cultural awareness awakening at ACS for the Product Owners and the Scrum team as they became proponents in their own right.
The positive by-product for the developers and testers was building on that knowledge and skill set. However, something to remember is that the content is as important as the code going forward, so there are usually a lot of contributors who need to deliver optimized work to keep the site friendly.
There are plenty of free tools out there for accessing sites. It’s great to sit down with someone from your team and be able to show them explicitly where and what the shortcomings are for compliance on your own site. There might even be small content changes (alt text, video subtitles and transcipts, for example) that can help right away.
Kudos to everyone who works toward this goal.
“There is always the answer of, “we’ll fix it later.” But will you?”
From my experience the fix will never come, and not because of bad intentions, mostly, but because people forget about it. At least they should note this somewhere, and when the opportunity arrives, they can really fix it.
I’ve been thinking a lot about accessibility recently too, I find it a little confusing at times though.
Does anyone know of a good accessibility scanner which can help with tidying things up or a standard accessibility checklist?
Hey Rob,
A great place to start is http://webaim.org/.
They have nice tools like WAVE (http://wave.webaim.org/) that can flag a web page for issues in accessibility. I also use their contrast checker quite a bit (http://webaim.org/resources/contrastchecker/).
Another place to check is WCAG (http://www.w3.org/WAI/intro/wcag) which has a checklist, but again, WebAIM has a great page that makes each guideline clearer (http://webaim.org/standards/wcag/checklist).
There are so many resources online, but these basics will get you started!
-Holly
Nice Blog I will recomend this site to my friends! Thanks for all of these informations!