Accessibility Prioritization: Your Tactical Roadmap [Part 2]

View non-AMP version at deque.com

In the post I published a few days ago I shared how to  efficiently create a strategic accessibility prioritization plan.The strategy is based on the fundamentals of  defining a standard and identifying core digital properties and functions of your business.  – in order to help you understand how to prioritize what to fix first. Now that we’ve laid the groundwork for your accessibility strategy, it’s time to move on to part two: the tactical roadmap, which will outline the specifics of prioritization for your development team.

These are some common issues and questions raised by developers who are tasked with successfully completing an accessibility remediation project::

What if our development team has no experience with accessibility? Do we go about it page by page? How do we know what the most critical issues are? How does all of this factor in with tight deadlines? Most importantly, how can we create a workable plan to resolve all the critical issues that won’t burn out our already stressed development team?

I’m going to address all of these issues in this post (part II of understanding accessibility prioritization), with tactical tips to get your plan in order.

Your Tactical Guide: What Should be a Priority?

I suggest that your development team break down the core functionalities into different stages of prioritization. The best way to do that is like this:

1st Priority – fix site-wide templates (commonly used header, footer, navigation, sidebar(s))

2nd Priority – fix any reusable components (like a date picker or a video player)

3rd Priority – fix individual page elements (content that is unique to a page)

Keep in mind, this isn’t an ironclad rule. If for some reason this method doesn’t work for you, by all means you can be flexible. But the reason I strongly recommend prioritizing this way is that the first two priorities gets your core assets accessible. Why is it so important to fix templates and reusable components first? Simply because it sets a precedence and helps those further down the line understand that you have an accessibility plan in place – and it’s already underway. If you don’t fix the templates and reusable components, it’ll be pretty demoralizing to a developer downstream who can only fix items in the main div of the page. Plus, accessibility issues in the template make it impossible for a person with a disability to use the page.

Make Sure you’re on the Right Path

Now you’re going to look at key path accessibility elements. As your focus moves from site-wide components to user paths, choose the most critical user paths and the highest traffic pages to work on. You need to attack the critical pages first. These are key entry points.

Where do most people enter your site? This might be your homepage. Or if you have an online banking site, for example, it could be the login to your account page. Next you need to think about the key user paths. What are the most common paths users take while using your website or mobile app? If we’re sticking with the bank analogy, this might be the “pay my bill” or “transfer funds” page. After those are completed you’ll work on pages receiving the highest traffic volume.

While you’re prioritizing pages, it’s important that you think of them from an accessibility perspective first. Don’t just look at it from your organization’s viewpoint; or you could end up heading in the wrong direction. Your team should really be asking, “what key information and functionality has to work in order for our site to even be useful to an actual human being?”

And don’t forget to address the obvious, like feedback and contact forms and any pages on your accessibility policy or standards or issue reporting. Those all need to be accessible, too!

Common Questions & Concerns: Which Issues to Tackle First

Now we’ve reached the all-important Q&A section. Because despite the fact that this plan is mapped out fairly clearly, for development teams there is often still a lot of uncertainty when it comes to understanding the logistics of prioritizing specific accessibility issues. Here I’ve isolated the most common questions and concerns that the dev team might have with regards to the best route for resolving these issues.

Do I have to fix every issue?

The honest answer: Well, yes, you really should. But try not to let that overwhelm you. If all else fails, go ahead and fix what you know you can – the big barriers that are so huge as to render certain functionalities completely inaccessible or unusable if you don’t. Because as much as we’d like to see all our accessibility problems resolved right now, for many development teams this may simply not be an option. There may not be the time, resources, or manpower to make that an immediate reality. Instead, you can refer back to your strategic plan and progress report and do it in phases – starting with core functionalities and critical/serious issues first.

Should I be attacking these issues page by page?

It’s important to be flexible, so do what works best for you. I often start attacking problems based on user impact. I’ll ask, “how much does this issue hurt people with disabilities?” Volume is also a factor. And by volume I mean the issue that occurs most often on a website or mobile app. But again, just because this is the way I like to tackle accessibility issues doesn’t mean that you have to go about it the same way – one size doesn’t fit all! There’s no correct recipe here, just well-informed advice that you can chose to follow as it fits your situation.

Should I fix every issue on the page I’m working on now? I won’t make the deadline if I do!

