Guidance
A Roadmap for Organizational Accessibility for Large ICT Vendors
If you ever really want to understand something, try to change it—Edgar Schein
You may have an interest in making your information and communications technology (ICT) accessible, but what needs to happen in your organization in order to make sustainable changes that ensure your ICT remains accessible in the future? (Fixing website accessibility is a worthy initial step. But, changing processes, procedures, providing training, and tackling organizational culture needs a roadmap.) So where should you start? We provide step-by-Step guidance that begins with establishing executive support for accessibility program efforts, and ends with implementing and monitoring new organization-wide accessibility initiatives.
This guide was developed as part of
The Accessibility Switchboard Project
from the
National Federation of the Blind Jernigan Institute
January 2017, Version 1.0.
Creative Commons License: CC BY-SA 4.0
Introduction and background
Who’s making and who’s buying accessible ICT?
Electronic interfaces and content are not inherently accessible to people with disabilities. Suppliers have to purposefully choose to include accessibility features. Currently. there is a steady growth in the number of Information & Communications Technology (ICT) vendors who are including accessibility as a feature of their mainstream products.
In the past, demand for accessible ICT has been driven primarily by government procurement mandates such as the US federal legal requirements in Section 508 of the Rehabilitation Act. Over time, many state agencies have also voluntarily adopted Section 508. Currently, the US Department of Justice (DoJ) is in the process of establishing rules for mandatory adoption of a Section 508 equivalent for state and local government agencies, as well as extending the same type of rules to businesses covered by the Americans with Disabilities Act (ADA) of 1990. (The ADA prohibited discrimination in the provision of services and access to public areas of physical buildings, but it preceded the commercialization of the internet in the mid to late 1990s and ubiquitous hand-held computing in the mid to late 2000s. An update of the ADA in 2008 did not extend the provisions to cover services provided electronically, and hence the recent regulatory activities of the DoJ.)
So, legislation specifically targeting business is now under development. But why is legislation needed?
Advocates have made the pitch to “to include the missing 20%” as a means to expand a company’s target audience / market (see the ‘Go In-Depth’ section at the end of this guide). At face value, it would seem that around ‘20%’ should be a compelling enough reason for companies to be inclusive in their design practices. (We say ‘around’ because the figure is plus or minus some percentage points, depending on how you measure the population, and how you define the term ‘disability’. But, even an error of -5% would still encompass a sizeable portion of the population.) While numerous companies have made improvements in their ICT accessibility—by following published advice, and/or enlisting the support of expertise of accessibility consultants, academics, and non-profit groups—such practices are still far from the norm in mainstream business. It is apparent that many in industry either feel that making changes to make their ICT accessible is too difficult to achieve, or they perceive that doing so would diminish the appeal or otherwise negatively impact their products.
The collective experience of companies that have progressed in making their ICT accessible, the majority of US federal government agencies, and many state agencies, have demonstrated that meeting accessibility requirements is readily achievable. This experience has provided justification for legal actions under the ADA and under Section 508, that have been brought against companies and federal and state agencies that have chosen to ignore, or have willfully opposed complaints about a lack of accessibility in their ICT. For these organizations, the ‘expanded market’ wasn’t sufficient, and the ‘readily achievable’ case wasn’t sufficient as a self-motivator. The net result has been the call for, and the actions towards, the DOJ’s process of updating regulations.
More and more organizations are buying or seeking to buy accessible ICT as a result of existing legislation and legal actions, the existing federal government demand, and perceived upcoming demand from state agencies and mainstream businesses fostered by upcoming legislation. Consequently, more vendors are, and will be, making accessible ICT.
This Roadmap Guide is intended for vendors of ICT, to provide advice on transforming operations to make accessibility a part of everyday business.
Making your ICT accessible
As a vendor of ICT, the elements of your organization’s ICT that can be made accessible include:
- The ICT products you develop and sell (software, hardware, as well as manuals and guides)
- Your customer-facing online presence (desktop and mobile websites, marketing, and social media postings)
- Your customer support mechanisms (telephone, online contact forms, and online chat support)
- The ICT used by your employees (computers and applications, telephone systems, building access security systems, intranet, real-time messaging systems, employee online training)
If your desire is to provide accessibility—for existing and potential customers and employees—then in order to overcome the problem that electronic interfaces and content are not inherently accessible, purposeful actions are required to ensure that ICT accessibility needs are addressed.
Once ICT accessibility needs are being actively worked on, documenting your efforts naturally follows. (A list of ‘known issues’ is helpful, but without documenting your efforts how would will generate such a list?) Subsequent to the administrative ‘checkbox’ of documenting your accessibility, the next steps can include promoting the accessibility the marketing of your products, including accessibility in product feature lists, detailing accessibility fixes in product release and update notes, and engaging with end users.
There is readily available development and testing guidance to help make your ICT accessible. The resources section of the Accessibility Switchboard website provides links to guides and other articles, and the support section provides links to people who can provide advice.
It isn’t just your ICT, it’s your development team and process…
A typical scenario, based on experience:
“We need to make our website accessible. Let’s hire a consultant to do it”. Jane the consultant makes the website accessible.
“Jane made our website accessible last year, but since then we’ve done four updates, and now we’ve been told that the site isn’t accessible any more. Should we hire Jane again? Or should we hire our own in-house accessibility team?” Frank, José, and Emily are hired as the website accessibility test team.
“Alright, we’ve got this new release just in time for the holiday shopping season. Oh yes, we have to send it to our accessibility test team.” The test team finds a large number of problems, meaning that the site will be inaccessible to deaf, color-blind, blind, and low vision patrons. The test report is given to the developers.
“We can’t do all of these changes in time for the release, which is due on Tuesday. Maybe for the next revision in January…?”
The mistake is to think of accessibility testing as something that is done by someone or some team that exists outside of the development team. When accessibility is treated as an add-on, or afterthought, companies rely on patch-style fixes. Their internal accessibility teams seem to be chasing their tails, and complain that they have limited impact on the accessibility of final products.
Quality control (QC) is deciding whether to ship a product. QC works best when people check to ensure that the product meets design specifications as it is being built, and this is called quality assurance (QA). For aspects such as security, look and feel, adherence to coding standards, etc., QC without QA can mean wasted energy as a result of a high number of rejections. The same is true for accessibility: if your company wants to assure your customers that your products are accessible, you need QA and its associated technical testing requirements early on and throughout development and testing, making QC sign-off a formality.
Case study: How Oracle implemented shared responsibility for accessibility
“The Oracle Accessibility Program Office, part of the central Corporate Architecture Group, is responsible for defining the corporate accessibility standards and serving as a central group of subject matter experts, including experts with disabilities. The office develops resources to educate the vast range of personnel involved with developing and maintaining Oracle products, including user experience engineers, developers, quality assurance testers, documentation writers, and support staff. This material is communicated in numerous ways, including formal training classes, moderated online forums, monthly newsletters, group meetings that include representatives of all the lines of business, and informal ‘brown-bag’ sessions. Educating the product teams on accessibility enables them to incorporate accessibility into their product development lifecycle in the most effective way, both for new development and release updates.”
From ‘Case studies of success’ (p.196) in Ensuring Digital Accessibility Through Process and Policy by Lazar, Goldstein & Taylor.
These days, tools and techniques are available for developing and QA testing accessibility as part of the mainstream ICT systems development lifecycle. Previous practices of having accessibility testing as a separate function are now being replaced by practices where mainstream development teams are tasked with including accessibility development and testing as a regular part of their work. There is still a need for a primary source of accessibility expertise and advice to be available to the developers, and that is the newer QA role of ‘accessibility teams’.
This model is being adopted because the costs are much lower for integrated models of operation. Having a separate team means additional staff for testing. Having existing development and testing staff take on accessibility tasks means additional training. The cost of initial and periodic update training is always going to be lower than the costs of hiring additional staff.
A resource for Getting started with organizational accessibility…
Strategic IT Accessibility: Enabling the Organization by Jeff Kline. This book provides background information and guidance for anyone wanting to make a start in organization-wide change. Specific guidance is given on organizational roles and shared responsibilities; and on funding accessibility initiatives.
It isn’t just your development team and process, it’s the user experience…
You’ve just finished a major project to ensure that your customer website is accessible. A short while later a phone call comes into customer support:
“Ah yes, can you help me? I’m trying to check out online and I’m not sure how to check the delivery date.”
“Of course, sir, I’d be happy to help. You see the red box in the lower right corner of the screen?”
“No, I’m blind. Red box and lower right don’t mean anything to me.”
“Why would a blind person be using our site? That makes no sense to me. I don’t think we can help you.”
Of course, management at this point would be doing a face palm if they knew. Who forgot to provide training to the customer support staff?
It’s good that you made your website accessible, but the website is only part of the customer experience. Beyond the technical standards conformance aspects of ICT accessibility lies the human (non-technical) aspects of interaction. Interaction design is part of any product development lifecycle, and including accessibility considerations throughout is going to lower the risk of those face-palm inducing scenarios.
The user experience also includes current and potential employees. You could similarly spend time, money and resources making your intranet and employee real-time chat system accessible, only to have hiring managers be unaware that this change has been made:
“Blind, you say? Really? Well, er… this job is computer intensive with lots of screens to deal with. How would you use a computer anyway?”
These kinds of scenarios are becoming less common as people generally become more aware of the capabilities of people with disabilities. Awareness of capabilities comes through education and training. But there is little use providing training and awareness for hiring managers if you haven’t assessed whether your intranet is accessible or not. The two are of course intertwined, which is why it is important to examine the process in terms of the user experience.
It isn’t just the user experience, it’s how your organization instills that user experience…
In its simplest terms, ‘culture’ is defined as what people say and what they do. The organizational culture changes when the things that people say and do changes. Like other equity and diversity initiatives such as gender, race, religion, and identity, disability initiatives require purposeful action to ‘level the playing field’ in the workplace. For example, it wouldn’t ring true to make public statements about how committed your company is to achieving ICT accessibility, but your staff to never see a colleague with a disability in the lunch room.
However, disability does differ from other diversity initiatives in key respects. Disability initiatives require that both physical environments as well as ICT are purposefully modified to become accessible. The situation is usually not level, however: while no one thinks twice in large companies about the need for disabled access restrooms, they might have to think twice and wonder whether their intranet time and attendance system is accessible.
The collective experiences of end-users (customers) and organization-users (employees) are defined by the choices made in the design and execution of systems. To make organization-wide efforts at creating accessible ICT, the available options need to be considered, and choices need to be made and acted on.
The Roadmap we have provided below is not the journey plan; it is an aid to be used in your own journey planning. The methods you choose to use to bring about change in your organization are going to be influenced by intrinsic and extrinsic factors. Available personnel, time, and funds will need to be determined, just as in any other project.
Here we provide directions based on the collective experience and expertise of the members of the Accessibility Switchboard Community Of Practice. This experience has been gained in working with many organizations that have sought to make similar changes to their ICT systems. On your own journey, it will be up to you to follow the signs, and to roll down the window and ask for help when needed.
This journey should involve stakeholders from across your organization. If you’re told to ignore this, and just fix the accessibility issues of the website, you may want to consult resources that help you overcome resistance to change. Additional Accessibility Switchboard resources, and links for going in depth for certain topics are provided at the end of this roadmap guide.
Step-by-Step: A Roadmap for Organizational Accessibility
Step 1: Establish executive support and strategy
A decade or more ago, it would be common to read about “accessibility evangelists” in companies. They would be the staff member bringing up accessibility at meetings. They would go to lunch with key stakeholders and talk about how nice it would be to make the intranet accessible. They would hold web and document accessibility training events and hope that people would show up.
Evangelists ask people to believe. Executives assign accountability and responsibility.
You don’t need accessibility evangelists on your staff; instead, you need executives who are committed to the strategy and who will help you and back you up when you need it. Without executive support, there won’t be any real consequences to the stakeholders who don’t want to be involved. (Trust our experience here… there will be stakeholders who don’t want to be involved. They will perceive any change as extra work to be avoided at all costs. You need to demonstrate to them that taking on accessibility assignments as part of their regular work is in their enlightened self interest.) You may designate an accessibility executive in the future, but initially you need one as high as you can go, and who doesn’t hold an accessibility title. They must hold a ‘getting stuff done’ title, like CIO, CTO, or even CEO.
With executive input, you need to consider your initial strategy. For example, should you concentrate on one business unit as your pilot program, or several business units at once. Remember that strategy is the high level thing you want to achieve, and strategy leads to plans and tactics (which are developed in subsequent steps). Strategies are never set in stone. If one strategy isn’t working, revisit it with the executives to modify or replace that strategy, or to counter any resistance. Also remember that it isn’t your responsibility to see to it that the strategy is effective and the staff are held accountable; it’s the executive’s responsibility. It’s your job to execute the strategy on their behalf.
Note: Step 1 might be best facilitated by taking some time to work on Step 2. If you have difficulty achieving the Step 1 goal of getting executive support, we suggest exploring more resources to build up your case, in Step 2.
Case study: How a theatre complex changed their corporate culture through one key question for their executives to employ
The Accessibility Officer at a large theatre complex had to get around the fact that executives did not have time to be educated on the A-Z of accessibility. She attempted to change the way things worked by having executives ask the right questions of management when projects involved customers:
“Of course [the executives] didn’t know about disability access either—they didn’t know the technical standards. And basically, I said to them: ‘There’s only one thing you need to do. It’s easy. Every time something comes across your desk from any person, you just ask “What access issues have been included in this project?”, or “Have you included access features?” And if not, “Could you go away and think about them?”’”
By ‘go away and think about them’ it was implied that the manager go to the Accessibility Office and find out what they should be doing to fulfill their responsibilities regarding any project that involved customers. This new way of asking questions gave executives an insight into how their managers were performing, which was useful because the organization had adopted accessibility as a ‘Key Performance Indictor’.
From ‘Embedding accessibility in organizational culture’ (p.76-77) in Responding to Accessibility Issues in Business by C.M. Law.
Step 2: Gather knowledge
There are two basic types of knowledge to obtain. The first is accessibility knowledge. What can be done to make ICT accessible? What options are there for making organizational elements incorporate more accessible practices? The second type of knowledge is how ICT is currently used and how it is developed within your organization (internet, intranet, phone systems, etc.).
We must provide a cautionary note here. We do not recommend that you take your new-found knowledge—of ICT accessibility, and of how ICT is used and developed in your organization—and then unilaterally attempt to design new work systems for everyone. Instead, use your knowledge to help others get to where they need to go (as described in later steps). A collaborative design process that involves stakeholders is recommended. Unilateral efforts usually fail, because they are often regarded as evangelistic and unsustainable.
For accessibility knowledge, there are resources on the Accessibility Switchboard website that link to additional published resources. You might also consider bringing in subject matter experts to help your team understand current ICT accessibility tools and techniques, and organizational approaches to accessibility.
Accessibility experts can help you with the process of understanding how your current ICT is used and developed, and to assess whether there are any notable gaps in the level of accessibility of current systems. This knowledge can be used to feed into the subsequent Step 3 (establishing stakeholders) and Step 4 (maturity assessment). However, the main goal here in step 2 is simply to take stock of what ICT you are dealing with when you consider the ‘user experience’ (consumers, employees) at your organization. This can be done using detailed systematic techniques of systems analysis, or at a higher level, using flow diagrams to document your understanding of input, processing and output descriptions for various functions in the organization. The level of detail you go into will depend on your available resources.
Note: We recommend proceeding to Step 3 only when both the Step 1 and Step 2 have been achieved.
A resource for getting expert help on ICT accessibility, and on organization-wide accessibility initiatives…
The Accessibility Switchboard Community Of Practice includes consultants and other subject matter experts who came together to produce this guide. Community member profiles are listed on this page.
Step 3: Establish stakeholders
For each ICT use and ICT development element in Step 2, there are stakeholders who will have varied roles and consequently varied levels of engagement with accessibility. The stakeholders include people ultimately responsible for accessibility activities, as well as those who undertake development, testing and processing tasks. From the complete list of potential stakeholders, you need to identify who you think will or should be involved in any organizational changes around accessibility. In this step it is advisable to be as broad as possible, because it precludes the likelihood of later having to answer questions such as “Why didn’t you ask for my input in the beginning?” This step is for establishing who the stakeholders are, but not necessarily talking with stakeholders (which comes in the next step). Once your list of stakeholders is drafted, we suggest going back to your executive support for a discussion of omissions, ‘red flags’, and how to approach the next steps of the project.
Note: The resource cited earlier, Jeff Kline’s book on Strategic IT Accessibility includes a chapter on identifying stakeholders.
Step 4: Maturity assessment
It’s difficult to understand things that you haven’t measured. A maturity assessment provides you with baseline metrics as you start out. The information and numbers collected here can later be reviewed to track progress. We suggest the following three elements comprise your organizational maturity assessment:
- Review current policy. Policies describe what people in the organization should do. All policies that pertain to the stakeholders established in Step 3 should be examined. Write a summary of what you found (or seemed to be overlooked) in terms of ICT accessibility factors. We caution that you may encounter negative reactions to this sub-step, either from people who assume there are no policies in your organization, or who assert that policies are written down somewhere “but no-one ever reads or follows them”. Even if the negative experience applies, it is important to find out what policies are in place, the department that ‘owns’ them and the department(s) affected by them, what they say, what their status is (e.g., draft, final, outdated), and who is responsible for them (an executive should be responsible for each one).
- Ask people what they do now. Edgar Schein once said “If you ever really want to understand something, try to change it”. To get accessibility into your ICT processes, it is likely that a good deal of change will be needed. Schein alerts us that before we go headlong into designing a new system, we will be better prepared if we have a good idea of how the current system works, and how the current stakeholders see the system. In this sub-step, you should interview stakeholders to collect their points of view and document their understanding of how the current system works. At this stage you are not designing a new system (that comes later with the participation of stakeholders); instead, you are just trying to understand the system and behaviors as they are viewed now by the current stakeholders. Open ended questions are more useful and preferable in this activity (as opposed to leading questions driving towards specific outcomes or answers).
- Measure organizational elements. Numerical organizational maturity assessments have been developed to help understand and plan responses to how well various aspects of a business are working. What level is each organizational element at on an accessibility maturity scale? Scales may use levels such as zero for no activity; 1 for ad hoc; 2 for planned; 3 for resourced, and 4 for measured. For example, you may find that your company’s external facing website is at level 3, but your internal facing intranet is at level zero. Assigning a score to each relevant organizational element gives you a baseline from which to measure future progress. For those elements where the level is given as ‘measured’, you should also note the actual measures that are taken (e.g., 78% of our customer facing web pages have zero accessibility defects) as well the goals in place in the existing plans (e.g., our aim is to improve to 95% with zero defects by the end of the third quarter).
Note: Conduct the policy review first, and then the next two sub-steps might be best conducted concurrently.
Step 5: Design and plan the new system
Before you begin, and periodically throughout this Step, our recommendation is to check in with your executive support. At the beginning of this Step, an overview of the results so far should be checked against the original strategy discussions from Step 1. Do these strategy decisions need adjusting? Will you be likely to achieve your goals, given what you have discovered in the other Steps to this point? The following steps align with and can be executed in the same manner as any typical organizational improvement initiative:
- Operational design. For each ICT element that you have chosen to tackle (internet, intranet, phone systems, etc.), you need to develop a design for the updated system (inputs, outputs, and processes). This design activity is best facilitated by involving the stakeholders from those elements in the activity. After all, they are the ones who will have to implement and live with it. The design should address the current understanding of the system (from Step 4) and the available options for achieving accessibility inclusion in ICT processes (discovered in Step 2). For tricky / contentious issues, earlier strategy decisions should be referred to as the team considers practical options for achieving the goals. If you can develop systems that appear to be consistent with the self-interests of stakeholders, and that are framed in terms of what needs to be achieved rather than how to achieve it, the design will be more likely to succeed.
- Policy updates. Policies affirm what stakeholders should do in their regular work. Once the design has been agreed upon, existing policies can be updated and new policies can be created and disseminated to affected parties as needed.
- Training design. A number of stakeholders should have already been involved in the design process, but there will be many more stakeholders who will need to be educated on the new design and new policies. For all changes to current process, training needs to be developed (e.g., face to face or online courses). Some training may need to be customized to specific audiences, and some training activities may need to be held at prescribed intervals (e.g., ‘refresher’ training). In order to achieve training goals, an education and outreach plan may also need to be developed.
- Implementation & Monitoring Plan. Who gets training first? When will the first post-implementation maturity assessment take place? In six months? In a year? You need to develop a plan to cover all of the aspects of implementation and monitoring of progress that affect stakeholders. Caution is needed, as with any project, to manage expectations. No matter how much effort you spend in this Step, not everything will go to plan. Therefore, it is important to gain experience through implementation as soon as is practical. Mis-steps and cul-de-sacs in your own organizational Roadmap can always be addressed in future revisions to strategy and plans as the stakeholders in the organization learn from their individual and collective experiences.
A resource for conducting organization-wide accessibility maturity assessments…
Policy Driven Adoption of Accessibility (PDAA) Vendor Self Assessment Tool. This self-assessment excel tool is a useful starter resource for scoring and tracking maturity levels across common organizational elements. PDAA is an initiative of the National Association of State Chief Information Officers (NASCIO).
Note: Available skills sets and available resources vary between organizations. Consequently, there is no single template for the design of the systems in a given organization. However, there are case studies and resources to help with including accessibility in the design of ICT development and testing systems. Other sections of the Accessibility Switchboard provide guidance and links to further resources that can be consulted in the design and planning Step of the Roadmap.
Helpful hint: Design and planning can sometimes appear to go on indefinitely. However, there is no substitute for practical experience. It is important to set a timeframe for conclusion of the design and planning Step, and begin executing the plan.
Go In-Depth
A resource for making organization-wide plans to embed accessibility…
Including Your Missing 20% by Embedding Web and Mobile Accessibility by Jonathan Hassel is a book that describes a process for changing the way ICT is developed and tested. The book also features interviews with many subject matter experts in accessibility.
A resource for rethinking development processes to include disability access considerations…
Just Ask: Integrating Accessibility Throughout Design by Shawn Henry is a book that covers ICT design and evaluation methods for user centered design projects.
A resource for overcoming resistance to change in projects tackling organization-wide accessibility…
Organizational Change and Accessibility, Overcoming the Resistance is a webinar by Chris Law. The webinar is intended to help people plan before they encounter resistance, and turn accessibility into an ‘enlightened self-interest’ of all stakeholders. The webinar was produced by the International Association of Accessibility Professionals (IAAP).
About this article
Authors
This article is published as part of The Accessibility Switchboard Project, an initiative of the National Federation of the Blind Jernigan Institute with support from the members of the Accessibility Switchboard Project Community Of Practice, and from the Maryland Department of Disabilities.
Suggested citation
The Accessibility Switchboard Project. A Roadmap for Organizational Accessibility for Large ICT Vendors. January 2017, Version 1.0. National Federation of the Blind Jernigan Institute. Available: http://www.accessibilityswitchboard.org/
Feedback, additions and updates
The authors welcome feedback on this and other articles in the Accessibility Switchboard. Use the feedback form to provide updates, new case studies, and links to new and emerging resources in this area. The feedback form can also be used to join the mailing list for notification of new content and updates from the Accessibility Switchboard.
Copyright, use and reproduction
Accessibility Switchboard articles are published under the Creative Commons License Attribution-ShareAlike 4.0 International. You are free to share (copy and redistribute the material in any medium or format), and to adapt (remix, transform, and build upon the material) for any purpose, even commercially. This is under the following terms: (1) Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use; (2) ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. For more detail on the license, see CC BY-SA 4.0 on the Creative Commons website.
Picture credits
‘Accessibility Roadmap’ by Chris M. Law & The Accessibility Switchboard Project. CC BY-SA 4.0.