· Web viewImtech ICT Velocity Best Practices for developing accessible web sites in Microsoft Office SharePoint Server 2007 Waldek Mastykarz ([email protected])

Imtech ICT Velocity

Best Practices

for developing accessible web sites in Microsoft Office SharePoint Server 2007

Waldek Mastykarz ([email protected])

http://blog.mastykarz.nl

June, 7 2008

Version: 0.4

Copyright © 2007-2008 Imtech ICT Velocity

Oude Middenweg 11

2491 AC The HagueThe Netherlandshttp://www.imtech.nl/velocity

This work is licensed under a Creative Commons Attribution-No Derivative Works 3.0 Netherlands License. http://creativecommons.org/licenses/by-nd/3.0/nl/deed.en

Table of Contents

11Introduction

22Validation

22.1General Information

22.2Tools

43User Experience Translation


43.2HTML

103.3Cascading Style Sheets (CSS)

113.4JavaScript (JS)

124.NET


134.2Custom Controls

155Microsoft Office SharePoint Server 2007


155.2Accessibility Toolkits

165.3Custom information pages

185.4Master Pages and Page Layouts

206Internet Information Services 6 (IIS)

206.1Web.config

206.2Response headers

21Resources

Acknowledgements

1 Introduction

Standards compliancy and accessibility is very important for the expanding Internet. Every day more organizations implement their business processes in web environments. Availability of the involved information is very important – especially if the organization is government related and is supposed to provide the citizens with important data.

Designing and developing accessible web sites in Microsoft Office SharePoint Server 2007 is challenging. While working on a few Office SharePoint Server 2007 projects I have faced various issues within Office SharePoint Server 2007 itself but also in ASP.NET 2.0 – SharePoint’s underlying framework. Recently I have done a research on accessibility of web sites built upon Microsoft Office SharePoint Server 2007 (MOSS 2007). I have found out that it is possible to create a fully WCAG 1.0 Priority 2+ compliant web site. At the same time I have discovered that there are more developers struggling with the problem of accessibility in MOSS 2007. To share my experience I have decided to write it down as a few helpful tips & tricks: Best Practices for developing accessible web sites in Microsoft Office SharePoint Server 2007.

This document presents my vision on the design and the development of accessible web sites in Microsoft Office SharePoint Server 2007. It is meant for SharePoint developers who were given the task to build an accessible web site. While writing this document I have assumed you have the knowledge of MOSS 2007, ASP.NET and .NET and that you have a little idea of web development and XHTML + CSS + JavaScript.

I have written the Best Practices as a Q&A document. Each question is followed by a short answer. For those who are interested in understanding the choices I have made, I present some background information on the particular issue.

While implementing some of the best practices you might face some potential pit falls.

I provide some additional information about them as well

Although there is no link between particular questions in this document, it might be helpful to read the whole document for the first time. As soon as you understand the principles of the design and the development of accessible web sites in Microsoft Office SharePoint Server 2007 you are likely to use this document as a quick reference to help you memorize particular solutions.

2 Validation

Validation is a process which allows you to check whether the code you have created is compliant with the predefined standards. In this scope validation refers to controlling the syntax of HTML, CSS and RSS.

2.1 General Information

Validation is very important because it allows you to discover the incorrect markup present in the code. If done frequently enough and with the right tools it will provide you very powerful mechanism supporting the process of developing an accessible web site. Validation should be considered as an integral part of the development process rather than an assessment tool used afterwards.

2.2 Tools

Although checking the validity of pieces of HTML, CSS and RSS might be done manually various validation tools turn to be very useful while validating complete pages. These tools are able to control not only whether the code is standards compliant but also whether it is accessible. Some of the tools present possible solutions for the found issues.

2.2.1 Standards Compliancy

While validating the markup you will most often begin with HTML which forms the structural baseline for the web site. Although the newest web authoring tools contain embedded markup validators it remains important to validate the web pages manually. This becomes very important especially in later stages of the development process as you are more likely to create controls producing dynamic content. Using the right tools will provide you the feedback required to fix the incorrect markup if found.

The W3C Markup Validation Service

The W3C Markup Validation Service is one of the most frequently used validation tools. It allows you to control the markup on the syntax correctness according to the given doctype (HTML standard). Together with errors the W3C Validator reports the code fragment and a detailed description of the error message.

