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.