Chapter 3: Implementing Accessibility in the Enterprise by Mark Urban and Michael R. Burks

In order for an enterprise to successfully implement an accessibility solution, the enterprise needs to be some sort of organization that will handle and support accessibility issues and enforcement. We'll refer to this as an accessibility organization. The details of how this accessibility organization works will differ depending on the type of organization. Certainly, there will be differences in the way it is implemented in nonprofit organizations, governmental entities, for-profit businesses, and educational institutions. However, there will also be important similarities.

This chapter will describe the basics of implementing web accessibility in an enterprise. We will look at the development of a model accessibility organization that could be set up within any large enterprise. While this chapter is geared towards web accessibility, this process could also be used to implement other accessibility solutions, such as enterprisewide standards for assistive and adaptive technology or employment practices related to disabilities.

Why Set Up an Accessibility Organization?

In many organizations that consider accessibility, the common approach is to create a project that will add accessibility to existing services, or offer accessibility on an ad hoc or as-needed basis—addressing accessibility only when persons with disabilities raise issues. There are at least two dangers in this approach:

The U.S. federal government also realized that an ad hoc approach would not be effective in resolving some of the issues on an enterprise basis. The U.S. Department of Justice, in a report to the federal agencies, stressed the need for a broad-based architectural approach:

Data provided by the agencies suggest that the majority of agencies that continue to handle IT accessibility issues exclusively on an "ad hoc" or "as needed" basis, instead of integrating accessibility into the development and procurement of their mainstream IT products (sic). Many IT officials hold the mistaken belief that persons with disabilities can always be accommodated upon request by using widely available assistive technology devices (e.g., screen readers, screen enlargers, volume control apparatuses, pointing devices that serve as alternatives to a computer mouse, voice recognition software, etc.) in conjunction with mainstream technology applications. Indeed, the goal of section 508 is to ensure that the agency will always be able to provide reasonable accommodations. Without adequate planning, however, the possibility of providing an accommodation to person with a disability may be foreclosed....Use of an "ad hoc" or "as needed" approach to IT accessibility will result in barriers for persons with disabilities. A much better approach is to integrate accessibility reviews into the earliest stages of design, development, and procurement of IT. Once an accessible IT architecture is established, then and only then can persons with disabilities be successfully accommodated on an "as needed" basis.

The point is that if you take the ad hoc approach, your web-based architecture may require so much retrofitting that it will be unusable to a large degree. Designing from the beginning and using good planning can avoid this trap. It can also save an enormous amount of money. Retrofitting anything is expensive, and it should be avoided whenever possible.

Setting up an accessibility organization for the enterprise will help to avoid the dangers of taking an ad hoc approach.

Makeup of the Accessibility Organization

A model accessibility organization (AO) within a larger enterprise must have certain qualities. One of the most important is the ability to cut across lines within an organization to maximize knowledge and awareness of accessibility itself. Its ultimate goal should be to build a group of qualified people within the company who can manage and oversee accessibility projects, rather than overseeing them itself. To that end, the AO should be a resource within the enterprise, not a controlling organization. Its management should be carefully structured, and its members should have a mix of characteristics directly related to their role in implementing accessible web technology.

The AO should consist of members of stakeholder departments and internal experts in the field of web accessibility. Very few of the members of the AO should be full-time workers in the AO. Most should work in the group only part-time, having their primary responsibilities in their departments. The reason for this is that (for the most part) members of actual design, development, sales, strategy, and management will have a greater day-to-day feel for the status of accessibility within an organization. Also, such a team spreads accessibility awareness and concerns throughout an organization, creating a culture of understanding regarding accessibility concerns that no amount of drum-beating by "purist" accessibility staff can create. Most should be drawn from the departments that will be affected by the implementation of accessibility in web technology.

Figure 3-1 illustrates how an AO might be structured.

Figure 3-1

Figure 3-1. Model accessibility organization structure.