Website: http://validator.w3.org

The W3C CSS Validation Service

The W3C CSS Validation Service is next to the W3C Markup Validation Service another frequently used validation tool. As the name states, it allows you to check whether your Cascading Style Sheets are standards compliant. Just like the W3C Markup Validation Service it presents the discovered issues together with its detailed description.

Website: http://jigsaw.w3.org/css-validator/

2.2.2 Accessibility

As soon as the web content is compliant with the chosen standard you should proceed to validating its accessibility. Just like there are various compliancy standards, there exist a few accessibility standards and levels. If not stated otherwise by the customer you should try to develop your web site according to the WCAG 1.0 Priority 2 accessibility level as it covers the most common accessibility issues. There are various tools available on the Internet which will help you discovering these issues in your web site. You have to be aware though that none of the currently available tools can give you 100% feedback on the accessibility of your web sites. There are many aspects that can be controlled by human only.

WebrichtlijnenQuickscan

WebrichtlijnenQuickscan is a web content accessibility solution developed by the Dutch government to support the Webrichtlijnen accessibility guidelines. Webrichtlijnen guidelines base on WCAG 1.0 Priority 2+ accessibility level.

Website: http://webrichtlijnen.nl/toetsen/

HiSoftware Cynthia Says

The HiSoftware Cynthia Says portal is a web content accessibility validation solution. It is designed to identify errors in content related to Section 508 standards and/or the WCAG guidelines. The free tool meant for educational purposes, is an online test which only validates one page at a time.

Website: http://www.contentquality.com/

TAW. Web Accessibility Test

TAW (Web Accessibility Test) is a tool for the analysis of Web sites, based on the W3C - Web Content Accessibility Guidelines 1.0 (WCAG 1.0).

Website: http://www.tawdis.net/taw3/cms/en

3 User Experience Translation

User Experience translation is the process of creating HTML, Cascading Style Sheets and JavaScript based on the design created by a web designer. During this process the web professionals build the templates for the web site by reusing the delivered graphics and adding dynamic JavaScript controls to leverage the interaction with the user.

This phase is very important in the process of developing of an accessible web site as it forms the basis for the end product. Choices made at this stage have consequences for the rest of the development cycle and affect the quality of the whole web site.

More and more web professionals responsible for translating User Experience have knowledge of web standards. Yet lack of insights into the destination platform and insufficient communication with the developers can lead to major quality issues of the web site at the end of the development cycle. Although the translation process is independent of the target Content Management System, its understanding and communication with the development team can improve the accessibility of the delivered web site.


Which User Agent to use when translating the User Experience?

Use Mozilla Firefox as the primary browser during the User Experience translation process.

As all of these browsers render the markup according to the web standards it doesn’t really matter which one you choose. Keeping in mind you will need some tools during this phase it would be the best to use Mozilla Firefox as it has variety of add-ons available which support web development.

Although Windows Internet Explorer remains the most popular web browser it shouldn’t be used as the only neither as the primary browser during the User Experience translation process. As Internet Explorer doesn’t follow the web standards it will very likely give you the wrong impression about the result of your markup. While trying to fix it you will apply various workarounds which will cause problems in other User Agents.

3.2 HTML

Which doctype should I use for an accessible web site in SharePoint 2007?

Use the XHTML doctype for standards compliant web sites in SharePoint 2007. If developing a Webrichtlijnen compliant web site use the strict variant. Send all pages with the text/html mime-type or choose for content type differentiation depending on browser if you still want your visitors to benefit from XHTML if supported by their user agent.

A doctype describes the standard of the markup for web sites. There are two main sorts of the markup HTML and XHTML. The main difference is that XHTML requires very strict markup resembling XML. An error is an XHTML-based page will result in an error message: the output will not be rendered.

Another important thing to know is that according to its definition each XHTML page has to be sent with the application/xhtml+xml mime-type. This mime-type will allow User Agent to process an XHTML page according to the strict XML rules and benefit from the advantages. Sending an XHTML page with the HTML mime-type text/html is discouraged as it’s requires some workarounds in the markup. Unfortunately the most popular browser – Internet Explorer doesn’t support the application/xhtml+xml mime-type correctly.

