This post is about some of my reflections and interpretations of official and unofficial guidelines when working on implementation of accessibility in agile developement teams.
I believe that accessibility should be a part of the development process from ground up. Starting as early as possible – for example when we are defining the personas or user journeys, mocking wire-frames, designing user interfaces, and of course when coding and testing. Accessibility can only be seen as an integrated part of digital production, be it web, mobile or even scoping out to communication, documents etc. So let’s think of a holistic procedures that should enable us to really be effective and provide our end results in an accessible manner.
As it is nowadays common to use self-organizing agile teams that are also using DevOps and other modern methodologies, we must start there. In practice I can not totally agree that all members in a team should do all tasks, as the technologies evolve in too many directions and too fast for every team member to be able to be proficient with solving different tasks.
For example – Database architect should not also fix front-end bugs and the other way around. I will not say that it is not possible, but usually there are still personal preferences that should be taken into account. I see a modern team as a self-organizing unit with different experts, I will not define them statically but I am thinking about at minimum:
- business domain expert (taking care of providing value, defining the product and dealing with resource allocation etc.),
- user interface and service oriented expert (usually a UI and UX designer and front-end developer roles),
- technology domain expert (architecture, back-end, DataBase, DevOps, and other profiles).
This team should be able to execute digital production provided it gets correct business and content input.
Defining accessibility roles
So here we must at once define also the accessibility practicalities – who will take care of it, what needs to be done and what are the inputs and outputs.
Main focus should fall on the user interface roles, but business and content role must also be involved.
WCAG is a known and mature set of guidelines that should ideally be in the toolset of every team member, but practical experiences are showing that the UI, UX and front-end developers should be responsible for execution that is based on business demands and content.
It is much more effective to make accessible digital products from ground up and that can only be done when content and business requirements are understood from the beginning.
A-team – Accessibility Team suggestion
I can think of an A-team – Accessibility Team as the best practical solution for implementing accessibility in a company. Please allow me to explain.
Before WCAG is in reality regularly used in all processes that needs it and before all developers really understand the importance of it for their own work they should get help and also systematic awareness building.
Therefore I suggest that organization get proactive members in all existing teams that are willing to have more focus on accessibility and creates a independent team of accessibility specialists that will be able to provide and complement their primary teams with accessibility support from first day on. Then with time the knowledge will be more anchored and accessibility efforts will give results they deserve.
A-Team is a team of proactive members from all other teams that are taking care of accessibility in their primary teams.
my definition of A-Team.
So to be able to execute this plan I suggest the following:
- Company needs an accessibility specialist that haves a mandate of leading A-team,
- Each team in the company consolidates internally who will be most appropriate member to be a part of the new A-team. Ideally this is a front-end / UI / UX role but not necessarily,
- A-team is organized and gets a mandate for regular meetings about progress and also regular workshops that A-Team leader will organize to “train the trainer”,
- A-team sets KPI’s (Key Performance Identifiers), goals, strategy and defines also practical tactical information and other hands-on resources.
A-team should then be perpetually educated in the WCAG and after that also WCAG-EM but let me conclude that this practical approach to embedding accessibility into company is only the first step on the important journey towards continuous accessibility.