Accessibility Organization Authority

One of the most important factors in implementing accessibility is seeing to it that the organization charged with this implementation has the authority to implement change, as well as the responsibility to do so. This organization must be able to set standards, make decisions on the tools needed, and lay out the processes to be followed. Without such authority, the implementation of accessible web technology will be difficult, if not impossible.

In addition, the AO must also have authority to do the following:

The AO must have authority from the highest levels of an enterprise. It must be able to assist or consult on all related projects. The upper management of your enterprise will need to make a commitment to implementing web accessibility. It must make this commitment publicly and provide financial backing for the AO. It is preferable for this empowerment and commitment to come from the head of your organization, such as the chancellor of a university or the CEO of a corporation.

Good examples of the types of organizations that have made such a commitment can be seen in the three letters sent to President Clinton by technology executives and research university presidents. These letters committed the organizations to various aspects of accessibility, but the principle is the same.

After the head of your organization has committed to making your web technology accessible, a web accessibility "champion" should be chosen, or should volunteer. This should be a member of upper management who is familiar with web accessibility issues, and has enough authority and prestige to ensure that everything that needs to be done is done.

A bottom-up approach is fine for implementation and understanding of accessibility; however, for this to succeed and to be implemented in an efficient and effective manner, at least one member of upper management must be able to "push" solutions when needed. This person must have a good grounding in this area and believe in what he is doing.

It is likely that if there are no consequences for noncompliance within organizational policy, low levels of compliance will follow. The AO must be authorized to punish noncompliance. Conversely, it is just as important to reward meaningfully the efforts of those who do make the effort to implement web accessibility. The AO must be empowered to use both types of consequences as tools to implement web accessibility throughout the enterprise efficiently.

Accessibility Organization Scope, Goals, and Functions

Defining the scope of the AO is critical to its success. Its scope must be narrow and well defined to keep the organization small and compact. This will also help to keep the workload of its members from becoming too large to handle. A clear and focused scope will also keep the organization from becoming bogged down in a morass of side issues not directly related to accessibility. The departments using the AO should be prepared to handle these issues.

The goals and mission of the AO should be clear and simple, helping members to understand clearly what is expected of them. This will keep the group on target for achieving its goals. For the initial implementation of accessibility, clear timelines must be set with checkpoints for the organization's goals.

An AO should be responsible for the following:

The following sections describe these functions in more detail.

Accessibility Awareness

The AO must make education and raising accessibility awareness top priorities. On its own, this awareness can solve many of the accessibility issues in your organization and go a long way toward making your enterprise's websites accessible to people with disabilities.

Awareness is very low among those who have not had any reason to implement accessibility in web-based technology. Many people do not even know there is an issue. The very act of educating those who will be responsible for making the web technology accessible will alleviate many problems. If properly trained, many people who work with web-based technologies not only start to work to the required accessibility standards, but also go on to help develop new and innovative accessibility techniques.

Two ways to raise accessibility awareness are through training and by providing an electronic knowledge base.


Training should be closely focused to give personnel not only a good grounding in the technical aspects of web accessibility, but also a clear understanding of the laws involved and how they can be applied to their work. Depending on their level, personnel will need different depths of accessibility awareness. Higher-level managers should need to know only enough to understand the issues. This should be the first level of training, which everyone involved will need. As you move deeper and deeper into the various departmental roles, training will need to be provided in greater detail on a need-to-know basis.

Training should be done both with live instructors and with online training. Instructors can give the initial coursework, answer questions, and get personnel started with accessibility training. The remainder of the training can be done using online distance-learning techniques. Externally developed online coursework can be considered both for basic and advanced courses. A number of online courses in web accessibility are available, such as those offered by WebAIM.

Using these resources can save your enterprise considerable time and money, while giving staff a good grounding in accessible web design. This can be supplemented by supplying personnel with a good textbook (such as this book!), which can also serve as a reference manual.