ASP.NET 2.0 contains State fields (hidden fields which name begins with __ (double underscore), for example __VIEWSTATE) which ID’s are valid only with the XHTML doctype. Furthermore some standard available controls render only XHTML compliant output.

Negotiating the mime-types depending on the browser might be a viable solution (for more information see the General information chapter in .NET section). You should consider though, that you would be serving different content to different browsers.

Defining natural language

Define the natural language of the page in the html element using the HtmlHeader web control. If you’re not using Variations you can hard code the natural language as well.

Each page should have the natural language defined. This allows the screen reader to read the content in the language it has been written what makes the content understandable and therefore accessible. The natural language needs to be defined within the html element by using the lang and xml:lang attributes.

One possible solution to achieve this would be adding the runat=”server” attribute to the html element in order to process it server side. The downside of this approach is that it requires a custom Master Page class. As this approach is definitely viable it requires you to create a separate class containing the code behind of the Master Page.

Another approach is using a custom web control (HtmlHeader) which writes the complete html element including the lang en xml:lang attributes. The control encapsulates the logic required for dealing with Variations.

Meta charset should be the first element in the head section

After a User Agent has requested a URL it receives the pieces of the rendered output from the server. As soon as it finds it reloads the page in order to decode the diacritic characters correctly. By putting this meta element high in the head section you will cause the reload to happen very early what improves the rendering speed.

Put the page content as high as possible in the source code

Putting the page content as high as possible in the source code makes the content more accessible for visitors using screen readers. Furthermore the higher the content is in the source code the more valuable it becomes while crawled by a search crawler.

The visual positioning of the various elements on the page can be done using CSS and is in most cases independent from the order in the source code. In some cases however it is impossible to put the content above the navigation. To make the content accessible in such case you could use skip links with anchors to the navigation and content. This solution won’t be picked up by the search crawlers however.

Use skip links to improve content accessibility

A skip link is nothing else than an anchor linking to another element on the same page, for example:

Skip to content

Which links to the content wrapper:

Lorem ipsum

As soon as the visitor clicks on the skip link the page will scroll to the content area.

Depending on the design the skip links can be visible or hidden and reside on the very top of the content area most of the time as the first element in the body section.

Be careful while creating hidden skip links. Hiding them improperly can make them inaccessible to screen readers. See more information about how to hide accessible elements in the CSS section.

As skip links are constant elements available on each page they can be extended with the accesskey attribute which will allow visitors to use a hotkey to navigate to the link. Because the predefined hotkey vary by User Agent it is the best practice to use only numerical access keys.

Make use of repeatable table headers in the print view

It is a best practice to markup the table head section with the thead element, for example:

Column 1

Column 2

...

In most cases is it enough and will cause the header to be repeated automatically on the top of each page in the print view if the table will be spread across multiple pages. Windows Internet Explorer is however an exception to this. It requires the following CSS markup in order to display the repeating header properly:

thead {

display: table-header-group;

}

Repeating the table header on the top of each page in the print view when the table is spread across multiple pages increases the readability of the table data and therefore its accessibility.

The thead and tfoot elements must be used with the tbody element. tbody element requires thead and has the optional tfoot element.

Escape the script and style elements comments correctly while embedding them in an XHTML document

The correct way to escape the comments within the script and style elements is: for scripts:

and for styles:

The problem occurs only when trying to parse an XHTML with an XHTML parser when sent with the text/html doctype. As the are valid XHTML comments so they will be processed by the parser it is required to add the additional markup in order to make the XHTML parser skip the contents of a comment within the script or style element.

Markup the first occurrence of acronyms and abbreviations with the suitable markup

Markup the first occurrence on a page of each acronym (abbreviations which can be read as a word) with:

NATO

And the first occurrence of each abbreviation with:

HTML

First of all the definition: acronym is a kind of abbreviation which can be read as word; see the example in the code above. Further or both acronyms and abbreviation will be called as abbreviation.

Marking up the first occurrence of an abbreviation will make the screen reader read the full definition out loud. Doing this will increase the readability of the content and therefore its accessibility. Defining abbreviation will increase the readability of the text not only for the visually impaired visitors but for all users of the web site.

Most of the modern User Agents render abbreviations by underlining them with a dotted line. On hover a tooltip is being shown with the definition of the abbreviation stored in the title attribute. Internet Explorer 6 doesn’t show the tooltip unfortunately. To achieve the desired effect a custom solution JavaScript based solution is required.

