Microsoft Web Accessibility Handbook

Practical Strategies for an Accessible Web

By design, the European Dialogues on Web Accessibility focused on exploring solutions and approaches to address challenges and promote a higher rate of Web accessibility. The experts on the Dialogue panels and in the audience identified a long list of practical strategies, including:

Use Standards Smartly

Technical specifications and guidelines are a cornerstone of an effective Web accessibility strategy.

It is important to recognize the emergence of new technologies and to utilize up to date standards. For example WCAG 1.0 is not designed or applicable to building a Web application that is interactive and involves menus, dialogs, scripting, and back and forth conversation between the end user and the server. WCAG 2.0 was designed to address some of these issues and to be applicable to new technologies as they emerge.

However, even WCAG 2.0 will never be the singular solution to making Web sites accessible. Web sites change continually so the W3C Authoring Tool Accessibility Guidelines (ATAG) can be an important standards tool. Even though WCAG defines what it means to be an accessible Web site, ATAG ensures that, over the long term, the production of Web content will be accessible.

While standards can give a solid foundation for accessible Web sites, organizations should not expect to use them off the shelf. They will likely need to be interpreted for each organization.

Make ownership of accessibility standards as broad as possible within an organization, so that they do not become just the opinion or preference of one person.

Raise Awareness and Knowledge

People do not set out to create inaccessible Web sites – so education is key. Give people the awareness, the desire and the technical skills to deliver accessible IT solutions. If they are not aware of it, if it is outside their frame of reference, if they do not have the skills to deliver it, they will not create accessible Web sites.

Training software professionals—the people who create development environments and authoring tools—should be a top priority. Often, content creators are not the appropriate people to fix accessibility problems.

Education and training is critical not only for developers, but also for designers, editors and even management. Knowledge directly affects Web site creation and impacts the creation of goals and strategies that support Web accessibility.

Raising awareness among business unit owners and sponsors helps them to understand why accessibility is important, and then they may even start demanding it from their IT professionals, rather than having it forced upon them. High-level awareness presentations can talk about what accessibility is, why it is important, and what the benefits are.

Cross-training and train the trainer approaches can be very effective in organizations of all sizes. Best practices can be extended throughout an organization by identifying individuals and teams that are getting it right and building accessible Web sites. Invite them to showcase their work and to share lessons learned about what works well.

Training should focus on the rationale behind guidelines –strategies for creating an accessible user experience. The point is not to tick every single compliance box just for the sake of it. Education and training should result in a Web site that is usable by everyone.

The Web 2.0 world of user-generated content makes accessibility education and training even more important. Many organizations of all types are encouraging people to share their knowledge in blogs and wikis. Strategies to teach people to generate content in an accessible way include articles on an intranet, road shows, and training sessions.

Institutionalize Accessibility

Within an organization of any size, moving from a guerrilla campaign for an accessible Web to a more institutionalized approach can be difficult.

Creating an “Accessibility Center of Excellence” or “Web Standards Forum” within an organization can help to define accessibility standards and practices and to drive broad implementation.

A Web accessibility group should include representatives from across an organization, including influential decision-makers and senior people, so they can help achieve buy in and to raise the profile of accessibility.

A Web accessibility group can bring draft strategies to decision-makers and seek the real authority to drive a strategic approach to accessibility.

Horizontal networking – working together in an organization (and externally) with other webmasters and content owners that face similar challenges--can help solve everyday problems.

Test and Benchmark Appropriately

Many organizations have hundreds of Web sites and millions of Web pages so automatic tools are needed to help identify potential issues.

The key to automation is repeatability. A repeatable process is important for measuring progress over time.

Often, a small number of Web sites generate the most traffic. Focusing accessibility testing and remediation on those key sites can enable more rapid progress in the area of accessible Web sites. Automatic scanning tools can allow for quickly selecting any kind of criteria to check against.

Understanding and interpreting the results of automated tools is important. The reports can sometimes be misleading. For example, if a search box on every page of a Web site is missing a label or not properly tagged, then it could cause 100% failure across all pages. One quick fix could bring several pages into compliance.

