Microsoft Web Accessibility Handbook

Planning and Implementation

The following are the four basic phases of developing and maintaining an accessible Web site:

1. 
   Develop a plan –Set organization goals, design guidelines and standards, and perform an assessment of your Web site or application. Understand that the requirements are different for application features than they are for documents. Many organizations choose to build policies around the World Wide Web Consortium (W3C) Web Accessibility Guidelines (WCAG) 2.0, which are intended to cover the ever-expanding set of Web technologies and to focus on techniques for implementation.
   
2. 
   Implement guidelines – Train designers, developers and testers . Decide which features should be retrofitted and which should be re-created. Design new features to incorporate the principals of accessibility, based on an organization’s new quality guidelines and standards, as it is much more expensive to add it on later. Retrofit existing documents, and put in place tools and processes to ensure that new documents are created in an accessible way.
   
3. 
   Accessibility testing – Test that your product has met your standards and guidelines, and that it works as you expected. For Web applications, this will involve three types of testing: Functional, Usability and Compliance. For documents and Web sites made up mostly of documents, with few application features, Compliance testing will sometimes be enough.
   
4. 
   Accessibility maintenance – Evaluate results. Automate verification of accessibility guidelines and standards for documents and static content. Add processes to ensure that new application features are tested for functionality, usability and compliance, before those features are released.
   

Empowerment

Provide tools to Web site designers and content creators to build accessible content

Giving team members the tools that they need to do the right thing from the beginning is the most cost effective approach to accessibility. Experience tells us that no one builds a Web site intending that it be inaccessible, but education, simplicity, and real empowerment are key factors to a successful strategy.

Implementing Organizational Guidelines

With the accessibility goals and guidelines developed, and a baseline audit completed, the next phase of the project begins. In this phase developers and quality assurance teams receive training and begin the process of retrofitting the company Web site. Organizations must first make an assessment of what is being done right and what is not being developed so that it is accessible.

Automate testing and understand where automation is not enough

An accessibility testing strategy will provide an organization with the ability to view accessibility from a project management perspective. This will enable an organization to:

Understand what is an application feature and what is content, and have a plan for how to test each;

Allocate resources appropriately;

Track site progress;

Educate employees;

Identify problem areas;

Integrate accessibility into product design, quality assurance, and content delivery processes;

Keep a historical view of your Web site accessibility work.

Reward good behavior and set reasonable consequences if standards are not followed

Most employees strive to be successful in their jobs. Once a Web accessibility strategy has been implemented, recognize teams and team members who work hard to accomplish their goals. Allow them to lead by example. Often evangelists within an organization who embrace the concepts and methodology behind accessible development can serve as mentors and trainers for others.

This phased approach offers the best opportunity for Web site compliance to accessibility guidelines and standards. Companies can avoid becoming a target and look forward to the continued accessibility of their Web content once they develop the above disciplines. There are many good reasons for supporting the creation of accessible Web content. It is important to recognize that these changes will not happen overnight. Once it is clear that “developing accessible” is achievable, affordable, and can provide a competitive edge, it will become common rather than the exception.

(Portions of this article were excerpted from the book “Understanding Accessibility: A Guide to Achieving Compliance on Web Sites and Intranets” - by Robert B. Yonaitis; HiSoftware Publishing, ISBN: 1930616031-More information is available at http://www.hisoftware.com/uaccess/Index.html)

 

Chapter 4

Demonstration of Practical Strategies from the Dialogues

In the previous chapter, we learned about the practical strategies for making Web content accessible that were discussed at the European Dialogues on Web Accessibility. These include using standards wisely, raising awareness within an organization, institutionalizing accessibility, testing and benchmarking web development for accessibility, and making it easy to make sites accessible. In this chapter we’ll learn how the Accessibility Kit for SharePoint (AKS), and in particular the community that has grown with the product, is a real-life example of many of the practical strategies that can be used to make Web content accessible.

AKS: A Community-based Approach to Web Accessibility

Microsoft Office SharePoint Server 2007 (MOSS) is a business productivity server based solution that can improve organizational efficiency and collaboration through integrated content management and enterprise search, accelerating shared business processes, and facilitating information-sharing across boundaries for better business insight.

Microsoft Office SharePoint Server 2007 (MOSS) made a number of accessibility improvements and enhancements over its predecessor, SharePoint Portal Server 2003. The W3C Web Content Accessibility Guidelines (WCAG) 2.0 working drafts were considered as part of the design process. However, Microsoft received feedback from customers who had a need to create WCAG 1.0 AA conformant Web sites on the SharePoint platform. Based on analysis of that feedback, and the most urgent customer requirements, the SharePoint team determined that they would create an accessibility add-on for SharePoint, to address those requirements which became AKS 1.0. AKS 2.0 will address additional customer scenarios and will provide additional WCAG 2.0 support.

AKS provides an accessible layer on top of a SharePoint implementation that accelerates the process of accessible Web development. AKS supplements the templates, style sheets and the components that are already utilized in SharePoint to create the most common types of sites, enabling users to deploy accessible SharePoint sites quickly. It also provides a framework and documentation to help developers make more complex and customized sites accessible. The Community site and discussion infrastructure include peer and expert support as well as code-sharing. This provides the community with the ability to extend the tools that Microsoft and HiSoftware have provided.

Microsoft has provided this solution, in collaboration with HiSoftware, as open source and at no additional cost to its customers. The creation of an “accessibility community” for this dominant platform technology will educate, enhance and extend awareness and accessibility initiatives as a high priority for organizations using SharePoint as their business productivity platform.

AKS is intended to significantly reduce the time, knowledge, and effort required to implement a SharePoint-based Web site that conforms to the World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines 1.0 Priority 1 and 2 checkpoints. SharePoint is the fastest growing server product in Microsoft’s history with revenues in fiscal year 2007 of more than $800USD million worldwide and greater than 37% annual growth in the UK alone. Microsoft sold 84 million licenses of SharePoint worldwide. These licenses are for internal users of SharePoint, and do not even contemplate the hundreds of millions of additional Web users that SharePoint may impact when it is used to create public facing Web sites. AKS allows the creation of WCAG 1.0-compliant SharePoint sites. This is extremely important because SharePoint has been deployed extensively throughout enterprise organizations worldwide, to create collaborative work spaces and Intranet sites, as well as Internet Sites. Microsoft’s emphasis on accessibility across the SharePoint Platform will have a dramatic impact on improving accessibility of Web sites AND Intranet (employee) portals.

AKS is developed as a set of building blocks rather than an end-to-end solution. SharePoint users can utilize various pieces of the kit and integrate them into their respective product or service offerings while some customers will integrate particular components of the kit into their SharePoint deployment processes.

AKS is available-at no cost- via Microsoft Public License (Ms-PL) which was recently approved by the Open Source Initiative as an open source license. Additionally the kit utilizes an open and well documented interface to enable accessible extensions of SharePoint. Finally, AKS contains tutorials and education-empowering others to “build accessible”. This education based approach to accessibility allows business users and content creators within the organization to do the “right thing” in terms of accessible development, more easily. By exposing content creators to more accessible tools and utilities and providing the explanation for “why” these tools are more accessible, users can learn, extend and incorporate these principals into their ongoing Web development efforts, both within and outside of SharePoint.