Today, Henny Swan posted a blog entry titled Accessibility for Project Managers. Henny’s article is a pretty complete overview which discusses all of the steps in the SDLC in which accessibility should be considered. The article mirrors, in many ways, the information I discuss in a training course I’ve created on the topic and also mirrors the sentiments of many similar numerous articles and discussions of integrating accessibility into the SDLC.
At a high level, here’s what is proposed:
- Requirements Phase: Ensure accessibility requirements are included
- Procurement Phase: Ensure accessibility requirements are mandated in procurement
- Design Phase: Ensure accessibility requirements make it into the design deliverables
- Development Phase: Ensure accessibility of designs are retained; Ensure accessibility requirements make it into final delivered system
- Implementation Phase: Ensure any accessibility-related configurations are set as necessary
- Maintenance: Ensure accessibility bugs are found and fixed
Henny’s article doesn’t explicitly discuss each phase in such a delineated fashion and she includes an extra discussion of documentation, but it is otherwise very similar. Note: I’m not accusing Henny of copying anything. In fact, I’d instead argue that Henny is a very sensible person, and the information covered in her article and the other similar articles on the topic is the most sensible approach to integrating any product trait into the SDLC. Want security? Put it in the requirements. Want to support American Express in the checkout process? Put it in the requirements. Want a kitten delivered to the company president’s daughter every time someone visits the home page? Put it in the requirements. If it is not in the requirements, it doesn’t get put into the product. Period. End of story.
Waterfall Sucks
The last thing we want to do is be the guy nobody wants to be around.
Once decided you should document how success is to be measured via a combination of audits (internal or third party), user testing, user acceptance testing, automated testing and suchlike.
…
Before the first line of code is written the structure of a site, semantics, behavior and alternatives should already be documented in the IA, functional design documentation and editorial documentation.
The problem with this approach is that it perpetuates this waterfall model of accessibility. This is exactly the type of approach that contributes to the attitude that accessibility is a nebulous roadblock. When a project manager reads this, their immediate reaction is to become concerned for their timeline and budget – the two things that are universally considered in determining project success. The desire to want to document the living hell out of everything and perform audits at every step of the way is a normal one. If people don’t know what’s expected, they cannot possibly meet the expectations, so we must make our expectations clear. But piling on a seemingly endless array of requirements and documentation is not the answer. It makes accessibility look like a hurdle. People have a natural aversion to things that are burdensome and expensive. Over time (and I have witnessed this first hand), what happens is that they will become less and less likely to involve “The Accessibility Person” into the process. You’ll stop being invited to meetings. You’ll start hearing about projects about a week before it is set to launch. You’ll start hearing about executives who signed off on an inaccessible project because someone convinced them that accessibility was expensive and time-consuming. The accessibility of ICT projects will actually diminish, not get better, when accessibility is perceived to be a burden.
Agility is the path forward to Accessibility
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Principles behind the Agile Manifesto
Collaboration and Integration with all parties throughout the process of creating a system is the best path forward for ensuring accessibility. If you want to ensure that the resulting product is accessible, you can’t sit back and be a gatekeeper waiting to see if everyone’s got the proper documentation. While you’re writing documentation and making sure all the requirements docs are being followed, you could be actively making accessibility happen by working as part of the team. Dollar-for-dollar the time you spend writing up documents is nowhere near as effective at making an accessible end product as it could be if you were part of a team. Want to ensure a more accessible final product? Don’t argue the case for Accessibility, argue the case for Agile.
- Agile is inherently customer-centric. In an agile environment, the team is already focused on meeting the needs of their users. Getting them to consider users with disabilities is likely to be easier than presenting accessibility as a special list of requirements.
- Agile is built on collaboration. In an agile environment, team members and stakeholders collaborate to determine requirements, tasks, and their acceptance criteria. Become a member of the team, not a gatekeeper, and you will be seen as a resource instead of a hurdle
- Agile is inherently quality focused. Instead of being relegated as a last moment check, quality is seen as an inherent goal of the Agile process. A working product is the outcome of each sprint, thus necessitating a close attention to quality. When accessibility is seen as a trait reflective of quality, it is easier to adopt.
Wait, are you saying agile is inherently accessible?
Hell no. In my experience, agile teams are just as likely to create an inaccessible product as anyone else is. The single universal trait that contributes to inaccessible ICT is ignorance. If people don’t know what accessibility is, who it benefits, why it is important, or how to do it, they are going to fail in implementing it. No project management methodology can compensate for ignorance. But neither can documentation. The best possible approach is to educate all project staff and facilitate a collaborative work environment rather than burying them in bureaucracy.