Category: Helpful resources

Criteria used when choosing accessibility tools

By: Geoff Stearns – CC BY 2.0

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

As with everything else, there’s a plugin for that

With the Disable Blogging plugin, you now have the ability to disable all of WordPress’s blogging features non-destructively. This means that, if down the line you decide you want to add a blog to your site after you’ve disabled all the blogging features, you can do so by simply deactivating the plugin.

What features does it disable?

The plugin disables the following features by hiding them as long as it’s active.

• • Posts and everything related to them
• Comments and everything related to them
• Comments from pages
• Blog related widgets
• Pingbacks, Trackbacks, and XML-RPC header links
• Biographical info and Admin Color schemes on the user profile page
• Press This Bookmarklet
• Posts via email
• Howdy, help tabs, and query strings from static resources

Think of this as the nuclear option if you want to do away with blogging on your site completely.

There are two things that immediately stand out during testing. The first is that logging in takes users to their profile page instead of the Dashboard. Second, the Dashboard and the link to it are gone. If you’re used to seeing the WordPress dashboard, running WordPress with it disabled can be a jarring experience, and, if you use this on a client’s site, and you’ve shown them how to update the site before adding this plugin, you’ll want to explain to them what they should expect before you enable this.

The WordPress dashboard serves a useful purpose, especially on sites where you need to quickly glance at things like e-commerce data, so I would only recommend using this in situations where your client isn’t depending on getting easy access to their data snapshots. It’s not that it’s not possible for them to navigate to the various sections of the administration panel to find their various stats, but it can be seen to add a layer of complexity.

If you’re looking for some user testing data before you make the leap, check out Jeff’s post on WordPress Tavern to get a sense of what it might be like to activate this plugin on your site.

All of this notwithstanding, if you know that, (at least for now), you don’t want a blog on your site, this is a good option that allows you to disable it until it’s needed.

Luckily, as long as you’re using Firefox or Chrome, (sorry Internet Explorer users, no help for you), There’s a solution for this problem.

Enter Greasemonkey

Greasemonkey,(and its Chrome equivalent, Tampermonkey), allows you to run user-created scripts in your browser so that you can change the way a website behaves. This includes making it more accessible.

[Tweet “Greasemonkey is like Smart Web except you don’t have to pay for an SMA to get access.”]

Wait, are you saying website creators don’t have to make their sites accessible?

Absolutely not. What I am saying is that when you have no control over whether or not a website like GitHub is accessible, and you have no choice but to use said website, Greasemonkey is the next best option.

Installing Greasemonkey

To install Greasemonkey, navigate to the tools menu by pressing alt+t. Then, arrow down to addons. Alternatively, you can press ctrl+shift+a to open the addons manager. Next,tab to the list view and make sure “get add-ons” is selected. After this,tab to the edit field type “Greasemonkey” in the field and press enter.

Once you press enter, you can either tab to the list of add-ons and select the one you want to install, or tab through the sort buttons and sort the results accordingly. Once you’re in the list of add-ons, arrow to the one you want to install and then tab to the “install” button and press enter or space.

You’ll need to restart Firefox for the Greasemonkey add-on to take effect. You can restart when prompted or restart later.

Make GitHub more accessible

Once you’ve installed Greasemonkey, install the Greasemonkey script for GitHub by Jamie Teh of NVDA fame. As long as you have Greasemonkey installed, you can press enter on the link to the GitHub repository and Greasemonkey will happily install it. It will ask you if you’re sure, warn you about how user scripts can do bad things, but this one’s fine so go ahead and install it.

The GitHub site is magically a lot less painful

Once you have this script installed, the GitHub website becomes a lot easier to use with a screen reader. This is a tool you definitely have to have in your toolkit if you’re doing anything with GitHub, regardless of whether or not you’re using it to host your own repositories. If it makes your life easier, consider a donation to NVAccess.

This talk by Rachel Carden at this year’s WordCamp Miami. Click here to view the presentation slides. If you’re using a screen reader to view the slides, navigate to the title of the talk at heading level three and read from there.

Léonie Watson has posted a very well-written article explaining what “semantic” means in the context of the web, along with some demonstrations. It’s worth a read for anyone who’s making things on the web, (including people who don’t consider themselves developers), and it can serve as a quick reference to file away for later when you’re in the middle of building and you need a reference.

Back in the bad old days, before the WordPress Accessibility Team really got off the ground and came into its own as a well-loved and respected part of the WordPress project, I used to see a lot of claims from theme vendors, page builder vendors, and plugin authors, (both free and premium), that their products were accessible, or sec. 508 compliant, or the like. Thanks to the work of the accessibility team, and its individual members, that is no longer the case. Not only are plugin and theme authors less likely to declare their products accessible without asking someone to check it, (or paying for work in some cases to ensure that their products are in fact accessible), the term accessible has been more or less swopped out for accessibility-ready, meaning that you can create an accessible site with it, but there’s also room to make your site less accessible by not following the author’s recommendations for settings. All of this makes me very proud. We’re making progress towards full inclusion for everybody, regardless of ability or language spoken, and we’re also making sure we point out where we still have room to grow.

Some of Adrian’s techniques from the linked post above will work in this ecosystem, and some won’t. But either way, this is a great roadmap for users who are either downloading or purchasing premium products to test claims of accessibility if any are made. The testing technique, and the filing issues technique, are also great ways for users or other developers to help the process of “make accessible all the things” move forward. Just make sure you’re polite and respectful when filing reports. The difference here, as with other open source projects, is that the majority of the time, these developers are putting their free time into these projects, and do not have dollars to spend on proper accessibility consulting or remediation.