If the distance-learning site is set up properly, it can also be used for reference and reviews. It should not be the only option for this type of information, but it should be set up with the idea that those who are implementing web accessibility in your organization will use it as a reference.

Knowledge Base

The AO should set up a knowledge base—an accessible collection of practices (internal and external) that can be queried. This electronic knowledge base should serve as the central hub for people looking for solutions. Employees should be encouraged to use the solutions stored in this repository and also to contribute new ones. Those who develop new and usable solutions to accessibility issues should be rewarded, which will encourage others to do the same.

The knowledge base should be easy to get to by everyone who needs it, including internal and external support personnel (if you have any). If the knowledge base isn't easily accessible, the simple fact is that it will be unused. It is therefore very important to ensure that the knowledge base is designed and deployed well, via a company intranet, for example.

A mechanism should be set up so people can easily enter information that would be appropriate to the knowledge base and increase the information it holds for dissemination to the organization. This information should be easy to submit and extract, and checked and formatted to ensure its validity before being posted. This method should be known throughout the enterprise, and people should be constantly reminded of its existence. Reminders of how to use the knowledge base can be placed in company newsletters, e-mail messages, and internal articles on a regular basis.


One of the functions of the AO should be to encourage the sharing of solutions within the enterprise. It should also encourage the sharing of common issues and problems. The feedback mechanisms should allow the expression of problems that are perceived in the implementation of the standards set up by the AO. This will allow problems to be aired, investigated, and resolved quickly. It is very important to answer the feedback in a timely and accurate manner, so people know that you are indeed supporting them and that they can count on getting help.

A feedback process must be developed so that the AO can work to improve its methods. Changes may be made both in procedures for implementing accessibility into new areas in the enterprise and in existing processes already in use. It should be easy for internal and external "users" to submit feedback. A "user" of the AO (that is, someone who can benefit from it) can be any person who needs access to the services you provide: another division or group within your organization, a student, another organization, or a consumer. Customers should be given every opportunity to provide feedback on accessibility on a continuing basis, without complaints being the only measure. This is important, because in electronic services, customers rarely complain about a cumbersome or inaccessible interface—they just leave.

Focus groups can help your organization to understand the needs of users and usability studies during the development of your web pages and websites can increase your customer satisfaction ratings. These should be small groups of individuals from within and outside your organization, with an interest in using your services. They should talk about what they would like to see provided by your services, and test your sites to see what problems they can uncover. Obviously, users with disabilities will be best to test the accessibility of your sites. Testing with real users is vital. Merely relying on the available accessibility guidelines is never enough. Focus groups and usability studies can help you achieve good, usable pages that meet the needs of your customers. In the long run, this will be cheaper and more cost-effective for both the enterprise and the customer than the cost of lengthy remediation. Usability is critical. No matter how many accessibility features a page has, if it is not usable, it is not accessible. You can find Information on how to develop focus groups and usability studies through many online resources. One of the best places to start is Jakob Nielson's site, Chapter 1 of this book includes suggestions for how to include users with disabilities in projects.

Quality Assurance

While feedback is one method of ensuring that accessibility initiatives constantly improve, the AO also needs to implement more formal procedures for monitoring and assessing the quality of web accessibility initiatives in the enterprise. Milestones, monitoring, and periodic reviews should be part of a quality assurance program.


The AO and its member organizations should set department-specific milestones that quantify accessibility. Those people responsible for implementing and managing the work necessary to reach each milestone should be involved in setting what should be accomplished by when. This will give you the best chance of success. The following are some examples of milestones:

An SME should audit quality and expenditure when each milestone is reached. This information should be recorded and made available for future reference in the knowledge base. These reports should also be integrated with larger periodic reviews to make sure that a good overall picture of the progress of the enterprise is produced on top of the snapshot at each milestone.

Technological Monitoring

