IBM maintains one of the best accessibility checklists outside of the corpus of WCAG 2.0 and related documents. they’ve now updated it in anticipation of the upcoming Section 508 refresh, which is slated to happen by the end of this year. If IBM’s making huge changes to accommodate the promised upcoming refresh, that gives me a little more confidence that it will actually happen.
The IBM Web Accessibility Checklist is extremely thorough. It provides an extensive guide on using the list itself, as well as current WCAG 2.0 checks which are mapped to the upcoming 508 refresh. It also includes legacy requirements for the current version of Section 508. Yay backwards compatibility!
If you’re not comfortable with reading through WCAG 2.0 and its related documentation, a good checklist can be a great place to start. It doesn’t substitute for the guidelines themselves, (sorry, you’re going to have to bite the bullet and become familiar with them), but it can guide you through changes you may be making to your websites or web applications to ensure that the changes you make are also as inclusive as possible. A good checklist can also serve as a template if you’d like to create one for your own organization that specifically reflects your workflows and practices. If you need a guide to the basics of what should be part of any accessibility checklist you create, this post on the defensibility of accessibility checklists contains a high-evel view of what should be included.
http://www.youtube.com/watch?v=OoF8BUww3A8&list=PL5HfShxoX0vse1_Vlw5Xlu5Ob0LpO1_W6&index=6
This talk by Luis Garcia at this year’s Accessibility Camp NYC, gives a very quick crash course on some accessibility tools that web developers can use to help make the websites and web applications they’re building more accessible. The slides for Luis Garcia’s Accessibility Camp NYC talk are here, and I would encourage you to follow along with them while you’re watching the talk.
Criteria used when choosing accessibility tools
There are a few notable accessibility tools that are not discussed here. This talk focuses on tools that are free, (as in cost, not as in speech), easy to use, fairly robust, (they’ll give you actionable information on a fairly large set of possible issues), and that will allow you to do local analysis. This last criterion is crucial for developers, especially if you’re running a local development environment like Varying Vagrant Vagrants or Desktop Server.
Most of the tools discussed are not free software or open source. Very unfortunately, free software and open source haven’t eaten the accessibility world yet. Each tool has its strengths and weaknesses though, and you’ll get the most out of this talk if you pick a tool you like, and stick to using that tool, as opposed to switching back and forth between tools. It’s also helpful when testing WordPress sites that you make a note of the markup that any of these tools is flagging, as well as the CSS. Since WordPress renders pages and posts based on templates, you’ll get a lot of duplicate errors that can be fixed by modifying an underlying function, or, in the case of CSS, a particular class that targets a template tag or shortcode you’ve created.
If you haven’t incorporated an accessibility tool into your workflow yet, you should
Accessibility tools aren’t the be-all-end-all for making websites and web applications accessible. There’s still manual work that needs to be done by everybody involved in the project. But accessibility tools will help you get on the right path towards making the things you build accessible to everyone, and they will save you some time and headache down the road if you apply the information they give you while you’re working on a project, instead of going back in after everything’s shipped and trying to add the accessibility later. That’s when accessibility becomes time-consuming and in some cases, very expensive. So save yourself the extra headache and expense, and start using an accessibility tool to help you integrate accessibility into your workflow
In which I potentially piss a bunch of people off, but oh well.
As I browsed through work Twitter this morning, I came across this.
In case you don’t want to read the entire thread, or the embed gives you fits, the gist is this:
UX conference: Hey, we’d like submissions from ladies of marginalized groups.
Very polite accessibility professional: I’d love to help you out, but am unable to complete your form with a screen reader. Here’s a free alternative platform you can use.
UX conference: So sorry, maybe next time.
When pressed, the UX con asserts that, since their link has been spread so far already, and since they’re volunteers, they can’t do anything about it for now.
You had to go there, didn’t you?
I am loath to call any small outfit that doesn’t get accessibility right lazy, because I know that resources can be tight and knowledge is often limited. But this is an example of pure laziness and unwillingness to make even the slightest change. Being volunteer-driven is no excuse. The overwhelming majority of WordPress contributors are volunteers, and yet we’re working on the accessibility of our platform. Our link has been spreading for the last thirteen years, and yet we’re working on the accessibility of our platform. The problem here isn’t lack of resources, or that this UX con’s organizing team is made up of volunteers. Hell, every single WordCamp’s organizers are volunteers, and yet we somehow manage to make sure that inclusion of the groups this con is asking for submissions from, plus people with disabilities, is part and parcel of every single one of our events.
This isn’t about resources, it’s about priorities. I will be the first one to yell at accessibility folks when I believe things are going crazy. But you don’t get to trumpet your inclusion creds while blatantly excluding people with disabilities. That signals that every other effort you’re making towards inclusion of marginalized groups is a hollow one, and only serves as a cover-your-ass mechanism. It’s not like anyone’s asking for the con’s entire CMS to be rewritten. All that’s being asked is that you create an accessible form so that you can get the submissions you so desperately desire. But if you’re not willing to make your form accessible, an effort which might take you an hour tops, assuming that this is a complex form, (which it’s probably not), you might as well just say that your conference is for the privileged only. At least if you did that, no one would waste their time trying to help you out.
http://wordpress.tv/2016/08/26/trisha-salas-accessibility-tips-tricks-and-best-practices-for-plugin-developers/
This talk by Trisha Salas, who is a member of the WordPress Accessibility Team, and currently works for Modern Tribe, helping them improve the accessibility of their WordPress products and services, is an excellent starting point for anyone who wants to improve the accessibility of their WordPress plugins. Although it’s well-known in the WordPress space that themes can be improved with regard to accessibility, and that accessibility ready WordPress themes can improve the accessibility of the sites they’re used to build, WordPress plugins haven’t gotten as much accessibility love. The reasons for this are varied, and deserve a separate post of their own, but fortunately, this is starting to change.
If you haven’t tried to make your WordPress plugin accessible before, this can seem a daunting challenge. Trisha’s talk will give you some quick pointers that are easy to start implementing, as well as demonstrate how Modern Tribe is tackling the accessibility of their WordPress products.
I’m working on a site for a client that includes e-commerce functionality. Since they have to ship physical goods, and are using Stripe already, and since they don’t want to bring in another outside service that they have to pay monthly for to handle their shopping cart, I’ve selected WooCommerce as the overarching plugin to handle most of the e-commerce. Most of the e-commerce sites I’ve done over the last couple of years have included third-party shopping carts, and so WooCommarce itself hasn’t figured much in my workflow, and I was expecting this experience to contain just as much unpleasantness with regard to accessibility as it did a year ago when I last looked seriously at WooCommerce.
I am very pleasantly surprised, delighted, and pleased to report that Automattic has been working on the accessibility of WooCommerce since they first acquired WooThemes a year ago. It’s got a ways to go, (especially since Select II is involved), but there’s definite improvement here. They’re using Aria in a few cases where necessary due to some custom controls, and they’re using it properly. I believe Automattic deserves praise for this, and encouragement to keep up the good work. Making WooCommerce accessible is going to be a long, hard slog, and I’m very glad to see things heading in the right direction. So keep up the great work Automatticians, and I’ll be cheering you on every step of the way.
