“Accessibility is not a bolt on.”
Have you ever heard this quote? It means accessibility is first considered at the end of the development lifecycle, or worse, once the application or website has been released to production. While this isn’t ideal for any organization, it’s an unfortunate reality where many enterprises find themselves on their quest to be accessible to the core. Microsoft has been no exception.
At Microsoft, the journey to becoming an accessible organization has been a fundamental mind shift for internal teams who in the past may have not considered if their new application, website or product feature could potentially encounter accessibility issues. Many times, when asked what testing had been done to minimize this potential, most developers would frequently stay silent or provide a simple response of “none.”
Why does this happen? The reasons can be multiple and intricate. From general unawareness to seemingly complex accessibility guidelines, there may be new standards, legal requirements or new technology features taking priority. The change in approach and practices for incorporating accessibility in the coding and release process can be difficult to adopt, inherently making accessibility a bolt on.
On the last accessibility blog, my colleague Beverly Carey shared the importance of fostering an inclusive culture at Microsoft through accessibility, and the “considerable challenge” it was to getting started. Indeed, ensuring everyone has access to our technologies is a formidable journey. In this blog, I will share the steps we’ve taken at Microsoft to help address the “bolt on” behavior.
The When. The Where. The How.
Incorporating accessibility into the build decision with suppliers and partners is an important first step. At Microsoft Core Services Engineering (CSE, formerly Microsoft IT), we’re accountable for the technologies we develop for our customers, partners, and employees. Making our portfolio accessible means ensuring that criteria is included in contractual agreements for SaaS or PaaS solutions delivered by our suppliers. Enterprises looking to supplement their engineering teams with suppliers or strategic partners to develop custom or configured solutions, should include contractual requirements for accessibility. This sets the priority for contracted service providers to develop knowledge and skills in accessibility, and ultimately deliver accessible solutions.
It’s also important to establish a compliance review process and, in some cases, incorporate service level agreements tied to the financial aspect of the supplier contract, effectively laying the foundation for a commitment to accessibility. I have personally been involved in contracting and procuring third party products within our organization and can tell you that this process doesn’t need to be overly complex, it just needs to be made part of the contract discussion.
Defining where in the process to start incorporating testing is a critical second step. We learned it was best to start as early as possible. Today, we’re incorporating accessibility into business and design requirements, testing design concepts with individuals with disabilities, and specifying accessible components in the design specifications. Design requirements is what sets accessibility in motion. If enterprises don’t require their applications and sites to be accessible for all users, then they shouldn’t expect them to be. Design requirements, at a minimum, forces a conversation about what accessibility means at that definitive stage in the lifecycle. Testing the designs with users with disabilities provides specific and explicit feedback on areas of the design that are particularly challenging and provide valuable insights into how these individuals navigate, understand, or interact with the application or website. This takes accessibility beyond minimum compliance with guidelines and standards. Designers and developers should specify components that are accessible when selecting components from existing frameworks. The Microsoft Web Framework is a good resource as they test their new components against accessibility guidelines.
Integrating accessibility into the development and test cycles is another effective tactic. At Microsoft, we use Visual Studio Team Services (VSTS) as the primary development workflow environment. Our team is also regularly working to integrate more accessibility plug-ins which prompts our software engineers for possible issues and recommendations for actions to consider as they code. The more we integrate accessibility tools into the coding and testing process, the better the chances that accessibility issues will be identified and fixed before getting released to production.
Enterprise IT teams should focus on standardizing tasks, driving the use of accessibility coding, testing tools, and plug-ins not just for accessibility but other critical requirements such as security and data. Depending on the size of the organization, integration can be done manually or through automation into the development workflow environment. In most cases, this will require a mix of both automation and manual intervention. Integration also enables reporting on how teams are planning and executing accessibility-related work throughout the development lifecycle. Making plug-ins available for testing allows software engineers to check for accessibility issues at the time of code check-in or during release testing. While these testing plug-ins can’t check for everything, they will help reduce the number of manual tests that need to be conducted and speed up the testing process.
Incorporating accessibility into the business workflow and technology decisions is the best way to get started on the path to becoming an accessible organization. Start as early as possible in the lifecycle to ensure accessibility is considered. Ensure accessibility business and design requirements are included up front, promote and integrate accessibility coding and testing tools into the workflow environment, and watch your organization begin to break down barriers and go from “bolt on” to built in.