(note: this article was previously published in French in June 2010 and translated by Stéphane Deschamps)

A frequent scenario

Let us begin by a not so imaginary conversation:

• The client: “We would like to have your opinion about an online application that we’ve developed.”
• The consultant: “Why of course, we do provide thorough audits, we will analyse your pages and deliver a huge report bearing all the problems and solutions we found as well as screen captures and explanations.”
  Thus the audit is performed by the consultant on a sample of pages taken from the site, and will be followed by an audit report that will give a complete overview of a site’s accessibility at a given time.

This approach is very interesting in numerous cases:

• When the site is already reasonably accessibility; then the audit comes as a confirmation that a number of accessibility-related improvements were done. This is the case for final audits required for conformity reasons.
• When, conversely, an accessibility inventory is needed after the site owner became aware of accessibility requirements, as a way of estimating investments.
• When the client needs to formally show a third party’s incompetence (web agency, services society, IT director, communications director, developer, manager), or when a formal report is the only way to turn on the red lights.

But in some cases the type of audits that consists in analysing a sample of pages through a complete set of criteria, then to produce a more or less thick deliverable can prove to be counter-productive. It becomes a double-edged blade.

When the scenario goes off the track

Let’s imagine a sensibly different scenario: the beginning is the same. A thorough audit has been agreed upon. When the reports are produced, it is discovered that the amount of work needed is daunting. The site’s accessibility level is a catastrophe, and even basic rules were not respected.
The whole wealth of remarks and recommendations must be taken into account by the teams in charge of the site. But how can you ascertain they will be? The answer is dead simple: you will have to do another thorough audit, whose job will truly be to prove the site’s conformity.
The verification audit has no reasons to be less heavy than the first one: of course the expert already knows the site and can concentrate on the defects he pointed out during the first audit, but the workload is roughly the same. The first audit is rarely enough to help solve all the problems related to accessibility. Sometimes, the second audit will even find out about new ones, induced by clumsy corrections, or simple because contents and interfaces may have evolved in the meantime.
This multiple-audit solution can discourage even the more eager developers and managers. Most often, after two or tree audits, accessibility is deemed a costly subject and which requires a very high-level expert, for a return on investment that is difficult to prove.
Along the same lines, audit cycles that are supposed to lead to a well-deserved conformity label often lead to failure. And when failure occurs, teams reject accessibility as a whole, as a counter-productive and excessively formal subject.
The scenario I’ve just described is still very frequent. It’s even so frequent that we need to draw some teachings out of it.

An accountability for results

The need for digital accessibility is vital: it enables a better integration for disabled people, but also for many other audiences. It helps industrialise the production of websites and represents an important management and social stake. But we are faced wth many potential problems:

• The return on investment of accessibility has yet to be completely proven,
• Accessibility is still perceived most of the time as constraints,
• Laws and standards in the industry are sometimes though of as hindering innovation, creativity and agility,
• Applying accessibility standards is often perceived as a measure for a specific audience, and sometimes a nuisance to all the other users,
• Accessibility standards are considered as the ultimate goal, whereas this approach should just be a means to go further in the production of websites.
  The people involved may fall into various traps:
• Reject the approach as a whole,
• Push the work to much later,
• Create ghetto contents (such as special versions for disabled people),
• Give up the production of contents deemed too hard to be accessible,
• Push accessibility to an extreme (“over-quality”), ending in insufficient results or acknowledgment, and eventually fall back into one of the preceding traps.

This risk is unacceptable, because the stakes are obviously essential: we do not have the right to get trapped, and as experts in the industry we must, at all cost, let our clients fall into these traps. This is why we must do whatever we can so that the production of online services becomes a lightweight, open and tolerant approach.
Most of what must be done, accessibility-wise, must be done prior to a thorough audit. Then during the improvement cycle, the cost must be optimised. Finally, the approach must be both progressive and flexible. All this is possible, but we’ll have to drastically change our habits: it is time to talk about agile accessibility.

What would agile accessibility be?

