Which Doctype to use with SharePoint 2007?

Designing and developing accessible web sites on top of SharePoint 2007 gets more and more attention in the community. But the more developers try to reach the required accessibility or standards compliancy level, the more challenges they face and the more questions pop up. One of such questions is which doctype should be used for standards compliant and accessible web sites.

SharePoint 2007 redirect solved: using 301 instead of 302 redirects

Each time you request a Site Collection (http://domain/) or a Site (http://domain/foo/) of your Publishing Site you get redirected to the http://domain/Pages/<WelcomePage>.aspx. SharePoint 2007 uses the 302 header (location temporarily moved) for this purpose. Surprisingly even WSS uses the 302 header to redirect a root url to the default.aspx. In comparison ASP.NET uses an internal redirect to render the default page when the root url requested: there is no redirect in this situation.

The impact of developing an accessible web site in SharePoint 2007

The development process of a typical Web Content Management solution based on Microsoft Office SharePoint Server 2007 consists of three main areas: User Experience, Functionality and Deployment. The development process begins mostly with designing the total User Experience. Based on the business requirements the designers determine the particular areas on the web site and the corresponding functionality. The typical products of this stage are the User Interface (UI) design and the Interaction design – the way the UI responds to the user input. The next stage is translating the User Interface into code: HTML, Cascade Style Sheets (CSS) and JavaScript (if any client-side interaction required). As the products of this cycle form the baseline for the solution to be delivered it is crucial to name all the requirements of the total product and in particular the accessibility aspects. During the last stage of the User Experience phase the translated User Interface is being incorporated into SharePoint 2007. At this moment the Master Pages and Page Layouts are being formed and the content areas and the Web Part Zones are being determined and placed within the Page Layouts. In many cases the User Interface incorporated in SharePoint 2007 is being hand over to the developers who are going to fill it with the dynamic controls they are going to build. Using the original User Experience translations the developers start their work. First of all basing on the original User Experience they design the look & feel and the behavior of the dynamic control and Web Parts. Then they take the pieces of the User Interface translation and incorporate them within the custom controls. As soon as the development stage is finished and the whole solution has been tested, it is being prepared to be deployed on various environments such as test or production. The decision of developing an accessible WCM solution based on SharePoint 2007 has a major impact on the development process. The affected areas have been marked orange (product independent) and green (requires product specific knowledge) on the figure below. First of all the designers have to take accessibility into consideration while designing the User Interface. Drop down menu’s dependant on JavaScript and mouse centered interface for example can lead to a totally inaccessible web site. Choices like these can have major impact on the overall accessibility of the web site and the presented information therefore they need to made very carefully and according to best practices for developing accessible web sites. The products made during the translation stage form the baseline for the whole web site. The accessibility of the information depends on the quality of the delivered code. That is why it is crucial to be sure that the right patterns and practices have been chosen to translate the drawing into code. The translation can also have impact on the total performance of the web site therefore it definitely shouldn’t be underestimated. During the incorporation of the translated User Interface into SharePoint the designers are very likely to face many of the undocumented features of SharePoint 2007. Originally SharePoint’s interface is table-based and my experience shows that even a little alteration can have impact on the SharePoint engine. If made carefully the decisions taken at this point can make the development stage easier and can guarantee very high level of accessibility. The developers are responsible for designing and developing custom controls which in many cases present dynamic content. Many of these developers are .NET developers with some SharePoint experience and very little to none accessibility knowledge. At this stage the web site has the biggest risk of getting inaccessible. Because of the little accessibility knowledge the most developers have, they are not able to estimate the impact of their choices on the accessibility aspects of a web site.

Automatically marking up abbreviations and acronyms in SharePoint 2007

Accessibility is a broad term and reaches way beyond the standards compliant code only. Accessibility is in my belief a set of features improving the understanding of information presented by an information system. I have to admit though compliant and semantic HTML is a very important factor of accessibility as it hosts the information. As I have recently solved the issue of standards compliant HTML in SharePoint 2007 I have started looking for new challenges and accessibility improving solutions. Almost immediately I have stumbled upon automatically marking up abbreviations in content.

Automatically generating a hierarchical Title in element

Recently while working on an Internet facing web site for one of our customers I thought of creating a control which would automatically create a hierarchical Title in the <title> element, like: Site Collection - Current Site - Current Page. Standard SharePoint 2007 allows you to define the title on the Master Page and within a Page Layout. Default SharePoint 2007 displays the Page Title in the <title> element. As I've been recently researching the accessibility issues I have noticed that such a behavior can cause loosing the context - especially if the visitor is vision impaired. Secondly it might cause search engines indexing a page and not linking it to the organization (Site Collection) or for example a division within it (Site). You could solve it using the standard features like displaying the Site's Title using <SharePoint:ProjectProperty> but still it wouldn't provide me the flexibility I wanted it to have. That's why I have decided to make a control which would automatically generate a title based on the existing hierarchy.