The brief and the review: secrets to accessibility success
Posted by Adem Cifcioglu on April 13th, 2013 in Accessibility
We hear some strange things working in the accessibility space, like “the brief was to rebuild, not to improve; accessibility enhancements and features are out of scope”.
Now, when I first read the above in an email I was a bit taken aback.
In fact, I had to read it a couple of times before it actually registered.
I mean, it is 2013, right? Right? 2013…
So how is it that in 2013 we’ve still got agencies referring to accessibility as “enhancements” or “features”?
Let’s think about the steps in the standard publishing process for a large organisation:
- Identify campaign (or tool, idea, etc.)
- Draw up requirements
- Compose brief
- Send brief to agency
- Agency develops concepts
- Review concepts and decide which to proceed with
- Agency builds campaign to concept
- Review build (usually done by briefing stakeholder)
- Advise web team e.g. “Hey guys, we’ve got this campaign coming up…”
- Agency provides campaign collateral, tools, assets, etc. to web team for integration
Where in this process does accessibility fit?
The correct answer is: throughout the entire development process.
But we all know this is not what happens. More often than not, accessibility is not even thought of until the final step, when all the assets have been provided for integration.
Why it is like this?
Right now accessibility is not ‘front of mind’ and is not considered by anyone not working with or around it on a day-to-day basis.
I imagine some of you are saying “But I employ a web/digital agency, they should know this stuff right?” You’d think the answer to that question is yes, but it’s not really that simple.
Good design takes time.
In today’s era design/creative agencies are almost like production factories; where in order to win work while cutting costs, agency executives force staff to do more with less (more projects in less time). This means good designers and developers do bad things, cut corners and make compromises that they usually wouldn’t.
The aim of the game becomes quantity, speed and profit – it’s about the amount of work you can do and the lowest cost to gain the biggest profit.
With cut corners and compromises comes a reduced quality of work.
Couple that with the fact that accessibility is not front of mind for the client, which means accessibility requirements don’t even make it into the brief, and you’ve got the answer.
So, what can we do about it?
You may not think there’s much you can do, but there is, and it’s surprisingly simple. The secret to success has two key components – the brief and the review.
The brief
Agencies work off briefs, they work off requirements, and they work to achieve the goals or outcomes that their clients set for a specific project.
Accessibility doesn’t “just happen”, there’s only so much that can be done by accident, and semantic HTML only gets you so far.
Accessibility needs to be planned for and thought about up front. That means including it as a requirement in your brief to your agency, so they consider it before concept development, before the design stage, and well, well before anything is delivered to your web teams.
The review
Once accessibility is included in the brief it becomes about the reviews.
The agency takes the brief, develops concepts around it and provides those concepts to you for review.
The process is followed as usual, with one key difference: accessibility is a requirement that can be tested, and the agency can be held accountable if they don’t deliver.
If they don’t produce an accessible product (design or tool or whatever), then they haven’t fulfilled the requirements, which means they haven’t hit the brief.
That’s why the reviews are vital.
Concept review, design review, and build review are all so important. The Web Content Accessibility Guidelines (WCAG) give us a set of testable criteria to check against, which makes things easier on both sides. The client can test and so can the agency.
Take the time to conduct the review and ask the agency to provide the results of their testing, because if they say they can build it, they need to be able to properly test it.
Ongoing accessibility is the end goal
Accessibility may not be front of mind, but more often than not there’ll be some type of standard requirements document that your organisation uses for each project.
Add it in, make accessibility part of your standard requirements document and dedicate time to it in the review stages.
It may not guarantee accessibility, it may not make it front of mind, but it should help your agency and your organisation produce accessible content.