There must be a consistent way to determine if the company-wide standards are being followed. These can be in the form of checklists, accessibility analyses, repair tools, or a combination of these things. Depending on the size of the enterprise, the number of web pages, and the type of web pages, there will have to be a suite of methods to determine if standards are being met. Whatever they are, the methods should be consistent across the enterprise. This will ensure that there is at least a level of consistency for both the compliance and the understanding of what the compliance is supposed to be.

Periodic Objective Reviews

SMEs or experts in accessibility should conduct regular reviews of enterprise web accessibility. These should be done within a framework of clearly delineated sets of checklists, standards, and milestones that have been set up by the AO for the entire enterprise.

This review should be able to clearly show where the enterprise is in achieving this goal. The information can be placed in the AO knowledge base so the entire enterprise will have access to it. Your enterprise may want to consider using an outside service for this assessment. This reduces the chance of the assessment being influenced by internal politics and pressures.


Having support personnel devoted to web accessibility is not recommended, unless your organization is huge. Much of this support probably can be done by electronic means. A well-laid-out set of web pages addressing the major concerns of the organization can greatly assist your organization's support needs for accessible web design. As noted earlier, a good feedback mechanism can help keep the electronic support up-to-date, and it can help highlight new problems your organization is facing.

To enable the talents of persons with disabilities to be utilized most effectively in an organization, a clear infrastructure for support and integration of assistive technology is essential. Ideally, the following questions should be asked:

Support for systems and applications for persons with disabilities should be formalized. Often, the problems experienced by users of adaptive systems can be resolved once, and the solutions applied throughout the enterprise. A model assistive technology support structure could follow this pattern:

  1. A call goes into internal support.
  2. Support checks for standard browser and assistive technology issues.
  3. Support checks with the knowledge base for known problems and resolutions.
  4. If necessary, the problem is escalated to outside vendor support.
  5. Solutions are entered into the knowledge base.

Legal Matters

The AO should ideally have at least one legal expert on staff, and the heart of the legal contribution should be a section of the knowledge base devoted to the laws, regulations, and policies that apply to web accessibility in the enterprise (Section 508, for example). These should be explained clearly, with examples illustrating the relationship to the enterprise's web activities.

The main job of the legal person on staff should be to deal with exceptions, and to make sure the knowledge base is usable and understandable to both attorneys and personnel whose main expertise is not in the area of law and policy.

It is critical that the AO and the legal department maintain strict control over the dissemination of governmental communications that could affect the future of the entire enterprise. All such communications should be routed through the AO. This is critical to both the health of the AO and the enterprise in general. The legal department representative should be an integral part of the AO.


Standards are the framework upon which an organization will be able to base its solutions to accessibility issues. Most organizations will deal with two types of standards: external and internal.

External standards have a national or international scope. Standards bodies have representatives from many areas of expertise. These bodies meet, discuss, and decide on standards for web accessibility, developing rules that are designed to promote web accessibility. The standards include the three sets of World Wide Web (W3C) guidelines (as explained in Chapter 1 and discussed throughout this book) and Section 508 of the Rehabilitation Act (also discussed throughout this book; Appendix B contains the section of it most relevant to web developers).

Internal standards should be through a manual, or style guide, and software. The manual addresses the consistency of style on websites. It should have accessibility built into the guidelines, as well as the standards that authors use to produce accessible websites. The software will be used by the enterprise to produce websites. This can consist of several types of software and will ensure consistency of results across the enterprise. These software packages should meet the needs of developers and be able to produce accessible websites. This approach should also reduce training costs, as a limited number of software packages will need to be supported.

Internal standards must be developed carefully with the input of the people who will actually be doing the work. This is critical to the success of the program. The people in the field who are building the websites and using the software on a daily basis are the ones who should have the main input into what tools will be chosen.

A good example of integrating accessibility standards is the North Carolina State University (U.S.) implementation. This enterprise architecture incorporates WCAG 1.0 requirements, along with telecommunications, software, and biometric accessibility requirements.

