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…

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.

Jennifer Sutton brought this interesting factoid to my attention today: the single most common HTML validation error is the missing alt attribute.

Of the 100 most common validation errors collected by W3C Love, a missing alt attribute comes it at number one — with almost double the occurrences of the next most common error.

It’s 2012, and the key mistakes in HTML seem to remain the same.

Now, one can’t help but hope — since these are the results of validation tests — that these numbers also reflect a large number of people who went “Oh! Whoops! Better get that information in there.” Of course, some of those people may have then gone on to write in “Spacer.gif. 600 bytes. White line.” as their alt attribute.

Obviously, this raw number of errors doesn’t demonstrate a lot of definitive information. However, the mere fact that this is literally the most common validation the error points to some serious problems in HTML education or in HTML generating tools.

I can understand people providing bad text alternatives. When you read over the guidelines for authoring alt attributes — either in the HTML 5 specs or Steve Faulkner’s slightly-more-easily-understood Techniques for useful text alternatives, it’s easy to get overwhelmed. The chains of instructions: this MUST be done, that MAY be done, this is REQUIRED, that is OPTIONAL…it can be a lot to digest.

But omitting the alt attribute entirely is kind of scary. Yes, it’s true that the HTML5 spec currently (and unfortunately) allows the alt attribute to be excluded in certain very limited situations — but the statement that alt attribute is optional in HTML 5 is far from accurate. It is definitely still required, and omitting the attribute is discouraged in no uncertain terms, as below:

Such cases are to be kept to an absolute minimum. If there is even the slightest possibility of the author having the ability to provide real alternative text, then it would not be acceptable to omit the alt attribute.

Even the most casual search of phrases like “alt attribute optional” brings up many, many results clearly indicating the importance of using the alt attribute without even a suggestion that the attribute is in fact optional, so it seems like somebody would have to work pretty hard to come away with the impression that it was optional.

Why is it left out so frequently?

We need better education. Ignorance is still the primary guiding factor in casual web development. When people are exercising barely-learned skills, they tend to go in the direction of the simplest possible set of instructions — leaving out any portion which doesn’t seem to have any impact. That means that images are included with a src attribute; possibly with width and height; and frequently with some kind of inline style or border instruction. Alt attribute? Why?

Any time you read up on an alt attribute, you’re likely to run smack into the TL;DR problem: explaining how to use alt attributes in any detail means a long, involved explanation. Even explaining the incredible difference between an empty alt attribute and an ommitted alt attribute is over the head of many layman content authors.

We need better decision making tools. It’s necessary to simplify. The experts need to work out the complex details of what, why, how, and when an alt attribute should be one thing or another. For the layman, it needs to be summed up as simply as possible.

Here’s my idea of a generalized alt attribute decision tree:

• Is this image a link or form control?
  • Yes: Alt attribute must communicate the destination of the link or action taken
  • No: Continue on!
• Does this image contain text?
  • Yes: Alt attribute should include the communicative text of the image (not text included for visual effect)
  • No: Continue on!
• Does the image contribute meaning to the current page or context?
  • Yes, and it’s a simple graphic or photograph: the alt attribute should briefly describe the image in a way that conveys that meaning.
  • Yes, and it’s a graph or complex piece of information: the information contained in the image must be included elsewhere on the page.
  • No: the alt attribute should be empty.
• Is the image something other than the above?
  • The alt attribute should be empty.

This very definitely does not cover all cases. But it’s much better than nothing; I hope that somebody is able to make use of it. If you have a quarrel with the wording or instructions, let me know in the comments!

It is incredibly hard to resist covering more and more issues here. But the purpose of this decision tree is to provide a simple and understandable tool to navigate the most common circumstances. This is not the place to explain the entire scope of alternative content.

At CSUN 12, I attended an interesting but somewhat disconcerting demonstration of Google’s progress on making their Google Docs suite accessible. The presentation was by Anne Taylor from the National Foundation of the Blind and Jeff Harris, the product manager for Google Docs.

They clearly agreed on one core point: that Google Docs was definitely not ready for users with disabilities. So, the demonstration was more a show of the range of changes which Google has been adding to make their Docs suite accessible.

On the surface, this is great: Google, a major web apps producer, is working very hard at making their products accessible.

But I’ll hope you’ll pardon me if I don’t consider this a reason to party.

What the demonstration really showed me was method of working with accessibility which seemed to amount to reinventing the wheel — doing whatever they wanted to implement a method for their software, then doubling their efforts so that they can use that method and make it accessible.

That Google is working to add essentially their own accessibility API layer between their apps and a screen reader is only mildly disturbing to me. They have the resources to do this, and I do believe, on the basis of the demonstration, that their cloud office suite will eventually be accessible.

What really concerns me is the example they’re setting.

In the CSUN session on Perfect Accessibility, Henny Swan raised a question about providing examples. The specific subject was in respect to organizations with an international reputation in accessibility, not an organization with a generally international reputation for web expertise; but I think that the point applies.

