Where is the best organizational location for Accessibility?

Accessibility is the little red hen of the business world. Almost everyone wants the accessible experience, however, not everyone wants the responsibility of making that happen. Complicating matters is that not all potential locations for an accessibility team are the best fit. I have worked with people with disabilities for more than 15 years, and in each organization, the accessibility team has been in a different part of the company. Here are some of the places I’ve seen Accessibility located, along with pros and cons.

Compliance / Legal

Compliance / Legal are probably my least favorite organizational locations for accessibility. Compliance is the IAD of the business world. Everyone hates them automatically, and no one gives them any respect for the positives they try to bring to the organization. In a carrot and stick world, compliance is a big muddy stick with a pointy end.

On the plus side, compliance is good for audits, particularly for external contracts, procured goods and services. Additionally, legal is good about making sure that accessibility clauses are included in all goods/services contracts. But the accessibility team doesn’t need to be located in either of those two areas if you can build those relationships from elsewhere.

Also on the minus side, compliance and legal are rarely close to technology. Locating accessibility in either of these organizations will likely either slow down the software release process substantially, or most accessibility issues will get discovered post-launch, which is expensive and will disrupt future development.

Diversity / Inclusion

Diversity / Inclusion does (or *should*) include disabilities as part of their mandate. Seems like a natural fit, right?

On the plus side diversity / inclusion can influence accessible choices for internal tools and anything else on the administrative side of the world such as procurement, reasonable accommodations, and recruiting.

However, there are several issues that may more than offset the benefits. Frequently disabilities are not represented in D&I at the same strength as gender, ethnicity, sexual orientation, and other more traditional components of the D&I domain. Also, Diversity / Inclusion, while close to administrative functions, is typically far removed from IT, and D&I staff frequently lack the necessary technical skills to drive accessible development.

Technology

There are several potential locations for accessibility in the technology side of the organization. One caveat with all technology locations is the accessibility team may not have a significant amount of influence over administrative functions, procured tools or accessibility outside of code that the Technology department owns.

Design / UX

Of the technology choices, design / UX may potentially be the best location for accessibility. All good, accessible digital properties start with an accessible design. Having a strong accessibility component in the design organization will help ensure that people with disabilities are accounted for in personas. UX is another potential location for accessibility. In some organizations, UX is part of design, in other (usually larger) organizations it can be a separate department. UX is typically responsible for focus groups and user interviews and can make sure people with disabilities are specifically recruited for these important functions.

Another important aspect of including accessibility in Design / UX is that a hand-off document identifying all non-visual accessibility affordances, along with coding requirements and cues should be included with every comp. This would include things like skip to content links, ARIA overrides for “learn more” links, header structure, alt text, etc. That way, the overall accessibility of the end product is less dependent on how competent the developers are at accessible programming techniques — accessible design teams are effectively giving developers a cookbook to work from. This is especially important when designs are developed internally, but implementation of those designs is done by a third-party company which is frequently overseas.

Development

Development is another reasonable choice for accessibility within a technology organization. A development team that has a strong accessibility presence will be able to incorporate many positive accessibility programming practices such as:

· Unit testing for accessibility

· Code libraries / repositories of accessible components

· Integrating automated accessibility unit testing with continuous integration

The downside to placing accessibility in development is that if a design or functional specification has inaccessible elements, the design may have to be reopened after coding has begun. Having accessibility earlier in the process can reduce expensive rework.

QA

Accessibility must be tested in an intensive, hands-on manner. So, should the internal QA component of technology own accessibility? While it may seem a natural fit, there are several caveats. Accessibility is something that is very hard to slap on at the end of the software development lifecycle. Accessibility needs to be designed and engineered from the beginning, whereas QA typically starts mid-way or even towards the end of the SDLC. Accessibility defects can be prevented at the design or development stages and QA typically gets involved after those two are completed. Again, having accessibility earlier in the process can reduce expensive rework.

PMO

The Program Management Office is sometimes the default, catch-all location for business processes that don’t fit well in other parts of the organization. The nice thing about locating accessibility in the PMO is the PMO typically already has established relationships with all the groups that the accessibility team needs to work with. However, the PMO is generally viewed as a support organization. Its typical role includes prioritizing features, scheduling, perhaps release coordination, but for the most part their number one job is keeping people accountable. Most importantly, the PMO rarely has a voice in any go / no go decisions.

I get to pick !!!

Here are some questions to ask yourself if you have the option to influence where accessibility goes:

1) Where is the analytics group located? And do I like it there? At an abstract organizational level, analytics is very much like accessibility.

· Neither analytics nor accessibility come under any one segment of the technology organization

· Both analytics and accessibility processes cut across the entire development and deployment cycle.

If your company has a well-established and highly functioning analytics group, you may be able to leverage that group to jump start your accessibility cross-functional business relationships, which will be somewhat similar.

2) Where is the root cause of my company’s accessibility problems?

The closer you are to the problem, the easier it will be to contribute to the solution.

Conclusion

There is no perfect corporate location for accessibility. There are good places, and not so good places. No matter where the accessibility team exists, the success of the team will require the manager to establish many cross-functional relationships to help bake accessibility into the DNA of the organization. The important thing to understand as the leader of an accessibility organization is where those bridges need to be built to mature the accessibility function over time.