Photo of Jamie & Lion

The personal site of Jamie Knight, a slightly autistic web developer, speaker and mountain biker who is never seen far from his plush sidekick Lion. View the Archive

Topics: Autism Development

Definition of Done for Accessibility Tasks.

If you have ever worked on an agile team, you have probably come across the term “Definition of Done”.

The DoD as it is known, is the checklist which standardises the requirements before work is considered finished. You can read more about the definition of done on scrumalliance.org)

A DoD for a11y.

I’m currently building a small virtual team which will focus on accessibility related tasks. The tasks are pretty wide ranging. For example, conducting design reviews, resolving bugs, or helping to prototype a complex UI widget. That sort of thing.

Part of building this team has been to build the process; and today I have been thinking about what makes a great DoD for accessibility tasks.

A prototype DoD for a11y.

This is my prototype DoD so far:

  1. Peer Review
  2. Testing
  3. Documentation
  4. Labels and Component Check

1: Peer Review

I think all good DoD’s should start with a “peer review”. That is, a code review or for the task to have been paired on. The purpose of a peer review or pairing is to introduce a second set of eyes to the code. This helps to reduce future bugs, and also allows for knowledge transfer.

2: Testing

The BBC Accessibility team has a recommended test matrix. In an ideal; world, we would suggest that all tickets are tested in the entire matrix. However, as the team is operating on these tickets is doing so on a voluntary bases i’m not convinced testing everything is going to be productive.

The aim of the testing is to provide confidence; knowing how much confidence is require is a complex topic… So my ideal accessibly DoD includes testing, but I am not sure how much yet. If you have a suggestion, or a model for this, please let me know in the comments.

3: Documentation

This will not apply to all types of tickets, but I think for many tickets documentation is a requirement. In short, if no documentation is being produced, I think there needs to be a good reason as to why.

Like testing, documentation is a bit of a slippery slope. You can easily do too little or too much. At this stage I am thinking that each ticket type should have the following documentation requirements before it is considered “done”:

4: Labels & Component Check

One of the outcomes required for the process is to enhance the understanding of the type and quantity of accessibility tasks coming through the team. So an explicit step in the DoD to check that labels and component attributes have been correctly set is a cheap investment to aid future statistical analysis.

What am I missing?

Thats some of my thinking so far; It’s early days the proposal above is very rough. What would you suggest? Do you have an a11y element in your DoD? Let me know in the comments, or via twitter (@jamieknight) and email

Published: 1 September 2014 | Categories: Permalink

Comment

Your Comment