SharePoint branding without accessibility requirements

If a SharePoint site has to be branded but is not required to meet any accessibility standard, the next consideration is whether the proposed branding style is radically different from the default look of SharePoint (or any of its associated built-in styles).

If the branding is exactly the same except for a change of colour, a new site theme should be created or an existing theme should be copied and modified.

If there are small structure and colour changes required to a built-in style for a SharePoint, the built-in SharePoint style should be copied and modified.

If the branding of the proposed SharePoint site is quite different from any of the built-in styles, a new branding will have to be created from scratch.

An example of changes that would qualify as regarding a complete build of master pages would be a custom navigation menu.

General considerations when creating a completely new branding for SharePoint

If the design of the site is going to be radically different from built-in SharePoint sites, the best practice is to create static web pages of the site design. This is the case for both accessible and non-accessible site designs.

The static pages should work well across a variety of browsers and pass accessibility testing if this is a requirement for the final SharePoint branding. This task of creating the static web pages could be done by an external party such as a web design agency. There are guidelines that should be followed when creating static pages for a branding for SharePoint that are outside the scope of this document.

Once these static pages have been created, these static pages will need to be cut up into separate ASP.NET files that SharePoint will use as the layout. This is a developer task.

Custom development of code and website files are also required when creating a new SharePoint branding.

Sites with accessibility requirements will require a lot more coding than those without. The development required really depends on the requirements of the site content.

SharePoint Designer

SharePoint designer is a free programme from Microsoft that can be used to customize the appearance of SharePoint whether it is WSS only or MOSS. Although some parts of the designer may be useful such as the workflow wizard, it is not suitable for any significant branding of SharePoint.

Accessibility standards overview

Website accessibility standards are specified by the Web Accessibility Initiative (WAI) which is a sub group of the W3C. The most common accessibility level to aim for is Double-A.

The main goals to achieve Double-A conformance is to produce clean HTML where the layout is controlled by CSS.

Aside from producing reasonably clean HTML, other considerations for accessible sites include providing:

• alternate text for images
• alternate content for media such as flash or navigation that depends on JavaScript
• meaningful titles for links on the page

Some of the standards for accessibility are the responsibility of the content editor such as providing alternate means of accessing content.

There are programs such as Total Validator which can automatically validate a web page against an accessibility level.

Considerations when branding MOSS SharePoint sites

With MOSS 2007 the following can be achieved:

• Colour scheme changes
• Major layout and appearance changes, making the site unrecognisable as a SharePoint
• Sites that conform to accessibility guidelines (though not without considerable effort)

The first consideration when branding a MOSS sites is whether the site has to conform to accessibility guidelines.

By default, SharePoint does not come close to conforming to accessibility guidelines but it can be re-worked with a variety of techniques to produce accessible content with (at least) 3 caveats.

These caveats are:

• Accessibility can only be achieved when a user is accessing a site in a read-only style mode
• Many advanced features of SharePoint cannot be used. These include:
  • Almost all web parts
  • Web part zones (a type of layout that allows flexibility in placement of modules)
  • Built-in brandings and themes that come with SharePoint
  • The default content editor
• It takes lots of work! Custom development is almost certainly required.

The NSU Safe network site is an example of a SharePoint site that conforms to Double-A compliancy.

There are 2 notable frameworks that have been created to assist with making SharePoint accessible.

The Accessibility Kit for SharePoint (AKS)

There is an accessibility framework produced by a HiSoft in association with Microsoft. The framework is currently at version 2.0 at this time.

The kit includes more accessible versions of the built-in SharePoint themes and layouts though using any of these is a token gesture towards accessibility.

From investigation, a lot of development is still required to create an accessible site and the AKS does not provide much help towards this.

The Alternative Rendering Framework (ARF)

ARF is an open source framework to assist with creating accessible SharePoint sites. One of the core concepts of the framework is to keep using SharePoint lists and document libraries as the data store for a site but providing an alternative method for customizing the display of this data.

The ARF has proved very useful for creating accessible sites is used in the NSU Safe Network site.

This article is only relevant for WSS 3.0 and MOSS 2007.

When there is a requirement to customise the appearance of a SharePoint site, the first consideration is the version being used.

Branding WSS sites

If the SharePoint version is WSS (free to install if you have Windows Server 2003), colour and image changes are possible along with minor layout changes. It is not possible to use WSS to produce an accessible SharePoint site.

The default theme of SharePoint looks like the following

Other built-in themes that have different colours and images only are available

Microsoft released 10 new themes for SharePoint in March 2009 and one of these could be used. Again, the structure of the site is the same and only colour and images have changed.

While working on the Timer job I talked about in my previous post, I also had a problem retrieving the value of a particular field.

I needed to get the value from a field called ‘Company’, but when I tried to get the value for Company through my code it brought back the value for the field ‘Position’.