The challenge with any kind of benchmarking, auditing or testing is that Web content is dynamic by nature – it changes all the time. Even if a Web site is accessible one minute, it can change 100 times in the next hour as thousands of content creators add new content.

However, testing for accessibility is not only an automatic process. It is important to recognize that there are three additional types of testing that are appropriate in different situations and for different purposes that can lead to even more useful information: functional testing, usability testing and compliance testing. Note: The last chapter in this guide describes these three types of testing in more detail. It also discusses the importance of sequencing them in the right order to achieve the best results.

Compliance testing focuses on adherence to technical specifications. It answers the question, “Does a Web site comply with a standard?”

Functional testing is about whether the product works as it is designed, and whether the design is a reasonably functional design. Does it actually incorporate accessibility needs? Was it designed to work with a mouse, to read out loud in order, to use large fonts and so on? Functional testing prioritizes by user scenario, addressing task completion and the importance of that particular task.

Usability testing is about whether actual people can use the product. It involves people using a Web site with their relevant software and assistive technologies. This testing can provide broad and deep insights into additional issues that guidelines will never cover.

User error is a factor with usability testing. A Web site might expose everything the way it is supposed to and meet relevant standards but users still may not be able to use it. That is a different question than whether it was designed well and does it meet a standard. Usability testing is best done last, after confirming that other key aspects work.

Rigorously testing all templates used by Web teams and the gateway pages can help ensure that at least the main elements are accessible and can be used by people with assistive technologies to create Web pages.

Make It Easy

If it is easy to do the right thing, people are much more likely to do it. If you create accessible content by default and someone has to do something to change it, they are less likely to do so. If you create content that is not accessible and if you have to then do something additional, it is that much more of a barrier to Web accessibility.

Developers can design and develop software in such a way that end users do not have to think about making accessible web content; since it is built into the tools, they get the accessible solution by default.

A standard software engineering practice is to take functionality that is duplicated in multiple places and to bring it in to a single control. Each of the different places can reference the single control, which avoids replicating the same work over and over again. Web accessibility examples include functions and libraries in coding environments or Comet controls in Windows. Web services such as third-party shopping carts are another example of something where specialized knowledge has been concentrated into a single place.

Do not become a checkpoint service. Focus on real life issues. It is a myth that accessible Web sites do not look as nice or do not have as rich functionality as inaccessible Web sites. Web developers love the challenge of creating an accessible, engaging, attractive user experience, regardless of whether you can see the screen, understand the language, or use the mouse. It is all achievable; it just requires some innovative thinking. Stick to the guidelines as your bedrock and understand what they are trying to achieve.

Many Web developers and content creators will never gain a complete knowledge of web accessibility. Automated tools can help fill in the knowledge gaps, but a comprehensive accessibility toolkit that includes manual inspection, tutorials, and other resources as in addition to automated checks will provide the range of support needed by developers.

Do not expect industry guidelines, technical specifications, or checkpoints to be broadly usable off the shelf. They can be open to interpretation by many different Web developers and content creators. They can be an exceptional starting point to promote an understanding of accessibility and to provide a foundation for further work, but they are more useful when turned into a set of standards specific to an organization and its developers, suppliers, and customers.

Combine additional best practices and pragmatism with industry guidelines and technical specifications. Once those standards are in place, adhere to them every time a Web site or intranet is developed. Test against them.

A set of internal standards can be the operational way for developers to implement an organization’s strategy. It can control the way that developers code pages, so that anything that produced during the development stage should meet internal standards.

A lower level, completely organization-specific set of very detailed internal standards can provide an almost “paint by numbers” product for developers. For every element on a page it tells them how it will behave, the size, the branding elements to use, the color, the behavior of the content when it is clicked, etc. It can leave absolutely no room for interpretation. It can guarantee accessibility compliance and brand compliance.

Content creators may require additional tools. Increasingly they are not technology professionals and have little or no accessibility expertise.

Require Compliance and Governance