A standard that is not applied is no standard at all. Your internal standards must not only be applied on a consistent basis, but they also must be applicable to the situations that exist within the organization. If the standards are not realistically chosen, they will not be applied.

If they are not applicable to the web technology that your organization is using, they cannot be applied. The style guide should be developed using the experience of your developers and institute accessibility standards. It should reflect best practices that have been developed both internally and externally, and should be tailored to fit the specific situations that your developers are likely to encounter. This ensures that document developers feel they are being listened to, that their expertise is being respected, and that the best tools are chosen to accomplish the tasks at hand. The people who are going to use the style guide should have a sense of "ownership" of it. This will ensure that it gets used and that new knowledge, acquired by experience, will be integrated into the document.

The best way for developers to address accessibility while dealing with your customer needs is for it to be incorporated in the design phase of planning. A style guide can contain the rules for accessibility, as well as all the other rules for how you will produce websites (such as spelling, colors used, copyright and trademark issues, scripting page layout, navigation issues, and so on), both internally and externally. Accessibility should be dealt with both specifically in a separate section and elsewhere in the style guide where appropriate. For example, alternative text for images should be discussed in the section on image use and presentation, as well as in the section on accessibility (see Chapter 6 for more information about alternative text requirements). Having such a style guide will make web developers' jobs a good deal easier, allowing them to concentrate on building the website's infrastructure and content.

Another important consideration for internal standards is that project personnel should be informed of the functional requirements of accessibility, not their implementation. Don't tell people how to do things; tell them what needs to be done. Personnel must be educated to the fact that most standards do not give specifics of how to achieve a desired functionality. In general, the standards should specify what must be done and not go into great detail of how it must be done. This allows developers to exercise creativity in implementing the desired functionality in any particular situation. Where possible, the AO should not only encourage creative solutions to problems, but also collect these solutions and make them available to all through the knowledge base.

Public Representation

The AO should represent the parent organization in public affairs related to accessibility. Since the AO will be the single most concentrated area of accessibility expertise in the enterprise, its members should be the ones facing the public and representing the enterprise to the accessibility community. This will present a unified front to the public and prevent misunderstandings about your organization's web accessibility policies in the wider arena.

The AO can also represent the entire enterprise in standards groups, such as the Web Standards Group Accessibility Task Force (WaSP ATF). This will serve the needs of everyone. Even if there are members of the organization who are on standards bodies and are not formally members of the AO, they should be listed as associated with the AO and should coordinate their activities with it to keep everyone informed and to be sure a united front is presented. The best way to ensure that people are committed to this goal is to make sure that the AO helps to finance these activities.

Standards committees can be difficult to work with, and it takes a certain type of person to be effective within them. This person must be able to work within the standards process, and to collect and integrate all of the concerns of the member organizations. She must then be sure that these concerns are addressed by the standards committee, as well as fairly representing your organization's interests and accessibility issues.

Implementation Approach

It is not realistic to suppose that you can simply convert every single web page overnight and make it accessible. Had they been designed that way from the beginning, then it would not be much of an issue. However, if that were the case, you would probably not be reading this chapter!

A phased approach is the most workable and realistic approach. The following are suggested steps for implementing such a phased approach in your organization:

  1. Decide upon a standard for web accessibility.
  2. Announce the standard to the entire organization.
  3. Announce support and training for the standard.
  4. Set a date beyond which all new web-based technology must be accessible according to the standard you have chosen.
  5. Have each organizational member of the AO analyze his web-based systems to determine which technology will be changing first, since this will need to be accessible.
  6. Determine if any critical web-based technology must be made accessible.
  7. Determine if any critical web-based technology cannot be made accessible.
  8. Have each member department in the AO present a plan phasing in accessible web technology.
  9. Begin implementation of accessible technology, including retrofitting inaccessible websites, as discussed in Chapter 15. The phased-in approach will help ensure that members of the AO are ready by launch date.
  10. Make sure all support systems are in place, including technical support and training.
  11. Monitor the progress and supply help where needed.