Google, while not particularly known for their accessibility expertise, is well known for pushing the envelope in web development. They build cloud software which can do some very cool things. What it does not do is follow anything apparently similar to standardized methodology — and because of that, as an example, their work is grossly problematic.

I worry that talented developers will look at Google’s methods and see them as a great example — when they may not also have the resources to build an entire accessibility abstraction layer between their ideas and assistive technology.

Now, there are some advantages to Google’s system, as well. Because they are devoting these kinds of resources to accessibility, they’re not only aiming at the possibility of using the Google Docs suite; they’re aiming at a great user experience for users with disabilities.

Nonetheless, a truly accessible interface with Google Docs is still a significant ways in the future. The best experiences currently are either using NVDA with Firefox or Chrome with ChromeVox and JAWS or VoiceOver.

We need to have a talk with marketing.

So, I’m sitting at CSUN 2012. It’s after the keynote, but before the first sessions of the conference – and some of the very key points of difference between the marketing and accessibility world are making themselves very clear. Most of the conferences I’ve attended in the past were marketing-oriented – and even where the subject of the conversations are similar, the overall impulse behind the issues is radically different.

The simple fact is that marketing is fundamentally business-oriented. It’s about moving your or your client’s business towards what counts as success for that business. Usually, that means greater profit: higher sales, better ROI, lower expenses.

The world of accessibility is oriented towards the success of the individual who uses your business. Instead of focusing on the profitability of business, accessibility pursues optimizing the experience of the user. This approach certainly can and should lead to improved ROI or higher sales — but it’s not how it’s advertised, and it’s not the goal.

The issues and needs may have a lot in common, but having a different core motivation makes for a radical difference in approach.

Great intentions, road to hell paved with

In marketing I have long observed a tendency to compromise the end-user’s experience for the opportunity to increase business opportunities. However great the intentions of a business owner, they can easily be swept away by the perceived opportunity to increase their business.

With a definite lack of available statistics which can reliably expose the real economic impact of users with disabilities on the web, this is a difficult argument. Is it a lack of empathy? Is it partially because the physical environment of a store forces the business owner to directly confront the visitor with disabilities whom they have disenfranchised, an experience which doesn’t exist online?

The disembodied user effect is well known in social media. The willingness to treat people online as objects rather than as people is damaging in many environments, and the arena of disabilities is almost certainly among them.

What can the accessibility world do to make this real for business owners? Improving empathy may be one path. Producing real, concrete statistics demonstrating the impact a lack of accessibility has on a web-based business may give additional working fodder.

But educating businesses may not be the best path. Educating marketers — possibly the class of service most heavily employed by businesses with a web presence — could have a truly inspiring impact. Where do business owners turn first when they’re looking to develop their web presence? Marketing. In the business world, a web site is fundamentally a marketing tool — so perhaps that’s where education and research needs to go.

Bringing the world of marketing to a point where it views a simple accessibility failure like inserting keywords into an alt attribute as a threat to the web site’s users, rather than as an opportunity for search engine optimization could have far-reaching impact.

An aspect of the problem for many web sites has to do with long-term business development. A business may hire an accessibility expert to review their web sites, make suggestions, or re-work their web site, but when they hire a marketing firm for long-term web site development, they can lose their accessibility very quickly if that marketing company doesn’t also have a firm grasp on accessibility.

Marketing is a necessary service for most businesses. Accessibility needs to be understood as an equally necessary partner to any marketing efforts.

Somebody recently contacted me with a fundamental question: they were undertaking an accessibility audit, and didn’t know how to structure the process. They knew web accessibility well enough — but from the perspective of setting out to perform an audit, they weren’t sure where to go.

As a result, I’m putting together this article to talk a little about how to structure an accessibility review, in all the practical ways — how you address coming up with a quote or estimate, ways to structure your research and site inspection process, and dealing with long-term follow-up.

• Specify the scope of the audit
• Identify “show-stoppers”
• Estimate or quote the project
• Plan your audit process
• Schedule a follow-up

Figuring out scope

Although the ideal is to perform an accessibility review which identifies every problem on a site and specifies solutions, that’s not always practical. In fact, it’s sometimes utterly pointless — it depends on the ultimate goal of the review. The review process for a site which is considering a redesign is radically different than for a set of templates intended for a web site still in development.

Setting goals at the outset is key. Are we looking to identify key areas for improvement? What are the resources available for fixing problems? If an aspect of the site is rife with major problems, is it best to identify every problem within that area, or simply describe the general issues and recommend finding a new solution?

An initial review does not need to identify every problem. One route I’ve frequently used is to specify a multi-stage review process: an initial review, in which I note major issues and provide guidance on fundamental principles of web accessibility, and a follow-up in which I re-check the site and, if desired, provide further guidance and detail for continuing development.

Identifying “show-stoppers”

What’s a “show-stopper”? Essentially, that’s a function of the site which is so completely inaccessible that there is no value to identifying the problems — instead, you should just describe what would constitute a good solution and recommend replacement.

