Talking with clients & potential clients is always tricky. The last thing I want to do is offend someone, but there are some things I wish I could say up front and with frankness. As the saying goes, sometimes the truth hurts, so in the interest of politeness these messages are often skipped or glossed over when in reality the importance of these deserve the clarity that forthrightness provides. Not inspired by any one specifically but rather everyone generally, here are 10 blunt things I wish I could tell clients.
1. Your staff knows much less than they think they do
Luckily I’m often in a situation where clients are already at least aware of accessibility’s importance and may even have some staff who are interested and experienced in accessibility. It is rare, however, for those staff to have much depth to their accessibility knowledge. In fact, in skills assessment surveys I’ve performed in the past, participants who had a high degree of confidence in their skill level with respect to accessibility still scored no better in the knowledge portions of the surveys than those who had the lowest degrees of confidence. In other words, they don’t know what it is that they don’t know. These staff members should be praised for their interest in the topic and encouraged to expand their knowledge, but it is also important to keep in mind their inordinately high level of confidence when making decisions about accessibility moving forward.
2. There’s no such thing as too early for us to start
Usability and accessibility consultants often lament the fact that we don’t get to work earlier in the design process. Often clients come to us after a system has been deployed and want an audit performed on the system. While I’m certainly happy to have the work, happy to have a client interested in making their system accessible, and happy to do everything I can to help, I always wish they’d made this decision earlier. There are many opportunities in a project’s lifecycle where decisions are made that will impact the system’s accessibility and the further down the road the project gets, the more likely an irreversible decision was made that impact’s accessibility. In most cases, we’re still able to make huge improvements to the system, but as with any other quality issue post-deployment remediation is more costly than avoiding the issues in the first place.
3. You should view my report as a learning document, not a defect list
One of the more frustrating things about doing audit reports is that they’re so often regarded as defect list. It is as if management staff dissect the report, turn it into a list of issues, and then set the development staff on the task of resolving the issues. That’s awesome, but that’s only part of what needs to happen. In order to be truly successful with your accessibility efforts, your team will need to review the report in its entirety to determine what issues constitute actual anomalies vs. inaccessible production patterns. From there, they should determine what new techniques must be adopted so that they can avoid repeating those mistakes in new code. This way, the next time your systems are reviewed, the new report isn’t just more of the same thing we’ve discovered already.
4. Your team might create a cool UI that meets business needs, but they still lack basic knowledge
Most web developers, myself included, are self-taught. What we learn is based purely upon what we need to know in order to get the job done. For instance, I started learning PHP over a decade ago because one of my early websites had a web form on it. That form was later expanded to go into a database. Later I had to take payments over the web. As time went on, I learned more and more. That expanded into things like Java, Flash, JavaScript, JSP, etc. all based on a specific need. Developers typically create accessibility issues on websites because they don’t know about accessibility. But there’s more than that. They don’t know accessibility because they often don’t understand even the basics about the DOM. In review after review, I find many accessibility issues relating to UI components that are created to have a specific appearance and operation without understanding the underlying objects they’re working with. Though it may offend them to hear, what your developers most need is training – not just in accessibility but in proper standards-based web development.
5. Your QA staff is unprepared to handle accessibility testing
When you think about testing your systems, the group which seems to make the most sense to do so is QA. Indeed these are the people who should be doing it. Unfortunately, QA staff are often unprepared to handle this task. This is for two reasons. First, a lot about QA is very objective – either the system passes a test or it does not – whereas there’s a lot of subjectivity in accessibility. This brings up the second reason, which is that successful accessibility testing requires both a knowledge of accessibility and at least some development knowledge. If you don’t plan on having dedicated internal subject matter expertise in accessibility, you really need to strongly consider training QA staff in both accessibility and basic web development.
6. An automated tool isn’t a substitute for knowledge
A long time ago, I worked the parts department of a Harley Davidson dealership. One of the mechanics, whom we called “Old man Brian” had a saying: “It is a poor mechanic who blames his tools”. I’ve written a handful of posts about automated tools, each favorable regarding their efficiency and ability to assist in testing large systems. That said, a tool is only useful when operated by someone who knows how to use it. This means more than just in understanding the tool itself but also the results it provides. The tool’s users must be able to effectively generate accurate, reliable results and translate those results into actionable guidance. Without that ability, the tool loses all value. The bridge for this gap is training.
7. “Waiting to get sued” is foolish
I am frequently approached at events by people who complain that their employer doesn’t take accessibility seriously enough. The reason most often cited? “They’re waiting to get sued”. In other words, the organization doesn’t plan to expend any serious effort or money on accessibility until they’re forced to. On the surface, this seems to be sort of business savvy, right? After all, why spend money you don’t need to? Here’s why (borrowed from my friend & co-worker Elle Waters): Would you rather spend your money on your own timeline or on your plaintiff’s timeline? I don’t believe in selling through fear, but it is important to recognize that certain organizations do have real risk exposure. For any organization that faces a high litigation risk, waiting to get sued is just plain foolish. You can save a lot of money (how does $6,000,000 sound?) by being proactive about accessibility now. Take an honest assessment of where you are now and prioritize you efforts to work on your timeline, lest you be legally compelled to do so on the plaintiff’s timeline.
8. Your first step after you get my report is to deal with internal roadblocks
“Fixing this will take a long time”, “That’s part of a third party’s code, we can’t fix that”, “This is going to be hard”, “This will negatively impact X Project”. These are a few of the myriad excuses that may be voiced by developers when they get an initial glance at their accessibility audit. Sometimes these comments are well-founded, especially in systems that have egregious errors, but such instances are actually rare. Usually these statements are exaggerations born from ignorance, fear, or lack of buy-in. They may be attempting to over estimate the complexity to avoid new accessibility requirements. Whatever the case, naysayers need to be dealt with as urgently as possible. Left unaddressed, naysayers will become like a virus, infecting everyone within ear shot every time the topic of accessibility enters conversation like a game of telephone where the message is purposely distorted.
9. Outsourced labor may be your biggest long term roadblock
One of the bigger accessibility struggles my clients face is rooted in the choice of outsourced labor. Most of the potential problems with outsourcing software development are already well documented. When it comes to accessibility, the biggest issues with outsourcing are control, continuity, and knowledge. With outsourced labor, you won’t have the same level of control that you have with internal employees. This means you cannot control specifically who does the development work which, from an accessibility perspective, means that the developers may or may not have experience with accessible development. This also has implications for continuity. When you have little direct control over how the outsourced labor is managed, you may likely have instances where resources are shifted without your control. Developers who you may have worked with to improve the accessibility of your systems may be gone without notice, replaced by new developers who have zero accessibility experience. Even if you stipulate in your contracts that deliverables be accessible, that stipulation may not be followed and with project deadlines and budget pressures, compelling them to remediate after the fact may be quite difficult.
10. The big report I give you isn’t the end of the world
I get paid to deliver an accurate, complete, and thorough assessment of your system’s accessibility. If you’re like most clients, that means several dozen pages of detailed findings outlining scores of accessibility problems. At first glance, it is easy to understand that you or your staff might feel overwhelmed. The good news is that you’re not alone. An unfortunate truth is that most of the web is inaccessible. At least you’re taking action to improve your accessibility. So up front, you deserve my praise for even going down this road. After receiving my report, I’d be doing you a disservice if I just left you high & dry with a big scary report and no support afterwards. Together, we can collaborate on an approach to dealing with your system’s accessibility issues in a way that creates the biggest positive impact for users with the lowest cost, effort, and time. From there, we should continue by introducing new development techniques to your team that will help avoid problems in the future. My report isn’t the end goal for me, your success is my goal and I will work with you to make that happen.