Variations and the natural language of a page
Defining the natural language of a web page is very important: it allows assistive technologies like screen readers to read the content of a web page out loud using the right accent en pronunciation. In (X)HTML you can define the natural language both for the whole page and particular elements using the lang and xml:lang attributes. As marking a particular fragment of text with a different language isn’t really difficult and can be done by the end users, setting the natural language of the whole page dynamically in SharePoint is challenging and must be implemented by developers.
To set the natural language for the whole web page you have to use the lang and xml:lang attributes of the html element, for example: <html lang=“en-US” xml:lang=“en-US”>.
If you use later on in the body text fragments in a different language you can mark them as well using exactly the same attributes, for example:
Dutch accessibility guidelines <span lang=“nl-NL” xml:lang=“nl-NL”>Webrichtlijnen</span> define….
The language attributes can be used on every (X)HTML element so you are very flexible in marking up the usage of different languages within one page. Getting back to the language of the page…
According to W3C the default value of the language attributes is unknown, so relying on the default values isn’t the best choice possible. If you create a web page presenting the content in a single language, you can solve the issue very easily by using the example I presented above in your Master Page. But what if you want to create an accessible web site presenting multilingual content?
SharePoint 2007 ships with the Variations mechanism which supports working with multilingual content. So far I have worked with Variations in a few projects and I have to admit, that the mechanism works pretty well as soon as you understand how it works.
Each Variation you create, is bound to a locale which is set during the creation of the particular Variation. This locale can be then obtained using the VariationLabel.Locale property. The challenge is to write the value of this property to the language attributes of the html element depending on the Variation of the page the visitor has requested.
The first time I’ve faced this challenge myself, I thought on using a custom ExpressionBuilder to do this. Using <html lang="<%$Imtech:VariationLanguage%>" seemed to me a good solution: comprehensible and manageable. Unfortunately there are two things you have to consider. First of all this ExpressionBuilder would need to support both compilation and evaluation mode - this in case you would like to customize the Master Page (customized assets are not allowed to use code). Second of all: as soon as you add the runat="server" attribute to the html element, the xml:lang attribute is being removed. It has nothing to do with the ExpressionBuilder - it’s just the way the ASP.NET handler works. Due to compatibility issues at this moment W3C recommend using both lang and xml:lang attributes. ExpressionBuilders are therefore no option unfortunately.
Looking for another solution, you might stumble upon coding the locale in-line using the <%= %> ASP.NET code blocks. Remember what I have just told you about customizing your assets: they cannot contain any code blocks. It might seem a plausible solution as long as the Master Page remain uncustomized. The only ‘if’ is here using a quite complex construction like <%= new CultureInfo(Int32.Parse(PublishingWeb.GetPublishingWeb(SPContext.Current.Web).Label.Locale).Name %> for something as simple as displaying the natural language of the current Variation. And I’m not even talking about the performance and memory issues which could arise by not closing the PublishingWeb properly.
There is another solution if you use code behind for your Master Page. Using the Page_Load method you can get to the html element and then add the language attributes using the Attributes.Add() method. It seems to me an overkill to create code behind for a Master Page only to add the language attributes to the html element but if you’re already using one, it is a neat approach.
And last but not least my favorite: a custom control instead of the html element. All you need to do is to replace the html element with <Imtech:VariationLanguage runat="server" /> and simply override the Render method of the custom control to produce the complete html including both language attributes and the xmlns. What I personally like about this approach is that is pluggable (you can easily add it to an existing Master Page), it has no impact on the customization state of the Master Page and it’s modular: the whole logic can be stored in an separate assembly accessible from within a particular Web Application (bin) or the whole Farm (GAC).
Summary
Defining the natural language of a web page is one of the most important steps of making content accessible. Even more important is making it reflect the current content while working with multilingual web sites. SharePoint 2007 and the underlying technology allow you to solve this challenge in multiple ways. While all of them are different it is the most important that you make your choice based on the architecture of your solution.
Technorati Tags: Accessibility, SharePoint 2007, SharePoint, MOSS, WCM, Best Practices