Mike Cherim and Jonathan Fenocchi, creators of the GrayBit service for showing a site design converted into grayscale, needed to move on. The time and expense of maintaining GrayBit was too much – and since Mike Cherim has moved out of the web development and accessibility world, it was necessary to make some changes. They recently shut down GrayBit.com, not having received any word that anybody wanted to take the site over.

I was too late to save the domain, which is now a travel magazine, but I have saved the service: GrayBit can now be found at http://gray-bit.com. I just did the move this morning, in about an hour, so there may be issues still to be seen – let me know if you encounter any problems!

For now, I’ve moved the service from being advertising supported to being donation supported; so, if you’re a supporter of GrayBit — please consider making a donation! I don’t know yet just what this service might end up costing me…

It’s official – I’ll be speaking at WordCamp Minneapolis 2013 on April 27th, talking about WordPress and Accessibility. Speaking locally is pretty rare for me, so I’m really looking forward to meeting some other local WordPress people at the event. Oh, and the learning. That, too.

The official description of my talk, in the ‘Continuing Education’ track, is:

Covers a wide range of accessibility topics including but not limited to implementing best practice accessibility in theme building, discussing current progress and goals from the WordPress Accessibility P2 group, and address general principles of accessibility that might be of interest to WP developers and designers.

The organizers of the WordCamp are still setting up their speaker matrix, so I don’t yet know yet what my target audience will be — so this is a good time to think about who wants to learn!

Integrating Accessibility with WordPress is a broad topic — and the description reflects it. Are you attending WordCamp Minneapolis (just say yes) and have something you really want to know? Let me know in the comments or via Twitter! I’m listening!

WordCamp Minneapolis 2013
April 27th
Minneapolis Community & Technical College
1501 Hennepin Ave,
Minneapolis, MN 55403

After a trip to a great accessibility conference like CSUN, I inevitably end up with massive lists of great ideas for things I could work on to promote and improve accessibility.

It is equally inevitable that I will forget some of these and fail to complete others — but documentation helps.

Coming out of the conference, here are a few of the great ideas I’ve talked about with other people here or just had pop into my brain without warning.

• Incorporate the QUAIL project for dynamically detecting accessibility issues into my WP accessibility plug-in.
• Develop a WordPress plug-in for using the new WAVE5 API to generate statistics and analysis of WordPress site accessibility.
• Establish a blueprint-like language for designing wireframes and web design proofs that include accessibility information that is not visibly part of the design. Came out of a conversation with Mike Guill on the problem with developers who only build what’s shown on the wireframe/proof.
• Finish my already 75% written accessible video management plug-in for WordPress
• Finally learn more about working with others* through Github or Bitbucket so that I can take advantage of others expertise to improve my accessibility projects.

There’s a good probability that there are other things I’ve thought about this week that aren’t in here. Most likely, I’ve already forgotten them, and will think of them again next year…

“Works well with others” was not a comment my elementary school teachers ever wrote on my report cards.

Whenever I update an application on my iOS or Android devices, I feel a certain nervousness about whether the learning I’ve put into the current app will go out the window. The same is true about any software: is my user interface learning going to become obsolete with this update?

When it comes to major software, like moving to Windows 8, you must expect major updates. But it can be maddening to update an app you’re working with on daily basis — and find that the new version is radically different from the previous.

This issue is made worse when you take accessibility into account: not just whether your interface learning will continue to be applicable, but whether it will still be possible to use the application at all.

I just came out of a session at the CSUN conference (California State University Northridge International Technology and Persons with Disabilities conference) in which Mika Pyyhkala and Mark Reumann demonstrated the accessibility of a number of iOS applications. During the course of the demonstration, one recurring comment was that various iterations of apps had varying levels of accessibility.

These apps did not develop accessibility in a linear manner – version 1.2 might be great, version 1.3…not so hot. One would hope, in an ideal world, that any application would be initially launched with fabulous accessibility. Lacking that, I would certainly hope that the accessibility of an app would be constantly improving. Unfortunately, the reality is different from the ideal. (I know, this is shocking news.)

Why do we get this experience of “yo-yo” accessibility? Why is one version accessible, but followed by a version with less accessibility? Madness!

I’m not going out on a limb here, I suspect — but I want to connect this issue to work flow. Following up from a conversation with Karl Groves, and the content of his presentation on automated accessibility tools, there’s an incredible importance to integrating accessibility into the standard workflow. When accessibility is a separate process, it’s easily skipped, ignored, or reduced in importance. When it’s a standard part of the project workflow, part of an integrated process, then skipping or reducing the importance of accessibility becomes a burden.

These apps undoubtedly broke their accessibility because it was not in their process: they did a new design or added a feature, and it wasn’t accessible because the people who worked on it didn’t happen to know accessibility — and nobody was checking this.

When the argument is that accessibility is a burden, then everybody loses. If the argument is that leaving out accessibility is a burden, then everybody wins.

Now, accessibility is currently an expert-driven process. As such, it has limited integration capability. Your developers should not need to be experts on accessibility in order to avoid making these mistakes.

Here are just a few ideas of work flow changes you can look at to keep accessibility inside the work flow, instead of depending on outside expertise:

• Create reusable code blocks – Standardized blocks of code that represent how your organization structures form fields, buttons, labels, headings, etc. Nobody should ever have to write a form field: at worst, they should have to copy and paste some code that has already been established as accessible.
• Use tools that check work throughout the process – Checking accessibility only with a finished product is a broken process; use tools throughout.
• Provide documentation of techniques geared towards your team – Different users need different information. Content creators need to know how to structure content, but shouldn’t need any information about the framing structures. Interface developers need a lot more information. The language of that information needs to be geared towards those users in specific.