In my case, I found out this was because these where not the original field names. In SharePoint a field has an internal name. This internal name of a field is set to the fields title when it is originally created and never changes.

There is an easy way to find a field’s internal name without resorting to code. If you sort a list by a field, the url will contain the fields internal name as the ‘SortField’ Parameter.

When I sorted the list by ‘Company’ I found it had an internal name of ‘Linktitle’:

http://…/All%20Open%20Items.aspx?SortField=LinkTitle&SortDir=Asc

and when I sorted by Position:

http://…/All%20Open%20Items.aspx?SortField=Company&SortDir=Asc

This explains why the code was returning the Position and not the Company.

I changed the code to pick up the value of field ‘LinkTitle’ and everything now works fine.

Just a tip for anyone who may be working on a SharePoint Timer job, this could save you a lot of hassle and head scratching…

I have been recently working on a simple enough Timer job. The timer job runs once a day and checks a date field for every item within a list.

if the checked items date is the same as the current date, a notification email is sent to the user who owns / created the item. As I said, simple.

Unfortunately I found out the Timer job runs twice in quick succession instead of once. I thought I must have activated it twice in the code, but after much debugging I found that It had only been deployed and activated once.

Eventually I found that the problem was being caused by a property called SPJobLockType.

This property defines how the instance of a timer job runs.

The value set in the timer job was SPJobLockType.ContentDatabase. This value causes the timer job to be run once for every content database on the farm. We have 2 content databases on the farm, therefore the job was running twice.

I changed the value to SPJobLockType.Job. This locks the job and doesn’t allow it to run more than once on a server and solved my problem.

Poor Spencer Harbar,  he has produced some very good, detailed and useful  articles on applying Kerberos and then TechNet publish an article “Using Kerberos for SharePoint Authentication”  full of the very points that may work in the lab but not necessarily in the real world.   I sense he was a bit miffed on writing this article!

He has listed the main points to be aware of in this article on his blog post:

TechNet Misinformation: How NOT to use Kerberos for SharePoint Authentication

You will be able to find other Kerberos related articles in his blog.

In order to turn off or disable the "My Site" or "My Links" functionality you need to be a SharePoint Administrator. Then follow the steps below.

• Go to the Central Administration Web Page
• Click on the link for Shared Services Administration
  • If you have more than one Shared Service Provider (SSP), select the one that is running the "My Sites" functionality
  • Under "User Profiles and My Sites", click "Personalization Services Permissions"
• Select the group you want to limit the functionality.  More than likely you will just have "NTAuthority\Authenticated Users"
• Click Modify Permissions of Selected Users
• In the next screen, you will see a list of checkboxes
  • To disable "My Sites" uncheck "Create Personal Site"
  • To disable "My Links" uncheck "Use Personal Features"
• Select the checkbox that is appropriate for you

Ever had to merge SharePoint lists? Typically you can open them in Excel, copy & paste from one sheet to another and bob’s your uncle. Unfortunately this doesn’t work in all cases, especially when attachments are involved or the data uses lookup columns.

I’ve been playing about with MS Access 2007. It has a handy feature in that you can open SharePoint lists directly, as shown below:

You can then get to do pretty cool things with the list as it’s pretty much a DB table within access, albeit still linked to SharePoint.

It’s simply a case of using the ‘External Data | SharePoint List’ option to open the lists you need merged and copying/pasting from one table to another. There’s a couple of caveats here to be careful of though, namely:

• Your content types have to match across lists, otherwise it doesn’t work. You’ll have to switch into the query designer and map the columns manually.
• Beware of lookup columns. They’ll cause a ‘data integrity error’ if your data doesn’t match correctly. What I tend to do is paste a row in at a time and manually select the lookup value from the relevant column. This seems to sort it.

The plus side of using MS Access is that you can build up queries and reports from your SharePoint list data. Pretty powerful and not often mentioned!

I installed and configured SharePoint 2007 on a farm but ran into a problem accessing the site from the web front end servers.

When trying to navigate to the site, SharePoint would prompt for user credentials, no matter who you were logged on as and then return a 401 error.

Spence Harbar has a really good article explaining this issue which is caused by a security feature installed in Microsoft Windows Server 2003 Service Pack 2003 (SP1). http://www.harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx

He points to Microsoft’s KB article 896861, http://support.microsoft.com/default.aspx/kb/896861

which details two workarounds to resolve this issue.

Here’s an interesting post (http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=305) from Maurice Prather on SharePoint 2010 Web parts.

It seems that now your web part will be stored against the page if check in/checkout is activated against the page library in a WCM site.

Sounds useful as in previous cases if you exported your site the web part settings were lost. Now hopefully your web part settings will stay with the page during export or the web part itself will reappear in a previous page version if inadvertently deleted from the current page version.

The one thing I’m curious to see is if the page differences / web part differences are visible to the user from the SharePoint UI, rather than having to revert to a version and manually check for differences Could be a useful WinDiff add on for SharePoint.