1. Identified criteria and process: it’s useless to do thorough audits of a design or of XHTML/CSS templates according to a whole set of guidelines. At each step of the process, starting at the beginning of it, only relevant criteria must be taken into account.
2. Quick validation in the form of expertise micro-sessions: the quick examination of a website by an accessibility expert gives key indications, so that action can be taken quickly. Direct work with an expert on a conference call (if possible with a shared screen) or in a live meeting enables the professional to easily understand the fundamental tests done by the expert and reproduce them, at least in part, throughout the development. Also, it is not necessary to sample 50 pages when examining 5 pages will show 80 or 90% of the most important problems.
3. Prioritisation: all accessibility criteria don’t have the same importance, the same severity, the same verifiability or solvability. An expert can quickly pinpoint the problems easy to solve, and those that will require more work. Exchanges can also help identify more easily the problems linked to the context (the content management system, budget, expectations…).
4. Planned improvements: a site’s accessibility can be thought of as a construction that needs foundations, walls, equipments and decorations. The expert can help you evaluate the cost and means needed for each of these step.
5. Quick iterations: repeating quick validation/planning/improvement cycles can help check what was improved and what is still needed in the next iteration.
6. Less formality, more efficiency: formal deliverables are indeed important in some instances, as a guarantee whether some points were properly dealt with. But most often the validation is essential and must be done quickly.
7. A complete audit at the end of the process as a success checker: the accessibility audit should end up showing more success than failures. It can lead to the production of a conformity document or to obtaining a certification.

Prerequisites

Attitude
On the part of clients as well as experts, you must first and foremost accept that accessibility is not a stable, static state, but a dynamic approach, a path along which one treads.

• Flexibility: you must accept quick, informal, badly-shaped deliverables. Their added value is important in the content/time-to-produce ratio.
• Accepting co-production: the expert and the developer must agree on co-producing validations. No one knows accessibility better than the expert, but no one knows the site better than the client.
• Accepting imperfection: it’s useless to get choked under delirious requirements. Begin with small steps, improve progressively, and remember it’s an ever-going process.
• Go for effectiveness: if a solution is quick and easy to put to work and you can implement it, then by all means deploy it.
• Accepting prioritisation: you cannot do everything at the same time, and even if you’re told everything is important, you cannot do everything. The expert must help you prioritise improvements; forget what people can think about you.
• Accepting that sometimes there’s choices to do: know that concerning accessibility, there is no one truth. This article’s author lives among many accessibility experts and can knowingly assure you that on some questions, there are almost as many opinions as there are experts. Corollary: when two experts agree on a subject, which is still frequent, listen to them and learn from them.

Ideas
Know the philosophy: you can master technologies at your fingertips, yet feel powerless when needing to deploy them. Always remember that a technology is a tool at the service of an idea, a use or a message. Behind usability rules, there is a philosophy regarding access to digital contents. Opinions may vary, but you cannot afford not to have one yourself. If you don’t take position, you’ll never be able to make the right choices.

Expertise
By far, it’s the most precious good on the accessibility market. An accessibility expert has rare qualities:

• They must be tolerant, accept mistakes, understand them and be empathic.
• They must have assimilated continuous (dynamic) improvement.
• They must be able to communicate with various audiences (both managerial and operational) and thus must be able to adapt to any listener’s level.
• They must have a very high technical level (who would’ve guessed!).
• They must propose arbitration, not enforce solutions.
• They must understand the contexts of small and big organisations alike.
• They must be able to know where accessibility is in the general web context, and in Web quality in particular.

What should you expect from this approach?
Let’s mention that the core of this article is also relevant if you want to implement guidelines, be they quality , SEO or performance guidelines.
Most often the thorough accessibility audit is an umbrella that you can open if need be, to show that things have been made in a formal way. But in quality processes, every time formalisation takes up on efficiency, you’re not far from failure. Even worse, excessive formalisation is over-quality. In a way, you’re giving the preference to quality assurance in spite of quality. Yet quality assurance in excess is a non-quality and is therefore to be taken as a non-quality cost.
For those who are ready to accept the flexibility of a less formal approach, and when the context doesn’t prevent it, agile accessibility is very promising. It makes it easier to produce accessible websites faster. Project teams will get to grips with the subject better. In the end, it makes accessibility a normal element in the process and makes it less of a constraint.
Ideally, agile accessibility could even contribute to transferring skills from the experts to the project teams, thus limiting the need to call experts to the rescue for very arduous questions, for complex arbitration and for thorough and exhaustive audits that can lead to conformity and certification: here we go.
The article you’ve just read aims at laying down the foundations for agile accessibility. The reality of accessibility is often more nuanced, and several experts who have read and commented this want to add their experience. So this must be read as the first page: Stephane Deschamps, who had already tackled the subject two years ago in an unpublished article, will show you how to put this approach to use.