What you can do is going to vary enormously dependent on your organization: the presentation by Karl was based on large organizations looking at massive auditing tools with six figure budgets; the topic of our conversation, on the other hand, was about plans for integrating a check of the accessibility of authored content into a plug-in for WordPress. (Can’t give a lot of details yet; but it’s in the works.)

The point is that if you can be notified of issues while you’re working on your project, it’s much quicker and cheaper to get the fix implemented than if you’re notified of the same issues two months after release.

The new version of WP Accessibility has just been released. Updates include the inclusion of Chris Rodriguez’s a11y toolbar, as previously announced and support for a custom WordPress administrative stylesheet.

The first item, the accessibility toolbar, falls into a category of accessibility I rarely pursue: the front-end accessibility widget. I’ve written (negatively) about the concept before, in my article When More is Less. Having previously opposed accessibility widgets, I wanted to talk a little about why I think including this one is a good idea.

The Problem of Accessibility Widgets

The problem with accessibility widgets is that they are not an optimal solution. If the problem is that the text on your site is too small, then the optimal solution is to make the text larger. Providing a widget so that your users can make the text larger is clearly not the best possible solution.

But my WP Accessibility plug-in is in no way an “optimal” solution. While some of the elements of the plug-in involve creating an easier way of incorporating standard accessibility methods into a WordPress site, others are really about inserting improved accessibility into a site which is otherwise sadly lacking.

Don’t get me wrong: because WP Accessibility fixes some issues in the WordPress core code, it’s valuable in any WordPress site. However, a lot of the additional use cases for the plug-in are about patching accessibility into a site because the skill, time, or budget required to do it natively in the theme is lacking.

This is where the accessibility toolbar comes in. It may not be the best option for a site — but it may be the only realistic option.

If I may hypothesize a scenario:

You’ve just been hired by a company to manage their web site, after a previous developer left. They recently spent many thousands of dollars developing a new web site — but they didn’t really consider accessibility in the process. A complete revamp of the site isn’t something they have the budget or desire to engage on, but convincing them to install a plug-in that will have very little visual impact but improve accessibility is an easy target.

This accessibility toolbar is well designed – Chris did a great job. It’s subtle, simple, straightforward. I’m glad to be able to incorporate it.

WordPress Admin styles

Including a custom admin stylesheet allows me to fix a few minor issues in the accessibility of the WordPress back-end. Among these are some contrast changes; moving the post actions (Edit, Trash, etc.) into a context that’s visible to screen reader and keyboard users, underlining navigation links on hover, etc. What I’ve implemented is very basic, however — if anybody wants to extend them, they can do this by adding their own custom wp-admin stylesheet into their theme directory.

Recently, the state of Minnesota rejected a constitutional amendment referendum that attempted to make same-sex marriage unconstitutional in the state of Minnesota. Much of the reason that this amendment was defeated has to do with societal change — but there was also a change in how the issue was discussed that is believed to have had a beneficial impact on the vote.

That change was a move from focusing on civil rights as a method to convince people to vote against the amendment to focusing on stories of the loving relationship of same-sex couples. The personal story: hardships faced due to an inability to marry and the very real emotional bond within a couple helped provide a personal connection to the issue that civil rights did not.

Like same-sex marriage, web accessibility advocates have long used business case arguments and civil rights as the major arguments for web accessibility — but is this really the way to convince people?

There’s no question that arguments for civil rights and the business advantages of an accessible web site are relevant: but if you want to convince people, an empathetic response is even more valuable. I’ve recently been involved in more than one conversation trying to convince people of the value of web accessibility where the argument hinged on “show me personal stories of the impact of web accessibility, and I’ll be convinced” — but I didn’t have any.

I don’t have a stock of personal stories about web accessibility – how inaccessible web sites have stifled the success of users with disabilities or how an accessible web site has made somebody’s day — but I would like to collect these.

To that end, I’ve created a page on my site dedicated to collecting your web accessibility stories: any story, however small, will be greatly appreciated.

I don’t have a plan right now for sharing these stores, but I do intend to make them publicly available — you can provide a name and email with your submission if you wish, but it’s by no means required. Names will be shared with their stories; email will always be kept private.

Go now – Share your Story

I released a brand-new WordPress plug-in today, targeted specifically at improving accessibility issues. There’s only so much you can do via a plug-in when it comes to site accessibility — most of what grants accessibility for a WordPress site is in the theme. However, that doesn’t mean that you can’t do anything.

This plug-in is designed to help shoehorn some accessibility improvements into themes that need a bit of help. It can do a fair amount, and every feature can be disabled or enabled as needed for a specific theme.

The plug-in is new, so forgive me for any errors — either in judgement or in execution — but here’s what it can do so far:

• Remove redundant title attributes from page lists, category lists, and archive menus.
• Enable skip links with WebKit support by enqueuing JavaScript support for moving keyboard focus.
• Add skip links with user-defined targets.
• Add language and text direction attributes to your HTML attribute
• Remove the target attribute from links.
• Force a search page error when a search is made with an empty text string.
• Remove tabindex from elements that are focusable.
• Strip title attributes from images inserted into content.
• Add post titles to standard “read more” links.

Many of these are tasks that have been performed by a diversity of plug-ins or have been known as customizations to WordPress over the years, but many of these plug-ins have not been updated for a long time. I’ve centralized several valuable accessibility improvements into one plug-in, to hopefully increase the ease of implementation and ability to find what you need!

At the moment, the plug-in is focused on front-end issues, and does not currently include any administrative improvements.

Download WP Accessibility now and give it a try!