Imtech SharePoint Compliancy toolkit ships with a solution for automatically marking up known abbreviations and acronyms. For more information about this solution see the help file of the toolkit.

Use full markup for data tables

Use full markup for data tables. A complete table markup consists of:

· Body section marked with the tbody element and the table header marked with the thead element. Optionally the table can have a footer marked with the tfoot element.

· Table caption for the table marked with the caption element stored as a child element of the table element.

Vegetable prices in Hobart and Darwin

...

· Table summary giving the visitors background information about the data presented in a table. Summary is not being rendered by most Internet browsers and is mostly being used by screen readers. The summary has to be defined using the summary attribute of the table element.

· Define the column headers using the th elements. It is a good practice to provide an abbreviation for long header so that screen readers will not repeat the long title each time while reading the contents of the cell which belongs to the given column. The column header abbreviation is being defined by using the abbr attribute of the th element.

Depending on the complexity of the table some additional markup might be required in order to make the table data accessible for visitors using assistive technologies. It is a good practice to keep tables as simple as possible and avoid the unnecessary complexity. The complete markup of tables together with the guidelines on when to use it can be found in the WCAG standard definition or on the Internet: http://usability.com.au/resources/tables.cfm

Don’t use meta refresh

Don’t use meta refresh or any JavaScript equivalent to automatically refresh the page

Automatically refreshing a page is a major accessibility obstacle as it makes impossible for people who need more time to read and understand the information to do so. You should therefore avoid using any kind of solutions automatically refreshing content periodically.

Don’t use pop-up windows

Pop-up windows are JavaScript dependant therefore they shouldn’t be used for displaying of any kind of information. Another major drawback for pop-up windows is that they cause visitors to lose the browsing context and history. Especially visually impaired visitors who highly depend on the browsing history and benefit from browsing in tabs lose they navigation as soon as being served a pop-up window.

Always underline links

All text links should be underlined at all times.

This best practice has to do with color blind visitors who are still able to navigate visually and use the menus but are not able to distinct links in text when they are marked with different color only. The underlined style has been there for links since almost the beginning of the Internet and it is therefore best practice to keep using it for all text links.

3.3 Cascading Style Sheets (CSS)

Cascading Style Sheets improve accessibility of the web sites by separating the presentation layer from the content itself. Thanks to CSS it is possible to create semantic (meaningful) markup for the content what results in improved accessibility of the content both for visitors and search engines.

Alternative style sheets shouldn’t be a copy of the standard style sheet

When creating alternative style sheets (like print style sheets or style sheets targeting other media) don’t copy the standard style sheet and make the changes but override only the necessary properties instead.

Copying the original style sheets and changing some of the properties will work at first but will make the maintenance of the user interface unnecessary complex. You will have to make each change in at least two places and maybe even more if using complex style sheets. Furthermore copying style sheets will negatively affect performance as you will be downloading the same information multiple times.

Cascading Style Sheets allow you to override earlier defined styles. Using this property will decrease the size of your style sheets and therefore increase the overall performance of the web site.

Use external style sheets

Use external style sheet files instead of defining them in-line or in-document.

Using external style sheet files will allow the user agent to cache them the first time they are requested. The next time the user agent will retrieve them from the local cache what will decrease the time required to retrieve all the resources referenced by the requested page.

Benefit of the cascading character of Cascading Style Sheets

Make the selectors as simple as it is possible to avoid the unnecessary complexity and keep it possible to override them if required.

While rendering the Cascading Style Sheets definitions in the document, the user agent scans the available definitions and orders them according to their precedence. The CSS selectors score points as follows:

