A few years ago I was approached by a Creative Director for a Federal Contractor here in the DC area. She outlined a familiar problem contractors encounter: her design team made hundreds of beautifully designed PDFs for a government project that were inaccessible, and thus were rejected. She asked for my help in fixing them. At the time, I explained to her that I wasn’t really doing remediation (i.e. fixing problems after they exist) freelance work, but I’d be more than happy to help them to figure out how to fix the PDFs so they wouldn’t have this problem again.
After I had been working with them for a while, they asked me if I’d join them full-time. When they sent me the job description, I politely declined. The description was essentially for an Accessibility Tester position, and frankly this is not what their Creative department needed. There’s no point for companies to spend money on positions that will make the lives of developers and designers difficult because they continue to make the same mistakes over and over again.
Joe Dolson (@joedolson), a fellow accessibility professional, wrote a fairly accurate depiction of this situation recently in his article, “I’m an Accessibility Consultant. Please stop hiring me.” As he explains it:
When your primary role is to come in and tell people what they’ve done wrong, you’re always going to be viewed to some degree as the villain. It doesn’t matter how nicely you put it — you’re ultimately telling somebody that they did this wrong, and they have to fix it.
Accessibility Shouldn’t be a Quality Problem
Part of the reason why the de facto reaction to Accessibility Consultants is to look at them as the bad guys is because companies have a tendency to wait until a problem occurs to decide how to address it. This approach has roots in the way software development was done back in the day, and was the preferred method of project management from the Department of Defense in the mid-eighties.
Even Agile companies tend to take this development approach when trying to integrate accessibility into their project management. It’s usually seen as one step among others during the lifecycle of the project. Essentially, the ‘step’ is derived from the question, “After I do this, what will happen?”
I believe another reason this problem exists is because accessibility is delegated to testing phases based on advice from Accessibility Professionals. Almost all of the tools that ensure software is accessible is used for testing purposes. For years, people in our field have been promoting the idea that it’s important to make sure Information and Communication Technology (ICT) works with the tools that make it possible for people with disabilities to use them. This is not bad advice, but project managers tend to respond to these recommendations by ensuring that something works after verifying it in the testing phase.
The notion of placing resources for accessibility in a testing phase is exacerbated by further advice from Accessibility Professionals to use assistive technology (AT), like screen readers, as integral components of their quality assurance tools (This isn’t to imply you should not be using AT during testing, just that this shouldn’t be the only way you guarantee your product is accessible).
The problem with this approach makes it seem as though in order for something to be accessible, it must work with whatever type of AT they’re testing with. I’ve had clients tell me that their sites aren’t accessible because it isn’t reading correctly in JAWS. Developers have a difficult time comprehending how a tool — which they’ve been instructed to use for testing — expects you to do something wrong and thus tries to mitigate this by “fixing” your mistakes before even you make them.
While they are very important for testing, screen readers are not testing tools. To be honest, people with disabilities are not running around with AT checking to make sure websites and software work correctly. They’re using it as a means to overcome a technological barrier that would normally keep them from doing something you and I take for granted.
Limiting accessibility to the quality level of a project is a detriment to the entire project. Relying on delivering a project based on whether something works with assistive technologies misses the entire point of how to make something accessible in the first place. Why? Because it leaves it up to the Quality position who is there to tell you something is wrong so you need to go back and make it work correctly.
It’s Both a UX and a UI Problem
People in my field love to tell Designers and Developers that accessibility is a User Experience (UX) problem, but getting your project to work with AT is better thought of as a User Interface (UI) problem. When you place accessibility in the testing phase of a project, you ask the question framed above, “If I make it work this way, what will happen?”. This question becomes framed around an idea of how the UI will interact with the AT tools used to ensure it works. When someone tests it later, the question they’re asking is , “What will our experience be after using their design?” Therefore, UX is only considered after the product has been built.
The flaw with this approach is that it makes it seem as though something isn’t working because it wasn’t properly tested before it was deployed. The burden here is solely on making sure your products are test correctly to ensure they work with AT. Making stuff work with AT doesn’t address the underlying problem that something was wrong in the first place. Working with a screen reader is essential, but tweaking individual UI components to be able to interact with it is rarely going to provide any kind of experience beyond frustration.
It’s More Accurately a Process Problem
Keeping accessibility within the testing phase traps it as a project problem. The Project Management Institute defines a project as a “temporary endeavor undertaken to create a project, service, or result.” Since projects are unique by their definition, it stands to reason that the same flaws and risks are bound to be repeated because testing for accessibility is the only place flaws and risks are going to be identified. When it remains at the project level, nothing changes to prevent it from becoming a problem in the first place.
In my opinion, the question Designers and Developers should be asking is, “What’s the best method to employ so my users will react to it the way I expect them to?” To be able to arrive at that answer, accessibility needs to be taken out of the context of making it work for a specific implementation and more about doing things according to the theories of development best practices.
Developers and Designers should begin to understand that accessibility is not a project problem, but a process problem. A process can be defined as a series of actions or steps taken in order to achieve a particular end. When considered as a process, the conversation becomes addressing the behavior that’s employed to perform an activity.
The Approach Needs to Change
The benefits of changing the way someone designs or codes using best practices removes the burden of relying on proper testing by creating a fundamental improvement throughout the entire design process. When Developers and Designers change the behavior of how they code or design, the benefits become meeting goals on time, on budget, and within scope regardless of how many unique projects are managed.
Testing is still an integral part of any software development, and using AT to test is a damn fine way to ensure that your stuff works according to spec. However, in order to address the accessibility needs of ICT, all stakeholders on a project need to take ownership of making it work out of the box. By using solid, proven techniques to design and code, the end product has a better chance of standing up to tests performed later in development. If the Quality Assurance team works intimately with the Developers and Designers during the project planning phase, known issues can be addressed in real time in order to tie up any loose ends. Making sure risks are addressed from the start will mean that there will be fewer critical flaws that surface during testing.
This becomes especially critical when products are deployed that might not have even considered accessibility whatsoever when designing them. This is true because common sense best practices include following the specifications, recommendations, and guidelines of creating ICT. If your UI is constructed correctly the first time around, it’ll most likely cover the basics of how it interacts with other technology — be it a browser or assistive technology.
Think about it. After H&R Block got sued for having an inaccessible website, the settlement didn’t include ensuring that it worked with assistive technologies, but rather that it used specifications and guidelines that had long been in place before they even got sued in the first place. If they had just used the proper best practices to begin with, it wouldn’t have been such a costly mistake to make.
If we want to change the behavior of how someone approaches this problem, the approach needs to change. Leaving accessibility problems to surface only after everything has been built is a horrible way to develop a product. By making accessibility an organizational process improvement, the experience of using a product has already become a defined approach.
