To persuade anyone, or any organisation, to comply with any regulation you need to:

• Clearly define what they have to comply with.
• Have some legal stick to use in extremis.
• Persuade them of the benefits to them and to society in general.
• Make it easier to conform than not to.
• Make it is easier to check for compliance.

In the case of accessibility of web based systems:

• There is legislation and guidelines that adequately (although not perfectly) covers the first two points.
• Social, moral, financial and legal benefits can clearly be shown for accessibility, but are often overshadowed by the perceived complexity and cost of complying.
• Many of the tools that are used to develop IT systems have not made it easy to develop or test for accessible solutions.

Two announcements by HiSoftware greatly simplify the development of accessible solutions built with Microsoft SharePoint:

• The first announcement integrates Hisoftware's AccRepair utility into the SharePoint environment. This helps the developer to verify accessibility and make repairs without having to leave the SharePoint workplace.
• The second announcement is an agreement with Microsoft to develop the Accessibility Kit for Microsoft Office SharePoint Server (MOSS) 2007, which will provide out-of-the-box accessibility.

The combination makes it easy for developers to generate compliant pages and for the pages to be tested before they are moved into production.

SharePoint Designer provides facilities for the development of web sites and web applications. The combination of WYSIWIG editors, source editors and task panes enables developers to quickly create good quality code. The developer is prompted with valid options for the specific environment; for example if a tag is inserted the user will be prompted with a list of the valid attributes for that tag. This should eliminate invalid or deprecated options being included. Further, when specific information is required, for example alternate text for an image, then SharePoint will display a relevant prompt.

SharePoint Developer is used to develop three different types of pages:

• Master pages: define the overall look and feel of all the pages on the site and ensure a consistent brand image.
• Layout pages: define the layout of a page for a specific type of content. So a site may have layout pages for news, articles, product details, etc.
• Published pages: are layout pages with content added—for example a specific piece of news.

During the development of any of these page types SharePoint will prompt and assist the user to produce code that complies with the standards and guidelines of the site. These could include W3C XHTML standards, WAI guidelines, Section 508 standards as well as corporate standards. These in-flight checks will remove a large number of errors in the code.

The new Accessibility Kit will provide templates, master pages, controls and web parts, along with technical documentation. They will reduce the need for the developer to make changes or additions to support accessibility, hence reducing the complexity and cost of creating a compliant solution.

However, even with the Kit, checks, and prompts errors can still exist at this stage because:

• The developer ignored SharePoint recommendations or warnings.
• The developer did not use the Kit.
• Some of the content has been imported from elsewhere and not checked in the process.
• Some errors can only be identified in the context of a complete page.
• Compliance with some standards and guidelines, especially those relating to accessibility, cannot be checked automatically. Only a human reviewer can fully verify compliance.

HiSoftware's AccVerify has been integrated into Sharepoint Designer so that the developer can instigate the checking of a complete page, by a single click of a button, without having to leave the familiar development environment.

AccVerify can check a complete page for accessibility, site quality, searchability, and privacy issues. These checks can be extended to include custom checks that reflect the corporate standards of the site. Wherever possible the checks are programmatic however many checks can only be completed by visual inspection by a human inspector. To formalise these checks Hisoftware provides an interview wizard that steps the user through a set of visual check questions. Each question includes:

• A description, including a link to the standard or guideline being tested.
• The method for testing.
• Space for comments.
• Space for the result (pass, fail, not applicable...).
• A button to view the page. The view may not be the standard view but could be designed to support the specific test, for example the page could be shown without colour to test for usability by people with colour blindness.

When a programmatic or interview test highlights an error, repair functions can be instigated that will help the developer fix the problem.
Once a developer has run the programmatic and interview test to their satisfaction it can be passed to quality assurance (QA) before being promoted to production. SharePoint workflow can be used to control the flow of pages from development into production. The developer will instigate a workflow process that could include ensuring that the developer has run the relevant tests and provided the reports to QA. The QA function may then run some random tests to ensure compliance before approving the move to production.

Once in production Hisoftware's AccMonitor technology can be used to monitor the on-going health of the website independently of Sharepoint.

The beauty of this collaboration between Microsoft and Hisoftware is that it plays to the strengths of both parties:

• The developers have one environment to work in for development and testing.
• The move from development to production is controlled and easy for the developers to use.
• The Hisoftware technology continues to be used to monitor the production environment.