103 – if the style is an in-line style (style=””)102 – for each id in the selector (#wrapper #content scores 200)101 – for each class, pseudo-class and attribute in the selector (#content .important scores 110)100 – for each type selector and pseudo-element in the selector (div p scores 2)

Making use of this principle will simplify your style sheets, make them more readable, better maintainable and will decrease their size.

How to hide elements visually but not from screen readers?

Use the following class in order to hide an element visually:

.invisible {

height: 1px;

width: 1px;

position: absolute;

overflow: hidden;

top: -10px;

}

By using the class definition above the element will not appear on the screen but it will be still accessible to screen readers.

Using the most common methods like display: none and visibility: hidden causes hiding the selected element from some screen readers. It should be therefore not used for elements which shouldn’t be displayed on the screen yet still available for screen readers. The elements you might want to hide using this approach are for example skip links on the top of the page as they are meant to be used primarily by visually impaired visitors and are not required to be seen by other visitors.

3.4 JavaScript (JS)

JavaScript is a powerful client-side scripting language and has evolved enormously during the last years. JavaScript allows developer to develop rich user interfaces improving usability and the overall user experience. Unfortunately as they are not supported by screen reader and other assistive technologies they should be used wisely and always allow users to use the web site and get to the information independent of JavaScript support. The best practice is to develop the web site without any JavaScript primarily and then extend it with extra JavaScript. This method is also known as progressive enhancement. Like this the developer is sure that users are still able to use the web site even if JavaScript is not there.

How should I attach events to objects?

Attach the events using unobtrusive JavaScript instead of in-line JavaScript.

Using unobtrusive JavaScript allows you to separate the content from the behavior – just like CSS allows you to separate the visual layer from the content. This is very important for interoperability and sustainability of the content.

Imtech SharePoint Compliancy toolkit ships with a cross-browser JavaScript library (Imtech.Behaviour.AddEvent) which helps you attaching and detaching events in an unobtrusive JavaScript.

4 .NET

Designing and developing .NET controls meant to be used on an accessible SharePoint 2007 web site is quite challenging due to various aspects. Very often controls produce markup which will become rendered on the page. This markup must be standards compliant and has to leverage the chosen accessibility level. As most .NET (web)developers have little standards compliancy and accessibility insights the choice for delivering an accessible web site requires the biggest investments in this area. The best practices presented in this chapter will help you during the design and development of accessible controls but you will still need to learn about the web standards and accessibility in order to understand the basic principles of why both of these items are of such an importance on the Internet-facing web sites.


Building ASP.NET 2.0 Web Sites Using Web Standards

MSDN contains quite a few helpful resources on how to build accessible web sites on top of the ASP.NET 2.0 platform. One of the very basic articles is ‘Building ASP.NET 2.0 Web Sites Using Web Standards’ available at http://msdn2.microsoft.com/en-us/library/aa479043.aspx. This article provides the basic knowledge of mechanisms available within the ASP.NET 2.0 platform which support developing accessible web sites. Although the article doesn’t provide turnkey solutions, it should be read by all web developers involved in development of accessible web sites in SharePoint 2007.

Which mime-type should I be using: text/html or application/xhtml+xml?

Use the text/html mime-type across the whole SharePoint 2007 web site.

Both Microsoft Internet Explorer 6 and Windows Internet Explorer 7 (further both called IE) don’t support the application/xhtml+xml mime-type. An XHTML page has to be therefore delivered with the text/html mime-type in order to be rendered correctly by IE.

Another solution is to vary the mime-type depending on the User Agent requesting the page. If the User Agent does support the application/xhtml+xml mime-type you could serve the page with this mime-type. Otherwise, in case the User Agent is IE or an older version which doesn’t support XHTML, you could be using the text/html mime-type. As this approach allows some of the users and information systems benefit of the XHTML features, it creates two different versions of the page on the viewer side which may differ from each other due to different parsing engines.

In some situations it might be required to use the application/xhtml+xml mime-type. An example might be an intranet environment with clearly defined supported User Agents. You can serve this mime-type using for example the code behind of a Master Page:Response.ContentType = “application/xhtml+xml”.

4.2 Custom Controls

Always pass the Control Tag in the custom control’s constructor

Standard custom controls are being rendered between span elements. Although it doesn’t seem to be a problem in many situations it might form a major issue within an accessible web site. Span is an in-line element. According to the HTML and XHTML specifications in-line elements might not contain block elements such as div for example. Using a custom control for generating a menu using an unordered list (ul) would cause problems. You can override this behavior by calling the WebControl constructor which accepts tag name as parameter. Like this you are able to render the contents of your custom control within a div or p element what will allow you to render block content.

Use the Render method instead of RenderContents when necessary

Certain custom controls might require rendering only the output without any other element around it. An example of such a control might be a custom control responsible for dynamically generating meta information. You can override the default behavior (rendering content within an element) by overriding the Render method instead of RenderContents.

Replace in-line JavaScript event binding with their unobtrusive alternative

Replace the in-line JavaScript event bindings () with their unobtrusive alternative making use of the DOM. This will allow you to separate the behavior from the content. Eventually you will benefit of decreasing page size, improving maintainability of your content and code and making the web site less dependent of underlying technologies.

SharePoint 2007 extends the ASP.NET 2.0 platform in many ways. One of the results is the in-line JavaScript event bindings. Although created automatically by the SharePoint runtime they are considered harmful an inaccessible: they decrease the code maintainability and reusability and increase the overall page size as the in-line JavaScript cannot be cached separately.

Imtech SharePoint Enhancement Toolkit ships with a JavaScript library which helps you binding the events to elements using the unobtrusive DOM approach. See the toolkit’s help file for more information about the usage of the JavaScript library.

Benefit of Control Adapters instead of creating new controls

Depending on the requirements you might need to modify an existing control. If the presentation layer is the only thing you have to alter, it is better to develop a Control Adapter for that control instead of creating a new one and redesigning the presentation layer only. By doing this you ensure that the control’s logic remains in one place and you keep the inheritance structure maintainable.

Control Adapters have been designed to alter the presentation layer of controls. They reside on top of the control and allow you to alter the default behavior whether by using the control’s object model or Regular Expressions. Although using the object models performs much better than a construction involving Regular Expressions it might be not always possible to incorporate the desired modifications using only the available properties and methods.

5 Microsoft Office SharePoint Server 2007

Microsoft Office SharePoint Server 2007 is a very powerful and highly scalable development platform. The 2007 version introduces a framework for designing and developing Internet-facing web sites. Although it is possible to make the platform fit the various requirements the customers may have, SharePoint 2007 hasn’t been designed with support for standards compliancy and accessibility in the first place. Developing an accessible web site on top of SharePoint 2007 is possible yet very challenging. In certain scenarios it might require some functionality drawbacks. Therefore you should take the accessibility requirement very into consideration very early in the development process.


Configure anonymous access as early as possible in the development process if applicable

Internet-facing web sites based on SharePoint 2007 might behave different when accessed by anonymous users. Although the editors’ area is highly dependent on its rich interface and the required resources, the pages meant for anonymous visitors can leverage the required accessibility level. Configuring anonymous access in the early stage of the development process will allow you to debug the functionality and optimize it for best accessibility and performance.

Don’t use the default temporary redirect whenever possible

Use the permanent redirect (301) instead of the temporary redirect (302) to optimize the process of indexing of your web sites by search engines.

SharePoint 2007 uses redirects in order to implement the required functionality. Many of these can be seen on the front-side (meant for visitors) of the web sites, for example redirect to the Welcome Page or Variation Root. Unfortunately all these redirects use the temporary (302) redirect. As such redirects are not being followed by search engines it forms a major flaw for the indexing and therefore accessibility of the information. Replacing the default temporary redirects with permanent redirects (301) will solve the problem.

Replacing the temporary redirects with their permanent equivalent is not easy. Imtech SharePoint Compliancy Toolkit ships with a turn-key solution for this challenge. See the attached help file for more information on installation and configuration of the solution.

5.2 Accessibility Toolkits

Which accessibility toolkit do I need to make my web site accessible?

The choice of the accessibility toolkit depends on the requirements of a specific web site. Imtech SharePoint Compliancy Toolkit has been designed to help you achieve the accessibility level as described in Webrichtlijnen (Dutch government accessibility guidelines comparable to WCAG 1.0 Priority 2+).

At this moment there are no turn-key accessibility solutions for SharePoint on the market. Furthermore this situation is very likely to remain that way because of the complexity of SharePoint 2007 and web standards fragmentation in various markets and countries/regions. Because of this you will have to know the contents of at least few accessibility toolkits and the way they should be used.

The research done during the development of the Imtech SharePoint Compliancy Toolkit is has proven that you can achieve up to 95% WCAG 1.0 Priority 2+ compliancy without any toolkit. As accessibility toolkits designed for SharePoint 2007 are required to rewrite some of the output in order to achieve the required accessibility level, they decrease the overall performance and should be therefore used wisely. Such toolkits can be combined with various caching solutions which will prevent reprocessing of the page on request basis.

Imtech SharePoint Compliancy Toolkit has been designed to help you achieve the accessibility level as described in Webrichtlijnen. If you don’t need such high accessibility level, you should use the required parts of the toolkit only to optimize the overall performance of the page.

In case your customer wishes to reuse some standard controls shipped with SharePoint 2007 you should use the Accessibility Kit for SharePoint (AKS). AKS contains various Control Adapters which modify the rendered code of the controls and make it XHTML compliant.

5.3 Custom information pages

Standard 404 (Page not found) and error pages delivered with SharePoint 2007 provide insufficient information to the user. In worst case this can cause the visitor to lose the browsing content and end-up without any usable information found. It is therefore the best practice to replace the standard pages with custom one which will leverage the User Experience available across the whole web site and provide some useful information allowing user to continue browsing.

Custom 404 page

The custom 404 page should contain the following information:

· Short explanation of why the user has been redirected to this page and how can he browse further

· The requested URL which is missing

· A possibility for the user to report the broken link including a comment

· Navigation options:

· Back button

· Link to the web site’s Sitemap

· Search field (or link to the search page if no such field available)

· Link to the Home Page

First of all the user needs to be aware of the redirect that took place. Explaining the reason of the 404 error and providing some information on how the user can continue should preserve the browsing context and improve the overall user experience.

Second of all users should see the url they have requested, which doesn’t exist. This is especially important while linking from other locations. If it’s an often requested link it might be useful to provide users with an option to send feedback about the broken link to the site administrator who can whether restore the page or make a redirect to the proper location.

Presenting the possible navigation options turns to be very useful as well. As the user has request a page that doesn’t exist, the following navigation possibilities should be presented in this specific order: back button – to let user go back to wherever he came from; sitemap – to display the site overview which may help user to find the right information; search field – if the user hasn’t found the required information he might use search and eventually a link to the home page if all other possibilities have failed.

Custom error page

The custom error page should contain the following information:

· Short, non-technical explanation of the error which has occurred

· The URL of the location which has caused the error

· ‘Try again’ link

· A possibility for user to send feedback about the error

· Navigation options:

· Back button

· Link to the web site’s sitemap

· Link to the Home page

The standard error page shipped with SharePoint is user unfriendly: it provides very little information about the error and, what’s more important, doesn’t provide any navigation mechanism to the user other than using the Back button in the browser.

Figuring out what has caused the error and explaining it to the user is very difficult. SharePoint 2007 is a very complex and highly customizable platform. The biggest downside of it is that there are various reasons for a web site to fail. A general, user-friendly explanation of an error must be therefore enough in many cases. If possible however, you should provide an explanation of the specific error.

Presenting the url of the request page which has caused the error is very important – especially for users who come to the page from an external location. Together with a possibility to report the error it provides both users and administrators a powerful maintenance and interaction mechanism.

There are many various reasons for a page to fail. Presenting a ‘Try again’ link might help in some situations: think for example off a situation when the web server is overloaded. The page itself works correctly. The server itself is the point of failure. By trying to load the page again the user might complete his request for information and preserve the browsing context.

After a user has been redirected to a page different than requested it seems fair to provide him some options to continue browsing. The first of which is the Back button, so the user can go back to the page where he came from. As the user has requested a certain page he might want to see other related pages which might provide him with alternative, though still useful, information. A link to the Sitemap can provide user with such overview. If all other mechanisms have failed, a link to the Home page will allow user to start the navigation from the main entry point.

5.4 Master Pages and Page Layouts

Provide the natural language of each Variation

Provide the natural language in the html element so it reflects the natural language used by the current Variation.

Providing the natural language of is required by various assistive technologies in order to speak-out the text correctly. Because of its importance it has become a requirement lately.

Providing the natural language of the given page is very important especially on multilingual web sites using Variations. As the content changes depending on the selected Variation, also the natural language must change as well. It might seem problematic to update the natural language automatically as it is rendered in Master Pages in most cases. In fact it is easier than many might think. Imtech SharePoint Compliancy Toolkit ships with a custom control which marks the natural language of a page depending on the locale of the currently selected Variation. See the attached help file for more information on implementation and configuration.

What is the best approach to present the title of the current page in the title element?

Use the title formatted using the following pattern: Page – Site – Site Collection.

Using hierarchical titles is very important as it helps users to preserve the browsing context. As it defines the title of the page it is also one of the most Search Engine Optimization weapons: search engines give much attention to the content of the title element. Choosing it wisely might increase the accessibility of your information.

There are many theories on what is the right approach to display the page title. These theories describe the various elements of the title and the separators used to divide these elements.

One of the approaches is to use Site Collection – Site – Page pattern as it reflects the natural hierarchy of the content. The downside of this approach is that while bookmarking multiple pages from one web site, it is more difficult to find a particular page as all the titles begins the same.

Another approach is to use Page – Site Collection skipping the Site title. The motivation behind this choice is, that it doesn’t mean anything to the user whether a page is in an Archive or not. In this particular example it is a correct assumption. On the other hand providing the Site title might add some extra clarity to the structure of the site – especially if the web site contains plenty of content.

As for the separators the choice is a personal matter in many cases. No matter the separator used you have to be aware of the consequences: how the title will be read by a screen reader. “Contact, Pipeline, About, Pipeline, Adventure Works” doesn’t sound the best while the title is presented correctly (Contact | About | Adventure Works). A dash (-) or a colon (:) will be the best choice in most situations.

As soon as you start implementing this best practice in your web site you will stumble upon various SharePoint specific challenges. One of these is how to render the title while being on the Welcome Page of a Root Web and how to render the title of any other Welcome Page? As you don’t want any of the elements to be displayed twice (what might happen if you named the Welcome Page and the Site the same) you would need to implement some extra logic to deal with these exceptions. Instead you might use the Hierarchical Title custom control that ships with the Imtech SharePoint Compliancy Toolkit. This control implements various exceptions, works correctly with anonymous users and provides you some additional options which you might need depending on the customer’s requirements.

Optimize ViewState

Remove the ViewState when not necessary. Otherwise move it to the bottom of the page.

Removing the ViewState decreases the page size. Depending on the controls used on the page it might save even 20kB of data. It is not always possible however to remove the ViewState. If it’s required by any of the controls on the page it should be moved to the bottom of the page as it’s not important for both visitors and search engines and it’s something processed internally by ASP.NET.

6 Internet Information Services 6 (IIS)

Internet Information Services (IIS) is the web server upon which both SharePoint 2007 and ASP.NET 2.0 work. Although many forget about the few IIS-leveled settings improving standards compliancy and accessibility it might spare you some extra work configuring these settings correctly.

6.1 Web.config

Set XHTML conformance to Strict

To avoid ASP.NET rendering legacy XHTML elements and attributes set the XHTML conformance to Strict in the web.config configuration/system.web section:

Settings the XHTML conformance level to Strict will cause ASP.NET to render the output according to the XHTML Strict doctype. One of the consequences will be stripping the name attribute from the form element and modifying the Postback JavaScript so it would work with the form ID instead of name.

Unfortunately not all ASP.NET and SharePoint controls render their output according to the set conformance level. Setting the xhtmlConformance mode to Strict will therefore fix some issues. Some ASP.NET and SharePoint specific output will remain invalid though.

Imtech SharePoint Compliancy Toolkit ships with a solution for fixing the ASP.NET and SharePoint specific invalid markup. This HttpModule resides in the runtime pipeline and cleanses the rendered output right before sending it back to the user. See the attached help file for more information on implementation and usage of the Compliancy HttpModule.

6.2 Response headers

Send charset information together with the response headers

Resources

Stichting Waarmerk drempelvrij.nlhttp://drempelvrij.nl

Webrichtlijnen voor de overheidhttp://webrichtlijnen.nl

Richtlijnen voor de toegankelijkheid en duurzaamheid van overheidswebsites (versie 1.2)http://www.webrichtlijnen.nl/webrichtlijnen-1.2-20061222.pdf

How People with Disabilities Use the Web

http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/

The Web Standards Project

http://www.webstandards.org/

Accessibility Kit for SharePoint

http://aks.hisoftware.com/

Rapid for SharePoint

http://www.rapid-for-sharepoint.com/

Documents

· Web viewImtech ICT Velocity Best Practices for developing accessible web sites in Microsoft Office SharePoint Server 2007 Waldek Mastykarz ([email protected])