Instituting a Culture of Accessibility in Your Organization: Part 2

Part of the challenge of converting an organization and its body of work into an accessible one is deciding where to begin. Accessibility itself is not easily defined. It is a highly contextual spectrum of concerns and not a checklist of items from an off-the-shelf software solution.

Organizations and their projects are living, breathing things. This fact should always be kept in mind throughout the process.

Attempting a single, massive waterfall-style sweep to convert an entire company, products and marketing to some standard of acceptance can be overwhelming as well as disruptive. While smaller, more agile organizations or projects might more easily undertake such an effort, they too may place them perpetually on hold for some future time when “things are more stable.”

Navigating the hierarchy and creating a workable plan for teams to approach the project are two keys to success.

Be mindful of the pyramid

If it stems from the bottom-upward, finding support laterally in the organization is probably best. Begin by communicating the importance of the conversion to team members, peers, and immediate managers to build as wide as possible base of support.

Take an active role and draft clear, easy to achieve tasks with highly visible and easily explainable benefits. An example of this would be to identify places where animation is used on the site to see if they use flashing or strobing effects. By cataloging the jarring animation, you’re creating an easily accessed, centralized list of all known seizure trigger risks.

Interested supporters can pitch in more easily, and higher-ups can understand and appreciate your efforts. If negotiation with superiors is necessary, a shared common understanding of the benefits helps.

If accessibility is a top-down concern, a goal-oriented approach might be better. Executive sign-off has leverage from the beginning, making it an easier scenario to enact. Or so it would seem.

Such an effort may suffer from frantic action or misunderstood or miscommunicated orders. Truth is, top-down accessibility concerns tend to originate externally, such as from customer complaints, lawsuits, or contractual obligations.

Disseminate an accessibility plan to project managers and team leaders and, like the bottom-upward approach, make sure to clearly outline the importance of desired outcomes. WCAG compliance criteria provides is a nice list of targets to shoot for.

Unlike a bottom-upward approach, a top-down effort will probably be more goal-oriented. The temptation might be to treat these accessibility goals like a completed item on a checklist. Teams need to make sure that conversion efforts aren’t just a half-measure—be sure to keep the momentum going once the immediate concerns are met.

If the accessibility concern originates mainly from an external groundswell—be it from prospective or existing customers or the larger population—take additional care. Your organization will likely be viewed as a single entity and interactions with outsiders—particularly criticism—will reflect on your organization as a whole.

Be careful to communicate that voiced concerns are being addressed in a timely and proactive manner. Failure to properly deliver this message can be just as damaging as apathy or neglect. Use your organization’s messaging platforms to communicate accessibility changes, with some care to delivering the news to the individuals who voiced the concern originally. Don’t forget that that support articles, trainings, call scripts, etc. will need to be updated in a timely fashion.

Eating the elephant

Navigating the org chart can be tough, but figuring out the second part—tackling the problem itself—presents difficult issues of its own.

The first step is to get a grasp on the state of accessibility in your organization. Conduct an audit that will create a snapshot of your products and list of accessibility concerns that need to be addressed. This typically is done by hiring an external vendor.

The audit should help you identify high-risk areas and break down fixes for them into a roadmap of small, easy to understand tasks that can be disseminated to relevant departments and teams.

Compliance tasks often come with a significant shock factor when first unveiled. A heads-up to managers goes beyond mere courtesy, as it allows them to adjust accordingly for the task at hand. Be sure to include the reasons why these tasks are being undertaken and supply any relevant supplementary information the team may need.

It’s worth noting that high-risk areas aren’t necessarily high-effort areas. Some of the most common accessibility issues aren’t obscure coding tasks that can only be performed by specialized developers. Notable low-hanging fruit includes ensuring that:

Images have alternative descriptive text, a feature of most modern content management systems

Links lead to the correct location (automated tools can help with this)

Content is easy to scan and interactive elements aren’t too small

Search and contact information are readily available

To stay organized, have employees report issues to a centralized issue tracker. Repeating patterns in reported issues are usually telling of a programming issue that can be fixed upstream. Develop easy to follow, non-technical instructions for easier fixes and begin assigning their parent issues to the teams whose strengths are best suited to tackle the challenges.

These steps can help build a solid foundation for accessibility efforts within your organization, not just for short term gains but long term as well. The idea is to bake it into processes and eliminate the need to constantly revisit the issue every couple of years.

Curious how to tackle the nitty-gritty? Want to know how to best utilize your developer and designer efforts? In Part III, I will be discussing specific ways implement accessibility testing, and how to make sure the effort survives long-term.