Agile accessibility: from theory to practice > Articles  > Agile accessibility: from theory to practice


Accessibility practices will soon need to be deeply redefined. We propose here an innovative method, far from the classical sanction-evaluation at the end of the process, that involves progressive improvement all along a project’s lifecycle.


(note: this article was previously published in French in June 2010 and translated by Stéphane Deschamps - if you have any feedback on the translation please let us know)

Going further

The first article in this series showed that doing an audit at the end of the process is not always the most relevant nor the most economical solution to make a website accessible. It defines a few directing principles that can lead to work on accessibility in a less formal, and at times more efficient way.

It is now time to get down into the trenches and to verify that these directing principles can be applied to real-life situations in an industrial context.

Practically, how can we work things out so that accessibility experts work together with the external world, and not only focused on their own area of expertise? How can we use them as an active component of a linear process, that goes from identifying the client’s need to the production of an accessible website? How can we fix issues throughout the process, instead of at the very end?

To better answer these questions and try to apprehend the ins and outs of this approach, we will start with the theoretic notion of evaluation in education sciences. We will then show, based on our own experience in a big company, how agile development modes can help to optimise, and make profits from, the accessibility approach.

Evaluation and education theories

You and I, when we were in school, made a clear difference between two types of assessments: the ‘flash quiz’ and the ‘end-of-term quiz’.

These two types were actually parts of an evaluation scheme in two steps, respectively:

  1. Formative assessment*: it aims at finding out as soon as possible the points not understood or learnt, through a small questionnaire, a few exercises. Quickly done, if possible quickly corrected, it enables the teacher to avoid too big a discrepancy between what they think is coming through and what was actually gathered by the pupils; when appropriate, the teacher can correct the trajectory with as little an effort as possible.
  2. Summative assessment**: this is done at the end of a teaching cycle. It enables the teacher to control the sum (hence its name) of what was taught in a given cycle (a complex notion in Grammar or Mathematics, a period in History, etc.). This assessment is sanctioned by a grade, and it is this grade that will be written down on quarterly reports and will show the pupil’s progression. [1]

Do you see where we’re heading to? Most of the time, accessibility is focused on the summative part, i.e. the after-the-fact assessment to check that a number of checkpoints were taken into account.

As we will see, we have to draw inspiration from the agile approach to integrate a kind of formative assessment, do the work progressively, by embedding accessibility at the heart of the development process.

Four-hand coding

Agile development provides us with a slew of methods that aim at making software development more fluid, more efficient, more reactive: in a word, more agile.

In particular we want to have a closer look at four-hand coding. Traditionally a developer would produce code on their own, and in the best case would submit their code to a validator who would write a code review listing the points that needed correction. The code would go back to the developer, who needed to integrate the validator’s remarks before lauching a test drive.

Agile development makes code review a part of the everyday process, validator and developer trading places all the time. They code four-handedly, each other taking the other’s code as their own, and limiting the number of potential defects (because tomorrow the other developer’s code becomes your own).

This approach does not guarantee an exhaustive accessibility validation, but it ensures that from the very creation of the web interface no blocking point will remain when the site goes live.

A lever to optimise resources

Going back to how we described our method: we have merely transposed to web development the notion of formative assessment. We evaluate the understanding of a given accessibility problem by the developer, and we facilitate the integration of accessibility requirements in their production.

We can immediately influence the developer’s work to put them back on the right tracks, instead of waiting until the very end of the production cycle to list all that was done improperly, or worse, that is completely blocking from an accessibility point of view.

The accessibility audit as we know it most of the time —costly, exhaustive, sometimes sanctioned with a certification— can always be done at the end of the cycle, like a summative assessment. It will make it possible to track through time the measure of accessibility as a quality criteria among others.

This two-timed approach is enormously beneficial:

  • Training developers is much lighter, since the accessibility expert among them will deal with the filtering of complex notions to give them only what is relevant to the current development.
  • Accessibility-related validation cycles are drastically reduced. In the traditional approach, we count roughly three days for a serious audit, to which you must add a feedback conference (a few hours). Here, we’re sitting next to each other, and every point is treated in real time after having discussed the best way to correct it.
  • Corrections cost almost nothing, since they are integrated upstream, whereas (most of the time) several days are needed after a classical audit, to which you must add non-regression control.
  • The final audit is greatly simplified thanks to this day-to-day mentoring, but it will still serve as summative assessment, if possible exhaustive, of the evolution that took place between two final audits.

Agile accessibility: in which context?

The method we’re showing here can’t be applied to every situation. Making up a developer/expert pair won’t always be possible: the market is very imbalanced, there are way more developers than actual accessibility experts.

The specific context for experimenting this method is one of a big responsible enterprise who chose to organise a full team of experts to mentor projects that need help on a day-to-day basis.

I’ve had the occasion to work according to the same principle on several projects: I sit next to the HTML/CSS/JS developer, or next to the Flash/Flex developer, and I validate their progress on the fly. If we detect problems, we correct them straight away. I explain what is wrong, we find a solution together, and the correction is integrated directly.

Reading this article, you may think a four-hand development mode is not for you, but you may be wrong. This method can be used in a lot more situations than you may think, if you consider the workload differences: ten days for a front-end developer will mean you’ll only need one day for an accessibility expert.

In closing

We have not yet talked about an indirect advantage of this agile-like mentoring method: in the long run, the developer’s brain will be impregnated with the subtleties of accessibility; this apprenticeship will be much more profitable than a theoretical training (because it’s practical) and more impacting (because the developers will be able to see by themselves the improvements in their product).

Mentoring development along the way instead of having to re-engineer everything at the end of the run, simplifying the process of production/correction, all this has substantially reduced the man-day workload around quality; also, a better accessibility is guaranteed to the projects. We still have to proof-test this method in other structures, such as small agencies, public institutions, etc. We hope to have provided, at least, hints about an efficient, alternate way to help integrate the accessibility constraint into the lifecycle of web projects.


This article was published in 2010, but was submitted to OpenWeb in 2008. Four-hand coding and the simile with agile methods were already relevant and I had been doing it on a daily basis at work for a year or two. Two years later, more than ever, it is important to push the methodology of accessibility forward. A huge thank you to Élie Sloim for his help on dusting off this article.

Notes (in French)

  • * « Evaluation continue des processus d’apprentissage, elle a pour but d’informer l’apprenant puis l’enseignant sur le degré d’atteinte des objectifs. » (Rieunier, Pédagogie, dictionnaire des concepts clés, 1978) Source :Évaluation
  • ** « L’évaluation sommative attribue une note chiffrée à une performance jugée représentative de l’apprentissage terminé, et ceci aux fins de classer ou de sélectionner les élèves. La procédure ne poursuit donc plus, en théorie, aucun dessein pédagogique, mais répond à des exigences administratives, institutionnelles et sociales. » (M. Minder) Source :Évaluation


[1I’m afraid that ‘formative’ and ‘summative’ may be more French than English. Again, feel free to get in touch with me if you have a better translation.

About this article

Your comments

  • Chitta Jena On 12 March 2015 at 09:45

    Saw your post and quite impressed with the comments over there. However I’m struggling to find a right tool to be used to run as part of nightly build.

    Could you suggest some? We are using Jenkins and Bamboo for Continuous Integration and deployment.

  • Stéphane Deschamps On 12 March 2015 at 10:20

    @Jena Unfortunately I don’t know automated tools which could do that…

Your comments


Warning, your message will only be displayed after it has been checked and approved.

Who are you?
Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Follow the comments: RSS 2.0 | Atom