The ideal situation is to fix every issue on the page, simply because if you don’t, it’ll come back to bite you later. If, say, you only fix a few issues and then return 6 months later to fix the rest, it’s a lot more time-consuming. Then again, not every company or development team has endless resources. So if you can fix the most important issues and breakdown barriers on critical components, then you are making progress.

If you’re really under tight time constraints, go back to “what should I fix first?” and  focus on the templates and reusable modules. Next tackle key user paths and pages, then go for the critical issues and serious issues, save moderate and minor issues for last. You’ll have to go back and fix the remaining issues when time allows in phase two, and remove or archive the rest.

Also keep in mind that the highest priority issues are based on the severity of impact to users with disabilities. The method for prioritizing impact categories as critical, serious, moderate and minor. It’s the most pragmatic method for prioritization for the first wave of your remediation efforts. I can’t emphasize this enough – full compliance with WCAG 2.0 AA is the only accepted standard for accessibility.

Speaking of priority, while any worthwhile enterprise accessibility  testing tool  will let you tackle your accessibility problems by page or issue type, their specific testing parameters may vary. Our Worldspace Compliance tool allows you to sort issues by certain parameters, like success criteria and (my personal favorite) priority. Not all testing tools have this priority feature. Priority illustrates the impact this type of issue has on real people with disabilities. Personally I like to sort by priority and resolve all the critical and serious issues on a page first – that clears the major barriers out of the way.

Practice Makes Perfect! The Pilot Plan

It may sound trite, but the old adage is true: practice makes perfect. And when it comes to accessibility remediation, practice is essential to getting your team familiarized with the whole process – especially if they have no prior accessibility experience.

In automobile racing, it’s common practice for the drivers to walk the track in preparation for the race. A walking tour of the race track allows the drivers to learn the subtleties of the course, giving them a feel for the ideal driving line around each corner.

I suggest your development team do some “practice laps” before they actually begin fixing issues. That’s why I think a pilot project is so important. It can help your team understand and prepare for the road ahead (no pun intended). Choose a team that’s already motivated to learn about accessibility and pair them with an accessibility expert. Supply them with the training, the tools, an assessment and a few pages that need fixing. I guarantee after they complete the pilot project they’ll feel much more comfortable “on the road.”

Here’s the outline for a good pilot project template:

Pilot Project/Practice Laps

Select Developer Team + Pair with an A11y Expert

• Own key user path(s)

• Motivated to learn a11y

• Adventurous

Plan – Select 1-3 pages to make accessible

Train – Focused developer accessibility training

Equip – Installs a11y testing tools

Initial Assessment – Provide expert assessment and remediation recommendations report to the Pilot Team. The Pilot Team then reviews and interprets results with assistance as needed from A11y Expert.

Remediate – Pilot Team prioritizes a11y issues, fixes them and retests. Assistance as needed from A11y Expert.

Capture Learning – Debrief, document success, identify the areas for improvement and go over next steps.

Reality Check: Litigation Factors & the Power of Empathy

How do you know if you’ve made the right choices when you prioritized your accessibility projects? At the end of the day, imagine this scenario: You’re standing in front of a judge in a court of law and explaining your company’s current state of accessibility. You go over what you’ve already fixed, and have outlined for the judge what you plan on resolving next. Will you be able to prove to the judge that you genuinely care about accessibility, and you’re putting forth your very best effort to make your website or app completely accessible? Based on the project specifics you’ve outlined, will s/he be convinced that your plan for fixing the rest is both reasonable and logical? Furthermore, what will the judge think of the way you’re taking care of customers who need access to your services now, but don’t have it yet? If you were this judge, would you be convinced that this company (your company) is doing everything in its power to implement a viable, comprehensive accessibility solution?

Let’s take this role play one step further.  People who work in accessibility need to be able to empathize with the user who’s most affected by accessibility issues. Step out of the role of the business person for a minute. Put aside your company’s concerns, and pretend you’re on the other side of the table. Imagine that you were the one who didn’t have access to a critical functionality on your website. Ask yourself, “If I didn’t have access to this, how would I feel?” If your response is to shrug your shoulders, then the issue probably isn’t critical. But if your gut reaction is anger and frustration, then chances are the issue is a critical one that needs to be fixed immediately.

Now that I’ve laid the foundation and paved the way for a pragmatic approach to accessibility prioritization, you have a 2-layered plan that will help you create and implement the changes you’ll need to make. You’ll also have a better understanding on how to prioritize which functionalities need immediate attention, as well as the issues that should be fixed first. Now, let the race for accessibility begin…Ladies and Gentlemen, start your engines!