If you're a technology provider, an established accessibility initiative will help ensure that the information and communications technology (ICT) you build and implement is accessible to all workers, job candidates, and customers.
If you're a technology provider, an established accessibility initiative will help ensure that the information and communications technology (ICT) you build and implement is accessible to all workers, job candidates, and customers. To be sustainable, however, your initiative should be guided by formal policies that have both clout and clarity. Such policies will provide every individual involved (whether on your team or hovering in the background) both guidance and a green light for moving ahead in the context of the initiative's–and company's–larger goals.
Below are some examples of the kinds of policies you may need to put in place. Above all, make sure your policy is meaningful and actionable–not boilerplate text and fluff.
Product Development
No matter how you build your products, you probably have informal or formal processes with written steps and responsibilities. Accessibility naturally fits in somewhere among these, but exactly where depends on your company's unique practices. For example, if you use feature specification documents (FSD) in your product development lifecycle, there are many sections within those to address accessibility. For instance, your test plans can refer to recruiting users with disabilities, including those who use assistive technology. Testing results may then feed into a gap analysis with a separate accessibility section, or include accessibility-related findings in other sections. Regardless of what tools and processes you employ, your product development policy should be as explicit as possible, indicating exactly where in the process accessibility will be factored in. This should then be accompanied by samples of development documentation.
Roles and Responsibilities
Depending on the structure of your organization, accessibility staff may be a centralized resource called upon by all product teams as needed, housed in product teams themselves, or somewhere in the middle. In any scenario, accessibility staff and team members should be assigned specific functions and given the resources necessary to perform them. Similarly, accessibility responsibilities should be included in performance reviews. Too many organizations have tried to implement accessibility as a hobby performed by a few energetic advocates—which doesn't work well in the long term. Staffing policies should ensure the right people are in the right places, with the right responsibilities—and get credit for the work they do.
Budget and Resources
Similarly, other resources need to be authoritatively assigned. Obviously a key element in planning your accessibility initiative is budget, which may need to reflect capital costs such as additions to a usability lab, total staff costs, and expenses for each product you work on. Your budget policy should spell out such line items and include a brief explanation of their value.
Training
Staff training is probably the most important part of your accessibility initiative, and should serve both motivational ("why are we doing this?") and operational ("how do I do that?") goals. There's value in giving everyone a taste of the former, especially if made relevant to larger organizational goals. "We're working on making our XYZ software more accessible because one of our largest customers has asked us to–they have 120,000 employees who use XYZ every day, and thousands of them are having difficulty." Sharing such statements builds a focused cultural consensus that vague references do not. Operational training should then be carefully planned to address specific roles and responsibilities. Managing this training effort should be part of your overall training function, as should decisions about when to develop your own materials and when to use the wide range of options available externally. Your training policy should address both general and specific training needs, goals, methods, and coverage.
User Needs
Clearly, a focus on accessibility has no value if it doesn't meet the needs of technology users with disabilities. But which needs? It's possible to be misled by advocacy messages coming from every direction, all of which urge immediate action. If your accessibility initiative is to have strategic value, it must be able to decipher such messages, evaluate potential responses, and prepare a roadmap that is not only feasible and defensible, but also exciting and innovative. At one end of this spectrum you may be attending a grassroots disability event at which technology issues are being addressed; at another, you may be reviewing a legal analysis of a customer's accessibility requirements. Your user needs policy should express the wide range of activities you will use to gain market intelligence—and what you will do with it.
Communicating with Suppliers and Tool Builders (Up the Value Chain)
Most ICT providers use components (hardware or software) and tools provided by other entities. You can dramatically simplify your accessibility work by requesting–or requiring–that your upstream suppliers support your accessibility goals. For example, software and web developers often use third-party media players rather than build their own. Requiring a player to have the ability to decode and render captions, and have all the play controls exposed and accessible, not only gets you the end product you want, but also sends an important message to the supplier. Your accessible supply policy should focus on how you communicate your input needs and how the policy will affect your purchasing decisions.
Communicating with Distributors (Down the Value Chain)
Many ICT providers don't sell directly to final customers and end users; they rely on distributors, system integrators, and value-added resellers to travel that last mile. But beware—it's very easy for your accessibility work to disappear in that mile! For example, a public sector agency may request a Voluntary Product Accessibility Template (VPAT) from one of your distributors. If the sales team doesn't know what a VPAT is, how to get one from you, or how to put the customer in touch with your accessibility team, they (and you) may lose the sale. Your accessible distribution policy should cover how you will document and communicate accessibility—all the way to end users.
Continuous Improvement
There are many ways to measure the outputs and outcomes of your accessibility initiative, and then use those metrics to improve the program, no matter how small or informal it may be. The more you learn about your effectiveness, the more efficient your accessibility work will be. Your policy on continuous improvement should cover the metrics you will use, how you will use them, and how the results will drive changes in your program.
From product development to plans for improvement, clear and credible policies are critical to the successful start of your accessible initiative–and its sustainability for years to come. So get started today!