Do not rely on people’s best efforts or goodwill to use internal standards, tools, practices, and strategies for Web accessibility. Put a governance process in place. Require compliance and penalize non-compliance.

Governance provides a set of rails for people to run along. It gives needed guidance to do their jobs properly but it also gives the mechanism to identify non-compliance and a means of dealing with it.

A governance process does two things at the outset: 1. it makes sure that internal standards are adhered to during the design and development process of Web sites and intranets; 2. it means that procurement documentation includes the right questions to help people purchase accessible solutions.

A governance process must also effectively address noncompliance – perhaps through a waiver process. If a project does not meet an internal accessibility standard it is best to understand the issues and create a managed remediation plan.

A waiver for non-compliance may require an assessment of risk and a time bound action plan for making adjustments and improvements as well as steps to minimize the impact on staff and customers. It could be signed off by very senior people within the organization.

An effective governance process should make it easier for people to comply with internal standards than get through the waiver process.

A governance process does not have to be hundreds of pages long; it should be a clear, concise policy document.

Approach Web Accessibility as a Process

A full lifecycle approach to Web accessibility can be effective. The lifecycle begins with an accessible design and continues after the launch of a Web site with good solutions to maintain the compliance of the site.

Incorporate accessibility as part of the build process, so that designers and developers, and even the tools themselves, enable accessibility to the greatest extent possible.

Timing can be vital. With any large Web project, there is a window of a few months in which people are planning what will happen over the longer term. Missing that window means probably means missing an accessibility feature in the next release. It is important to really understand an organization and the points at which decisions can be influenced.

A lifecycle approach can include several stages. A first stage would be an assessment of existing Web sites and benchmarking them against standards and guidelines along with a review of the technologies the site should support such as Flash, JavaScript, Cascading Style Sheets (CSS), HTML, etc. A second stage would be an examination of resources needed – both internal and external. A third stage would include defining a strategy, including a quality assurance and testing plan. Once all these plans are in place, a fourth stage would focus on design, prototyping and testing. A final stage would include feedback, refining code libraries, making sure style guides are up to date, and building in checks for accessibility at regular intervals.

Within any process, focus on prioritization, both in testing and fixing problems, to ensure the most impact. When evaluating the functional aspects of accessibility and what may need to be fixed, consider the use of scenarios to determine which things are the most important for the user.

Evangelize and Engage

Many Web accessibility projects fail because nobody has clear ownership of accessibility within the organization. There must be an accessibility project manager for the whole course of a project and beyond. Define who has ownership, who is driving it, and who is managing it.

In addition to a project manager, choose an accessibility champion. It should be someone senior in the organization that takes responsibility for the accessibility strategy and, when it matters, is prepared to stand up and be counted. Decide how serious the organization is about accessibility. To what lengths is it prepared to go in order to enforce an accessibility standard?

Determine the key stakeholders within an organization. Who has an interest in making a Web site accessible? This could include Web teams, procurement teams, legal teams, and marketing and branding teams, who quite often are forgotten until towards the end and may come up with a number of missing things.

Define the key stakeholders and interview them. In large organizations there can be a lot of politics and emotion involved in how people want the Web site to be, so get it all out on the table. Figure it out. What are people’s hopes and goals? What do they want to achieve? What are their fears?

Engage individually with a variety of people and sell them the message in the way that is important to them. Different messages resonate with different people. The most successful seem to be a combination of “this is an interesting problem that you can solve which helps people and also makes money”.

6. 
   If it is a business person, then maybe the business opportunities of a growing aging demographic will resonate.
   
7. 
   If it is a user interface designer, then focusing on interesting user interface challenges may make accessibility a more appealing topic.
   
8. 
   If it is a developer, then discussions might focus on code quality, standards and implementation.
   
9. 
   If it is a tester, then how accessibility impacts quality might be of interest.
   

Senior level executive buy in to accessibility is absolutely essential. People at the grassroots level, the developers and the designers, are critical to delivering accessibility from the bottom up. However, executive buy in to mandate it from the top down is equally important. Much of the actual guidance and leadership comes from the middle.