Before you take any implementation steps, you need to make an initial assessment. If you do not know where you are, then you will never figure out how to get where you want to be! The initial assessment gives you a starting point. You will then be able to gauge how long it will take to achieve the goals you have set and how many resources are required.

Initial Assessment (Where Are You?)

The most effective way to begin accessibility integration is to make an objective analysis of the current situation in your organization. An honest and thorough assessment, along with a detailed, time-limited plan for remediation, can help an organization meet its accessibility needs in a cohesive, cost-effective way, as well as limiting liability during the remediation process. Although some organizations may have the resources to do accessibility analysis internally, one of the most effective methods is to have an independent assessment. This rules out the possibility of political forces (internal and external) or subjective attachments and conceptions skewing the assessment.

An assessment should involve answers to the following questions:

When conducting a review of your existing web technologies, you should ensure that you include the following:

All devices and services that use web-based technology must be accessible to people with disabilities, including your employees and any others who may use your devices and services. These must be tested with a wide range of access devices where appropriate.

Implementation Plan

When looking at the costs associated with retrofitting existing inaccessible technology, it becomes apparent that the implementation plan should stress implementing accessibility as part of new development, procurement, and use of electronic and information technology. This "forward accessibility" focus will maximize the resources within the enterprise by making accessibility simply part of the natural development of the organization. This plan will need to deal with both retrofitting old web material and seeing that standards are developed to make sure that all new web-based projects are implemented in an accessible manner.

Once this plan is in place, you can then start to monitor against it using the feedback and quality assurance procedures that are included in the functions of the AO.

Handover to AO

Accessibility, if being handled by a special team as a project, should be handed off to the AO upon completion of the initial integration. The AO should meet no less than quarterly to ensure enterprise-wide accessibility maintains momentum. Between the meetings, information should be gathered so that progress reports and agenda items can be brought to the AO for action.

If properly handled, and the initial integration completed, the requirements for keeping web-based products and services accessible should be no more onerous than making sure any other required design features are included in the next site redesign. It is a simple matter of raising awareness and keeping a good set of requirements available to designers, developers, and those who must implement the technology.


When considering web accessibility in any organization, it is essential to do so by coordinating all its resources. Without this holistic view, accessibility can be both expensive and difficult. Additionally, there is a danger of creating pockets of inaccessible web-based technologies within the enterprise. By having management and field personnel participation in accessibility integration, an understanding of the needs of people with disabilities can be disseminated throughout the enterprise, creating an environment that allows the largest number of people to be as productive as their talents permit. By having the personnel who are actually developing and implementing solutions as ongoing participants in the implementation process, you will get commitment from the people who know the most about the web-based technology being used by your enterprise.

The following steps can be used to create an accessibility organization successfully:

  1. Get commitment from the top manager.
  2. Get an accessibility champion to head the organization with authority to implement accessible web design.
  3. Clearly lay out the purpose of your organization and its goals and scope.
  4. Recruit its membership from the people doing the work and the people managing them.
  5. Develop your accessibility plan.
  6. Set your specific goals and timeline.
  7. Begin your implementation.
  8. Monitor your progress.
  9. Make needed corrections.
  10. Provide feedback mechanisms.
  11. Create a central resource for ongoing use.
  12. Meet with field personnel on a regular basis to monitor progress, introduce new technologies, collect internal methodologies, and reward progress.

Keep in mind that the U.S. and other countries have developed standards for accessible web technologies. As described in Chapter 2, 16, and 17, there may be laws that apply to your enterprise. Even in instances where these laws do not directly apply, the regulations and standards that are being set up are bound to have a great influence in many places. Therefore, it is a good idea to keep informed of what these regulations and standards are, and how they are being applied in the technical venue.