It’s not uncommon for this to arise at the very earliest stages of the review, when discussing scope. If a site is using a CMS or a framework which is fundamentally rendering it inaccessible, you may want to begin by recommending redesign of the site. However, due to the common usage of external resources to provide video, interactive widgets, or social media (to provide a few examples), it may be that there are elements in use which won’t stand out right from the beginning.

Rather than performing a detailed exhumation of a fundamentally broken aspect of the site, it may be in the best interest of all parties to simply flag it for replacement and discuss that possibility with the client.

Why is this section part of the business structure? Because spending hours reviewing replaceable services is a poor use of your time and your client’s money. You should be looking for ways to improve your client’s site without costing them an arm and a leg!

Coming up with a fair estimate

It’s difficult to provide a good estimate on what a large-scale accessibility review is going to require, in terms of hours or dollars. The larger the project, the harder it is to quote. Keep in mind, however, that what you’re quoting is not generally going to be based on the number of documents on the site — rather, it will be based on the number of unique templates, forms, and navigation structures found on the site.

It is entirely possible that the site you’re reviewing will have 12,000 pages, most with images containing improper alt attributes. However, as an accessibility consultant your time is better spent identifying one or two representative examples and explaining how to properly use the alt attribute than it is painstakingly identifying every single inappropriate attribute throughout the site.

For this reason, you should be looking at the site as a process, not as a collection of pages. The ideal process of the site can be described, greatly simplified, in four steps:

1. The visitor arrives at the web site, which can happen at any place in the site.
2. The visitor will attempt to move to another point on the site, which may be another part of the same document
3. The visitor will begin a goal, which may be a purchase, a form submission, or the acquisition of information
4. The visitor will successfully complete that goal, and be notified of the results.

This general outline describes any visitor to a web site — as a consultant, your job is to identify each barrier they may encounter while completing the process. You don’t need to look at every single page of the site in order to see the shape of the problems — if you can’t navigate using a keyboard on one page, you probably won’t be able to on any other page, either!

With this knowledge, it becomes readily apparent that a web site which has 12,000 pages but uses only one navigation structure, one template, and has only a single form will be much more quickly reviewed than a site with 120 pages which uses 5 templates, provides ecommerce, and has different navigation structures depending on what area of the site is being used.

A 100% complete audit must allow for the possibility that each page may exhibit different problems. After all, if you haven’t looked at a page, you have no way of knowing how different it may be from what you’ve already seen. However, in all probability, pages of a site will be at a fairly consistent level of accessibility. The pragmatic approach — mindful to your client’s budget needs — is going to be a selective audit, not a complete audit.

Plan your Accessibility Audit Process

Now, once you’ve done this a few times, you’ll probably have the basic approach down cold. Every web site is different, however, so that isn’t going to completely free you from doing some planning. You still need to decide what your approach will be. Two example starting approaches could be process-based testing or issue-based testing.

If you’re going with a process-based testing procedure, you’ll start by selecting a process – any process. The path to make a purchase; getting to the Privacy link in the footer; sending a contact message. Follow that process all the way through in painstaking detail, isolating the accessibility issues encountered along the way.

With issues-based testing, you’ll instead pick an issue – such as keyboard accessibility. Work your way through the entire site, noting keyboard-relevant issues as you go. Then move on to the next issue and start your hunt over.

It may seem like I’m describing a very pedantic way to thinking about conducting an audit — you know that you will ultimately do both of these in their entirety. However, the reason for having a plan is simple: you need to avoid the trap of the scatter-plot approach. If you don’t have a system, you’re far more likely to end up missing problems – either because you failed to consider keyboard accessibility over here; or because you forgot to check the contact form when you were reviewing contrast. Having a plan and a process will help you avoid these gaffs.

Schedule a Follow-up

It would be nice to believe that when you’ve written and sent your painstakingly thorough accessibility audit to the client you are done with the project. Sadly, we don’t always live in that pleasant fantasy world. (Although, to be honest, in my fantasy world an accessibility audit would consist of nothing more than a smiley sticker and the phrase “Good Job!”)

Unfortunately, no matter how detailed you made your report — the report doesn’t fix the web site. The client’s developers need to do that. Or, as is sometimes the case, the client’s developers will fail to absorb the principles of the document…and while fixing the problems you described, will create new accessibility issues. Or, they’ll implement a fix which shunts the problem somewhere else, rather than resolving it entirely.

This isn’t a guarantee – there are developers working out there who don’t know accessibility, but immediately catch on to the concept once the issues are presented to them. But there are also developers who…don’t.

Planning at least one follow-up review is important. You’ll also need to make yourself available to answer questions from the development team while they work through your suggestions.

The follow-up review should be a quicker task than the initial review. You can spot-check to see how the developers worked with your suggestions. If you like what you see, you can probably be fairly satisfied. If you see problems, you may need to keep going. If you see a lot of problems, you may need to give the client a call before continuing.

In Summary

Performing an accessibility audit requires many skills: an eye for detail, a strong sense for when an accessibility issue requires fixing, and when it requires replacement, and the ability to describe accessibility concepts in language developers can respond to. Join those skills with sound business planning and a personal investment in your clients’ success, and you’re ready to go!