Chapter 13

Accessibility in SharePoint

In Chapter 1 you had a brief introduction to accessibility as it relates to Web design. You saw a little bit of the reasons why accessibility should matter and some of the potential consequences of not taking it seriously. But this exposure to accessibility was meant to be merely a cursory overview of this critical element of Web design. It wasn't meant to be a truly deep-dive approach; that is what this chapter is for.

In this chapter, you should hopefully come away with a much more solid understanding of what accessibility means, how it affects today's Web design, how SharePoint measures up, and what you can do as a SharePoint developer to make things better.

As part of this last point, you will be introduced to some free tools that are available that, if used properly and for what they were intended, can really move your SharePoint installations much closer to accessibility compliance. Will you be Priority 3 compliant (don't worry; you'll get to know what that means a bit later in this chapter)? Probably not. But at least you will know where the shortcomings are and be able to talk intelligently about them. And maybe work toward new solutions that can help figure some of these problems out.

Accessibility Today

Accessibility, in its simplest definition, would be “making the Web available to everyone.” You might be thinking, “The Web is available to everyone already.” Is it? Imagine going to your favorite site while blind. Is it still available to you? What happens to all of the flashy graphics and maybe the multimedia functionality of a site that depends on mouse clicks when there is no mouse attached to the computer accessing this site?

The most common perception of what accessibility means are matters that affect those with some sort of impairment (usually visual), so it makes sense to start there. To get an idea of what this might mean to you as a Web developer, consider the study commissioned by Microsoft in 2003 (performed by Forrester Research, Inc.) to look at how many working-age adults could benefit from the use of assistive technology (http://www.microsoft.com/enable/research/workingage.aspx). The numbers, shown in Figure 13-1, might surprise you.

So what do these statistics mean? Well, the easy thing to point out is that 45.9 million working-age adults are likely or very likely to benefit from visual accessibility considerations in Web site planning. There are several things to take note of in these results. First, these numbers only represent the US population. That is 45.9 million American working-age adults that are likely to benefit from visual considerations in accessible Web design. Second, these are people who would not considered “disabled” in other studies. In other words, these 45.9 million Americans are not considered legally blind. Finally, these are working-age adults age 18 through 64 years of age. This doesn't include the increasing number of under-18 crowd, as well as senior citizens, who are getting more and more involved in the Internet. So this means that 45.9 million Americans age 18 through 64 who are not otherwise classified as disabled would still benefit from visual assistive technologies in Web design. That is a pretty huge number.

So what do these numbers represent, financially? Most things in business eventually come down to money, after all, so it is worth asking. Can there be a financial impact to not providing accessible Web design? The answer is, of course, yes.

The United States Department of Justice reports that Americans with disabilities have approximately $175 billion in discretionary income (http://www.ada.gov/busstat.htm). Add to that the approximately £45 – 50 billion (almost $100 billion) for the UK reported by the Employers' Forum on Disability (http://www.employers-forum.co.uk) and you have a staggering amount of disposable income from people with disabilities. And, again, those are just the ones classified as disabled; not the ones reported earlier in the Microsoft report. And, maybe more important, that is just from two countries (USA and UK). Project those numbers on a global scale and you begin to get an idea of what this can mean financially. If there are two sites these people can go to in order to get what they want and one is accessible to them and one isn't, guess where those hundreds upon hundreds of billions of dollars are going to go?

A new consideration is getting a lot more attention in the realm of accessibility in today's Web market. Too often, people think of accessibility as only extending to the handicapped (usually the visually impaired), but this is becoming recognized as a short-sighted definition of the topic. To take the mouse-click example at the beginning of this section further. Who has a mouse hooked up to their cell phone? Today's cell phones are capable of accessing the Internet at high-speed rates. But if when they get there, everything looks chaotic, unorganized, and unusable, how long will the mobile user stay there? Not long. And that is a reality of today's world. People surf the Web on the mobile phones or smart phones in airports, in the taxi, or on the commuter train. Basically, anywhere it's not practical to break out the laptop, people are more and more using their phones to do basic Internet browsing. And if your site isn't accessible to these users, they will go somewhere that is.

So how many phones are being used to surf the Web today? A January 2008 report by M:Metrics, a company that specializes in tracking and reporting mobile usage, shows the following statistics (http://mmetrics.com/press/PressRelease.aspx?article=20080318-iphonehype):

Mobile Subscriber Monthly Consumption of Content and Applications M:Metrics Benchmark Survey: January 2008

The first interesting number worth mentioning in this chart is the total number of mobile subscriptions worldwide. If you add up the entire first row of numbers, you will see that there are approximately 660 million global cell phone subscribers. Now, if you do some quick analysis on the numbers, you will also find that there are over 70 million users who access news and information from a browser from their phones while over 20 million users access social networking sites from their phones. Is this surprising? This is the future of the Web. And if your Web site isn't accessible to these devices, many without a mouse and with limited CSS/JavaScript support, you will have unhappy customers (or, likely, lost customers).

Guidelines for Accessibility

The generally accepted authority on accessibility in Web design is the World Wide Web Consortium, commonly referred to as W3C (http://www.w3.org/). This group creates policies and guidelines for creating accessible Web sites. It also provides definitions and links to services that may help you with your own sites. Under this group, a set of guidelines called the Web Content Accessibility Guidelines (WCAG) has been released. The current version (as of writing this chapter) is still WCAG 1.0 (http://www.w3.org/TR/WCAG10/), which was published May 5, 1999.

Generally speaking, most accessibility compliance is measured by compliance with one of three priority levels published by the W3C (copied from their site):

• Priority 1 A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
• Priority 2 A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
• Priority 3 A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

So, according to these definitions, every site in the world should be, at a bare minimum, complying with the Priority 1 checkpoints, which include things like using alternative text for all non-text elements (images, animations, frames, and so on). When you start looking at Priority 2, you will find things like not using tables for structural layout (for example, only use tables for tabular data, not to lay out your page design). Finally, Priority 3 includes things like identifying the primary language (such as “en-us”) of the Web page in the HTML element tag at the top of your page. Many will find Priority 3 difficult, if not nearly impossible, to adhere to. But most people can go to at least Priority 2 compliance if they make a concerted effort to do so.

You can see a full list of the guidelines and their associated priority levels at http://www.w3.org/TR/WCAG10/Guidelines. You can see the guidelines grouped by priority at http://www.w3.org/TR/WCAG10/full-checklist.html.

Accessibility in SharePoint

How accessible is SharePoint? The short answer is, honestly, not that great, out of the box at least. Take, for example, the checklist of accessibility guidelines provided in the last section (http://www.w3.org/TR/WCAG10/Guidelines) and measure SharePoint up against those guidelines to see for yourself:

One thing to keep in mind is that you, as the developer, need to store these checkpoints in the back of your mind for your own development. This checklist only measures the things that SharePoint does by default. So, for example, in checkpoint 2.1, the criterion is, essentially, that the site does not use color-only indicators to convey meaning. So, with the default key performance indicator (KPI) reports SharePoint has, it uses color identifiers that are also distinguishable by their shape. A green circle, a yellow triangle, and a red diamond are examples of the indicators used in these reports. So, even if the user cannot distinguish green from red (common in color-blind individuals), that user should be able to indicate a circle from a diamond. And, even if the images are turned off, appropriate alternative text is provided to convey the meaning of the indicator. So, no matter who accesses those reports, they should be able to get the same meaning from them.

If, however, you go and create your own report and set up the title to be green for good, yellow for warning, and red for noncompliance, you will have a problem. Someone who has visual impairment may not be able to see the colors appropriately and, as such, will not be able to tell which items are okay and which ones are in danger of being out of compliance. SharePoint may meet the guideline on its own, but that doesn't mean you can't go in and manually break it. So be careful. And be informed.

The Checklist in the Real World

While the checklist will be useful for many, it might be more useful to actually see what this means to a typical user. To do this, first take a look at a standard site created using MOSS 2007 using all of the defaults, shown in Figure 13-2.

Now take a look at the same site as seen in a Windows Mobile 5 Emulator, as shown in Figure 13-3.

It's not the same experience, is it? Now take a look at the site with all CSS and JavaScript turned off (which is typical of some text browsers), shown in Figure 13-4.

You will see that this is, in fact, in the more accessible mode (as evidenced by the link “Turn off more accessible mode” at the top of the page). While it doesn't look completely crazy, there are some things you have to take note of. For one, look at all of the URLs in the Announcements grid. For example, the text reads “/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser” for the first line entry. It is not resolving the {ItemUrl} parameter and is not even creating it as a link. The same is true with the Edit in Browser links. This is not a very usable interface at this point, which means that it scores pretty low in the accessibility department.

One thing to note in this scenario that is not evident in the screenshot is that some of the critical navigation is no longer working. On both the Windows mobile device and the browser with no CSS or JavaScript, the user has no way of getting into, say, the Site Actions menu (if signed in). That menu relies on a mouse event triggering a JavaScript event handler. The mobile device has no mouse and therefore no mouse event, and the browser has JavaScript disabled and therefore no availability of the JavaScript function that brings up the menu.

So this means that, out of the box, SharePoint installations won't display or function properly in mobile clients and probably won't display or function properly in most assistive technology browsers. It is certainly not Priority 2 or 3 compliant but, sad to say, it probably is not even Priority 1 compliant.

In the next sections, you will learn of some of the ways you can get around some of these limitations and make your site a bit better off. You may not be able to get all the way up to Priority 3 compliance, but you should be able to achieve Priority 1 and maybe even Priority 2. Or at least know where your obstacles are and decide if there is a way to get past them in your own projects.

Customizing SharePoint for Accessibility

So, with the information to this point, you might be a little apprehensive. SharePoint, at least out of the box, doesn't even meet the Web Content Accessibility Guidelines (WCAG) Priority 1 level of compliance. Especially if you are in a public sector environment, where accessibility is so vitally important, you might be thinking “Should we really use SharePoint?”

The good news is that, with some diligence and planning, you can make your installations much better. In fact, with enough work, you can certainly meet Priority 1 compliance and maybe even Priority 2 or 3. Those are lofty goals, of course, but if you recognize the issues and know how to integrate some freely available solutions, you can make great strides towards accessibility in SharePoint.

So, in this section, you will be doing exactly that: looking at some of the freely available tools to help with accessibility. The first tool will be the CSS Friendly Control Adapters that are available to all .NET 2.0 Web applications (not just SharePoint). However, the second tool, the Accessibility Kit for SharePoint (AKS), as the name implies, is targeted directly to SharePoint installations and can provide a lot of assistance to the accessibility conscious developer.

The CSS Friendly Control Adapters

One of the most commonly used tools for Web design back in the infancy of the Internet was tables. Using tables provided designers with a matrix for the rendered web page on which they could then lay out the various components of their site in whatever way they wanted. This allowed designers to fairly easily create the header, navigation, sidebar, content, and footer sections that are so predominant in the Web. Tables were easily nested within other tables to allow an even greater level of control over appearance and functionality for the final design. And, unfortunately perhaps (for this discussion), tables pretty much always worked, regardless of what browser a user used to access your site.

However, tables provide a very real problem with regards to accessibility. And this becomes even truer when you start nesting these tables. This is due in large part to the way assistive technology interprets the rendered HTML of a web page. Typically, these browsers read through the HTML in a linear order from the top of the page to the bottom of the page. If your navigation is buried in some nested table halfway down the HTML code, the user won't get to it until the reader goes through all of the preceding code first. These browsers will also often misinterpret the table as a data matrix and render it as such, which can confuse the layout of your final page a lot.

This is why, if you examine the checkpoints for accessibility earlier in the chapter, you will see several references to tables-based criteria. In fact, tables get their own entire Guideline (Guideline 5: Create Tables That Transform Gracefully). And one of the biggest offenses designers make, at least in regards to tables, is against checkpoint 5.3 (Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent [which may be a linearized version]). And, as seen earlier, SharePoint is no exception.

For example, look at the following code snippet that showcases the rendered output of a navigation control included in a standard SharePoint site:

This snippet is the actual rendered code for Figure 13-5.

The code snippet, if you can't tell from reading through it, represents the top-level menu, which, in Figure 13-5, includes “Wrox,” “Services,” “About Us,” and “MOSS 2007 Navigation.” For those four little tabs that don't even include any submenus, all of the code in this snippet was generated by the .NET Framework.

This creates at least two problems. One is that it's just sloppy. With that much bloated code, it loads slower and is harder to navigate through if you are, for example, trying to read through the rendered output to see what is going on.

The second problem, and probably more important on a global scale and certainly more important in the scope of this chapter, is its strike against Priority 2 compliance. Examples of how this fails compliance standards might include:

• Checkpoint 5.3 (Priority 2) Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
• Checkpoint 5.5 (Priority 3) Provide summaries for tables.
• Checkpoint 5.6 (Priority 3) Provide abbreviations for header labels.
• Checkpoint 13.6 (Priority 3) Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

Certainly the way the navigation is rendered makes the page fail Priority 3 compliance but, because the site is using tables to layout navigation, it probably fails Priority 2 compliance, too. So, just because of using the standard out-of-the-box ASP.NET menu control, something not exclusive to SharePoint, the SharePoint site fails Priority 2 and 3 accessibility compliance.

You might be thinking “So what can I do about that? It's out-of-the-box. I can't do anything about out-of-the-box controls!”

Well, actually, you can. One of the greatest traits of the .NET 2.0 Framework is its ability to be modified. While there are several ways to do this, one of the more interesting (and relevant for this discussion) is the introduction of the control adapters. Control adapters allow developers to override the functionality of standard controls to allow complete customization over their behavior. This can mean a lot of things. If, for example, you want to include a custom property for the control that tells the rendering engine, when included, to add a special property to the rendered HTML object, you can do that.

However, for this discussion, it can mean that you can override the non-accessible tables-based rendering of the ASP.NET controls and make them use more accessible standards. Generally, this means using CSS and better linearized HTML (unordered lists, for example).

Fortunately, an initiative was created by Russ Helfand to create a set of adapters specifically targeted at “fixing” the rendering habits of a set of ASP.NET controls to make them more accessible. These adapters are collectively referred to as the CSS Friendly Control Adapters and can be downloaded from their project page on CodePlex: http://www.codeplex.com/cssfriendly.

To see how these adapters work, take a look at the same navigation control shown before but now controlled by the CSS Friendly Control Adapters:

The first thing you will probably notice is that the code is considerably shorter. It is providing the same information (hyperlinks to other pages in the site collection), but it is all done through more accessibility-friendly methods. In this case, rather than using tables, the navigation menu is using unordered lists (<UL>) to create the navigation hierarchy and then applying CSS classes to everything to allow you, as the developer/designer, to control the look and feel of the menu strictly through CSS style rules.

Just by doing this, you have changed at least four of the “No” answers in the accessibility checklist included earlier in the chapter to “Yes.” To answer the four checkpoint items just mentioned in regards to the default table output, this new code solves these issues in the following ways:

• Checkpoint 5.3 (Priority 2) The navigation menu is no longer using a table to structure its layout.
• Checkpoint 5.5 (Priority 3) With no table, this is no longer relevant.
• Checkpoint 5.6 (Priority 3) Again, in the absence of a table for the layout of the navigation menu, this is no longer relevant.
• Checkpoint 13.6 (Priority 3) The menu is now encapsulated by a CSS <DIV> element with an ID of “zz1_TopNavigationMenu,” which groups the set of related links (the navigation menu) into a CSS DIV element.

So, simply by implementing the adapters, you now have a more readable layout in the rendered code (which should load faster) and you have answered some of the accessibility concerns of SharePoint.

Understanding the CSS Friendly Control Adapters

First, it's important to understand what control adapters are, as these are the foundation of the CSS Friendly Control Adapters. Essentially, control adapters, which were introduced in the .NET 2.0 Framework, allow developers to override the behavior of certain .NET controls. More specifically, these adapters are used to modify the rendering behavior of out-of-the-box .NET controls in certain (or groups of) Web browsers.

What this boils down to, though, is that you can modify the rendered output of controls. Basically, this means that you can change the menu control, for example, from outputting tables in its rendered HTML output to outputting DIV, UL, and LI elements that are styled through CSS rules.

So how is this accomplished? Behind the scenes, there are a number of class files with a bunch of methods that override the functionality of the control. For example, take a look at this snippet of code from the menu control adapter:

In this code, the method for building the navigation structure is taken over. Typically, at this stage, the CLR is creating table-based HTML code to store the navigation items. However, as you can see here, the first thing that is happening (of consequence) is this line:

This is creating an <UL> element to start the navigation hierarchy. A little later in the code, there is a foreach loop that calls a function called “BuildItem(item, writer).” This method is considerably longer and including the entire thing wouldn't add much to the comprehension of what is going on. However, within this method, you will find a line of code like this:

At this point, the BuildItem method is creating a new <LI> element for each menu item. The method continues on to add class references and other relevant items to the <LI> element but, at this point, you can hopefully get at least the 30,000 foot view of what is going on. This class is overtaking the rendering behavior of the out-of-the-box menu control and forcing it to generate much more accessible HTML elements in the place of its standard tables-based design. This is pretty cool.

So is this done automatically? Meaning, if you have this class file in your project, will it override the menu controls without you having to do anything else? Well, no. There is one other thing you have to play with: the browser file.

In .NET 2.0 projects (and above) there is a protected directory called App_Browsers used to hold *.browser files. The browser files' job is to tell the CLR which controls to override and, when overridden, which class to use to do the job. For the menu control, you would need to have a browser file in the App_Browsers directory with at least this much information in it:

The line that does all the magic is highlighted in bold in this snippet. In that line, you are telling .NET to override the control “System.Web.UI.WebControls.Menu” with the class “CssFriendly.MenuAdapter.” If you were to go back into the menu class file that the previous snippets were taken from, you would see that it starts off with:

This is how everything ties together. The browser pulls up the page and the .NET Framework looks in the App_Browsers folder to see whether it needs to do anything special. It sees that for all browsers (designated by the refID=“Default” property on the browser tag) it should use the CSSFriendly.MenuAdapter class when rendering out the standard menu control. So then it goes into the CSSFriendly namespace and loads the MenuAdapter class and follows the override methods included there for rendering out the control to the browser.

Before you ask, this incurs, at most, a nominal performance hit. In fact, it probably washes because the outputted page will load faster so any hit taken on the rendering will be recovered in the page load. Performance really isn't much of a consideration here; the outputted HTML is the big deal.

For more on control adapters (in general terms), you can read the Microsoft documentation here: http://msdn2.microsoft.com/en-us/library/system.web.ui.adapters.controladapter(VS.80).aspx.

Modifying the CSS Friendly Control Adapters

So, if these are just class files, can I modify them? Yes and therein lies the beauty of these adapters. These files were built with the intention that developers would take them as a starting point but hopefully not a complete solution. These file were, as noted, merely class files with references to them in browser files. As such, the code is very open source. The snippets for this chapter were taken by opening up the class files and copying and pasting them into the manuscript.

You have the full power to manipulate them. For example, say that you had business requirements that every menu control use the order list element (<OL>) rather than the unordered list element used in the adapters. You could simply open up the class file, go to the line in the code that generates the UL code, and change it to OL.

A real world example can be seen by looking at the GridView control adapter included with this tool. It still renders out tables. This is okay because even the WCAG guidelines allow for tables to be used for tabular data, which is really the only purpose of the GridView control. The adapter just cleans up the rendered HTML table (adding things like THEAD, TFOOT, and TBODY sections to the table and eliminating inline styles). However, if your company was determined not to use tables at all for any reason as it still provides an obstacle to readers accessing your site through assistive technology, you could go into the GridViewAdapter.cs file and change the rendering behavior to completely eliminate tables and instead use CSS HTML elements (DIVs, for example) to represent your tabular data. This might be a task more suitable for the intermediate to advanced developer, but it could definitely be done. And, while the WCAG doesn't require you to do this (yet), this would probably provide a better experience for your visually impaired visitors.

This demonstrates that although the CSS Friendly Control Adapters were created and released as a means of combating accessibility concerns that is not their only use. These adapters can be used to do whatever you need to do (with regards to rendering your controls in Web browsers, that is). These adapters, when used in conjunction with other tools like master pages and themes, can be a godsend at creating a .NET Web project framework that allows developers to just drop controls on their page and code against them. Any nuances that you need can be taken care of in a global sense without the developer having to worry about it.

Be warned, though. The adapters are not really for the faint at heart. If you are new to programming, you may not want to get in and tweak the class files much. For example, the C# example for the menu control adapter is 329 lines of code and, without some experience in coding, it will be hard to follow. But, with enough initiative and at least some experience, these adapters can be really fun to dive into headfirst and make some cool things happen in your own projects.

An Overview of the CSS Friendly Control Adapters

The adapters accommodate the following controls:

• Menu This is the standard navigation control provided in the ASP.NET 2.0 Framework. SharePoint uses this menu control for its top and side level menus and, as such, this control adapter can be very useful in your SharePoint projects.
• TreeView This is the control that provides hierarchy navigation much like you would experience in Windows Explorer (folder with sub-folders and files). This is used by SharePoint for, among other things, the Quick Launch menu.
• DetailsView This control is used to display a single record from a data set. This is typically used in conjunction with the GridView control that displays all of the records in a recordset and, when a row is selected, this control displays the details for just that one record.
• FormView This control is similar to the DetailsView control in that it is used to display a single record of a dataset. However, this control allows for the customization of how the data is displayed.
• GridView This is the standard control for displaying a matrix of data in ASP.NET. This creates a tabular representation of multiple rows of data and allows for things like pagination and sorting of that data. The SharePoint control SPGridView inherits from the GridView control.
• DataList This control is used to create a repeater, of sorts, where data bound to the control is repeated using a custom template that the developer creates. The custom template details are rendered out in a matrix of table cells (sort of like the address book in Outlook if you are familiar with that).
• Login This is a part of the ASP.NET Membership provider class. This control is the basic means for logging in with the default ASP.NET Membership provider. This provides textboxes for the user's credentials as well as a check box to keep the user logged in.
• ChangePassword This is a part of the ASP.NET Membership provider class. This control allows users to update their password by first providing their original password and then creating (and confirming) their new password
• PasswordRecovery This is a part of the ASP.NET Membership provider class. This control sends an email with the password for an account to the address used when the account was originally set up.
• CreateUserWizard This is a part of the ASP.NET Membership provider class. This control collects the necessary information to create a new account e.g., User Name, Password, Email address, etc. and then creates the new account.
• LoginStatus Part of the ASP.NET Membership provider class. This provides a login link to unauthenticated users and a logout link to those that authenticated users.

These adapters were created to fulfill a variety of needs. In the world of SharePoint design, many of these control adapters may not be very useful. For example, all of the login related controls are probably not going to be necessary for most installations because most installations will probably use Windows authentication since it is the default for MOSS 2007 and WSS 3.0. However, if your company chooses a custom authentication mechanism, such as the membership provider included in the .NET 2.0 Framework, then you may need these control adapters.

While most of the adapters are innocuous, meaning that they won't break anything by leaving them in there even if they don't do anything, there is one that is not: the GridView control.

The GridView control is a bit interesting anyway. Its purpose is not to eliminate tables. After all, CSS standards say that tables for data presentation are okay. The purpose of this control is to make the tables it renders better. It includes cleaner table code, as well as THEAD, TBODY and TFOOT tags for the table.

And, in the world of SharePoint, the GridView control probably isn't used that much. For the most part, when you are dropping a grid onto a SharePoint page, it is using the SPGridView control instead. While it is true that the SPGridView control inherits from the GridView control, it is distinctly different from the GridView if only by the namespace reference (Microsoft.SharePoint.WebControls.SPGridView). This means that, if your site is using the SPGridView control, SharePoint won't override it with the GridView control adapter. You would need to create a new control adapter specifically targeted at the SPGridView control to affect this control.

However, if you include the GridView reference in your browser file, you may incur a penalty. As seen in Figure 13-6, if you try to navigate to Manage Content and Structure under Site Actions, you will get an error.

So, if using the CSS Friendly Control Adapters in a SharePoint installation, you may want to remove the following line of code from your browser file so that you do not receive this error:

Or, even better, you might want to figure out what is causing the conflict and fix it. Then share your resolution with the world.

If you find resolution to issues like these, you can help modify the current code base so that others can reap the benefits of your discovery. This truly is an open source project now and will get better and better as more people contribute to its success.

As a final note in this section, many users are finding that they are having problems with the TreeView control as well. The biggest problem lies in the fact that if you navigate to Manage Content and Structure (under Site Actions) and you have the TreeView control adapter in place, you will get an unhandled error. This appears to be a problem with the way the TreeView adapter deals with the ViewState of the TreeView control and one solution (presented at http://forums.asp.net/t/1052121.aspx) showcases a way of modifying the adapter to change the way it controls ViewState.

So with this in mind, you might consider turning off the TreeView control adapter as well until a resolution is incorporated. To do this, make sure you remove the following line from your browser file:

While this is only relevant for Publishing sites, this can be a very big problem for those affected so it is worth looking at which solution works best for you in your scenario. While the ViewState solution fixes the problem for some, others found that it caused other problems (for example, the left navigation tree no longer worked when this solution was implemented).

Integration with SharePoint

As stated earlier, the CSS Friendly Control Adapters were engineered to be included in .NET 2.0 (and above) Web projects. And, since SharePoint is built on the .NET 2.0 Framework, it might seem logical that the adapters would easily integrate. But that isn't the case. Take a look at Figure 13-7 and you might get an idea of what the problem is.

Figure 13-7 shows the expanded view of a typical Web site that incorporates the CSS Friendly Control Adapters. There is the browser file in the App_Browsers directory, a bunch of class files (the adapters themselves) in the App_Code directory, some CSS in a CSS directory, and some JavaScript files in the JavaScript directory. There is a WalkThru directory there, too, but that only serves to provide examples on how to implement everything. In a real example, you would probably delete that directory.

Can you spot the problem yet?

If you have worked in SharePoint pages, especially if you have tried to inject any kind of .NET code into the page, you will probably notice the problem pretty quickly. The whole idea of control adapters involves using custom methods in a class file to override behavior. These class files are in the App_Code directory, which is typically fine for .NET applications. And, as such, the code is meant to be compiled into a DLL referenced in the production server. After all, that is generally the point of having class files. (It's bad practice to leave uncompiled source code in a production environment.) However, in the world of SharePoint, this can cause a problem.

So, the first problem is, how do you actually get the compiled class files in your project?

There are at least two ways of accomplishing this. You can download the source files and compile your own DLL, which gives you the ability to store the compiled file in your Global Assembly Cache (GAC), which in turn opens up the adapters to all web applications on that server. Alternatively, you can download a precompiled version of the DLL provided through the CodePlex project and, with a little bit of tweaking, install it on an application-by-application basis.

Both of these approaches will be discussed in more detail in the next two sections.

Installing the Adapters in the Global Assembly Cache

If you want to use the adapters on multiple applications on the same server, the best way to do this is to create an assembly and install it into the Global Assembly Cache (GAC) of the server. Once installed there, you will have access to the adapters in any .NET 2.0 application on that server (not just SharePoint).

The first step is to download the latest version of the source code from the CodePlex project at http://www.codeplex.com/cssfriendly. You will need to go the Releases tab and then download the ZIP file, CSSFriendly_1.0.zip, as this contains the source code (the other two files you can download from that page will be discussed in the next section). Extract all of the files to your computer, keeping the path information from the ZIP file. For the remainder of this chapter, it will be assumed that C: was chosen, meaning the project is stored in C:CSSFriendly_1.0.

Next, you need to open up the solution file that came with the download (CSSFriendly.sln) in Visual Studio (2005 or 2008). With the project open, you will see in Solution Explorer that there are three groupings: Solution Items, CSSFriendly, and the Web project. The first thing you need to do is to sign the CSSFriendly assembly. Expand the CSSFriendly class and you will see that it includes several sub-items, such as CSS and JavaScript folders and several class files. You will also see that there is an item called “Properties.” Double-click on this item to get the properties for the CSSFriendly assemblyOnce the properties window opens up, click the “Signing” tab. You should first check the option for “Sign the assembly” located near the bottom of the options. This will enable the “Choose a strong name key file” option. Click the dropdown box and choose <New…> to get the Create Strong Key Name dialog box. Enter a name for the file and provide a password (optionally). Now save your project to make sure your changes have been saved (following the good general practice of saving often).

Now build your new assembly by selecting Build from the Visual Studio toolbar and choosing Build CSSFriendly. This will create a new DLL file in the following location (assuming the path used at the beginning of this section): C:CSSFriendly_1.0CSSFriendlyinReleaseCSSFriendly.dll.

The next step is to simply copy this DLL into your GAC. The GAC is a common repository for .NET applications that allows you to copy/install strongly named and signed DLLs for reference by any .NET application on that server. This allows you to have a single source of code to share among multiple applications. It also allows a level of security by keeping the codebase in a server folder rather than a web application subdirectory. So, even if you aren't sharing out your code, it's not a bad idea to store your signed DLL files in the GAC when possible.

The easiest way to install the new DLL in your GAC is to have two instances of Windows Explorer open and to simply drag the DLL from the release folder to the assembly folder (typically C:Windowsassembly). This will automatically install the DLL and make it available to your applications.

The next thing you need to do is go back into your CSS Friendly project in Visual Studio and open up the CSSFriendlyAdapters.browser file located in the App_Browsers folder of the Web project. This is the file that tells the rendering engine to use the code in the adapters when rendering out the controls rather than the default rendering behavior. This is done through a line similar to the following (this is for the menu control):

The first property, controlType, is telling the .NET compiler what object this applies to. In this case, it is going to override the System.Web.UI.WebControls.Menu control. The second property is telling the compiler what adapter to use. The browser file included with the CSS Friendly Adapters is telling the compiler to use CSSFriendly.MenuAdapter. In the scenario expected in this project, that is fine because this is telling the compiler to look for the CSSFriendly namespace in one of the project class files.

In the scenario this section is working with, the problem is that the namespace will be in the GAC, not in a project class file. So you need to modify this code to something like the following:

The part you have added is telling the adapter where in the GAC to locate the namespace you are referencing. You can find the information (Version, Culture, and PublicKeyToken) by right-mouse clicking the assembly in the GAC and selecting Properties.

You need to make this change to all of the controls that you want to override. In other words, if you want to keep using all of the control overrides provided in the default browser file, you need to modify each one to point to the GAC assembly.

Once you have your browser file updated, you need to copy it to the global browser file on your server, typically located here at C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIGBrowsers.

Once you have the browser copied to its global folder, you need to compile the browser file and install it in the GAC. Fortunately, there is a tool already installed on your server as part of the .NET 2.0 Framework. So, in order to use the tool, first open up the Visual Studio Command Prompt (Start ⇒ Programs ⇒ Microsoft Visual Studio 2005 ⇒ Visual Studio Tools ⇒ Visual Studio Command Prompt) and type out the following command:

The last thing you need to do is modify the compat.browser file to remove the last four tags included in that file (InfrawareSamSung, InfrawareLG, InfrawareSKY, and InfrawareMotorola). This file is located at C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12CONFIG.

You need to make this same change to any compat.browser file located in any previously (and future) created SharePoint sites in IIS as well. These files are typically located in a directory using this path: C:InetpubwwwrootwssVirtualDirectories<Your App Pool>App_Browsers.

At this point, you should have your CSS Friendly Control Adapters installed in the GAC and shared out to all SharePoint installations on that one Web server. Of course, if you are going to use the adapters on multiple servers, you will have to follow these steps on each web server. However, for multiple applications on a single server, this approach has a lot of appeal. On the other hand, if you only have a single SharePoint installation on the server, this might be overkill and you may find that the approach showcased in the next section better fits your needs.

Using the Precompiled CSSFriendly DLL

While installing the adapters in the GAC is a valid approach, it might be overkill for a single SharePoint installation. In such cases, you might find it easier to just use the pre-compiled assembly provided by CodePlex and only apply it to the one installation. This section will highlight exactly how to do that.

Well, first, a little back history. When the adapters were first introduced, they were maintained at the following address: http://www.asp.net/cssadapters/. While this address is still valid (and still very useful), the code was moved to its new home at CodePlex in March 2007. It was moved there in an effort to make the code more open source and invite others to participate in its enhancements and maintenance. It is also possible that the project was moved to CodePlex to legitimize the product and make it easier to find. Regardless of the reasons, it was moved there.

While not much has been done to the project since it moved (the release available on CodePlex is still 1.0, which is what was available on the previous site), there is one interesting change that is noticeable: they compiled the DLL for you. Additionally, they provided separate download links to allow you to download only the DLL and/or the browser file (two separate downloads). This means that you can, if you find it useful, just download the bare essentials, set them up to work with SharePoint, and then you are good to go.

While this is a very cool way to use the adapters, especially if you don't have the need to customize anything beyond what is already being customized, there are a couple of problems with this approach. The first, as just stated, is that you can't modify anything since the DLL is already compiled. The second, which is a bigger deal, is that the DLL isn't signed, which means it can't go in the GAC.

So what does that mean? If you can't install it to the GAC, is it useless?

Well, it introduces a new level of complexity, but it is not useless. It would probably be much better if it were signed but, if that is really a huge issue for you, you could certainly download the source file, sign the project, and compile a DLL you could use in the GAC.

However, to avoid doing this, you might consider putting the DLL in the BIN directory of your SharePoint. After all, if you look at the directory structure set up by SharePoint during installation, you can see that there is, in fact, a BIN directory (you will also see that there is an App_Browsers folder as well). You can see these folders in Figure 13-8.

So, if you download the DLL and the browser file, you should be able to put them in the BIN and App_Browsers folders, respectively. And, in some cases, you can do exactly that and be done.

However, in many cases (if not most cases) this won't work exactly as you would hope. The reason is that, by default, your SharePoint site is probably set with a minimal trust level. And, at this level, SharePoint lacks sufficient permissions to execute code in the BIN directory. So, if you simply copy the DLL and browser files as described, you will get the error message shown in Figure 13-9.

If you look in the event log for the error that occurs, it simply gives you this:

Since neither of these things is particularly helpful, you might get frustrated and decide this can't be done. However, this can be done, and you have a couple of ways of resolving this issue.

Again, the problem is that SharePoint sites running at the WSS_Minimal trust level cannot execute code in the BIN directory. So what might the logical resolution be? Change the trust level.

In any .NET application, there are the following trust levels:

• Full
• High
• Medium
• Low
• Minimal

You can read more about these trust levels here: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a55fb31b-5b42-476d-9cae-050ab3fae307.mspx?mfr=true.

However, in addition to these trust levels, SharePoint establishes two additional trust levels:

• WSS_Minimal
• WSS_Medium

These trust levels were created to extend the “Medium” and “Minimal” trust levels of ASP.NET for SharePoint. By default, SharePoint installations are set to WSS_Minimal. While all of the ramifications for setting various trust levels are not pertinent to this discussion, the one thing that definitely is relevant is which ones allow you to run code in the BIN directory. WSS_Minimal does not; WSS_Medium does.

Changing the permission level is surprisingly simple. Go into the Web.config file for the SharePoint application and look for a line that looks similar to the following:

Now change it to use the WSS_Medium trust level, as such:

While this does work, it's probably not a good idea. There is a reason the default is set to minimal, and opening up the trust level just so you can get the adapters to run out of the BIN directory isn't a good idea. There are a whole slew of things (such as unrestricted permission on SQLClientPermission and essentially unrestricted permissions on the FileIO) that you will also open up with doing this and it's just not worth it.

So what is the alternative? There are really only two trust levels used by SharePoint? One works but you probably shouldn't use it and the other doesn't work at all (in regards to what you are trying to accomplish in this section at least). So what is the alternative when the only two provided options don't work? Create a third option, obviously.

The nice thing about the trust levels as that they are regulated through a config file stored on the server, typically in the following folder: <<Program Files>>Common FilesMicrosoft SharedWeb Server Extensions12config.

So if, for example, your Program Files directory was stored on your E drive, the configuration file for your WSS_Minimal trust level would be the following: E:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12configwss_minimaltrust.config.

So think about what has been discussed to this point. There are two options, neither of which work. WSS_Medium is too open and WSS_Minimal is too strict. You need to create a new trust level that keeps the strictness of WSS_Minimal but allows you to run code in the BIN directory. This means that you want to start with WSS_Minimal and open up one thing: the ability to run code in the BIN folder.

So, with that in mind, make a copy of WSS_Minimal.config and call it something that makes sense. For the remainder of this section, the file will be called “WSS_cssfriendly.config” and the associated trust level will be referred to as “WSS_cssfriendly.” This will let you know that this trust level was created in order to accommodate the CSS Friendly Control Adapters. However, it will also result in allowing code to run in the BIN folder, so if something else like “WSS_Bin” makes more sense to you, feel free to use that. Just substitute your name every time you see “WSS_cssfriendly” in the examples in the remainder of this section.

So, once you have your new file, the first thing you will want to do is add a reference to the SharePointPermission class in the SecurityClasses section, as seen below:

The next step is to add a new permission set that is given the right to access the object model. A permission set is simply a collection of permissions that can be applied to one or more assemblies. The easiest thing to do is to find an existing permission set in the file, copy it, and then modify it slightly. So, in order to do that, search through your config file for a permission set that is called either “ASP.NET” or “SPRestricted” (you probably have one or the other but not both). It will resemble this:

Now make an exact copy of this section and paste it directly below the copied code. You will need to modify it slightly, as shown below (changes in bold):

The last thing you need to do in the configuration file is to add a code group that lets the CLR know which assembly or assemblies the new permission set should apply to. Keeping this in mind, there are two alternatives for setting up the code group: Allow access to a single assembly or to the entire directory. Obviously, the more conservative approach is to only allow access to a single assembly. Short of having a strongly typed name sitting in the GAC, this is the better alternative. It opens up the security you need to access the functionality you need for the adapters without opening up the entire directory to execution rights, which has some security repercussions.

So, to do this, you would need to add the new code group immediately below the “FirstMatchCodeGroup” group by adding the following code:

Notice that the PermissionSetName property is set to wss_cssfriendly. This is a pointer to the permission step you set up in the previous step. Also notice the IMembershipCondition element and the URL directory. As you can see, it is being set to only open up the CSSFriendly.dll assembly in the BIN directory of the current application. This is fairly tight control over what is specifically opened up beyond the WSS_Minimal Code Access Security level.

However, you may have the need to run multiple assemblies and do not want to set up new code groups for each assembly. If this is the case for you, realize that you do have the ability to turn on code for the entire directory. Just understand that this is not the recommended approach and you are opening up a bigger security hole by doing this. However, if you feel the need to open up the entire BIN directory, you can modify the above code to the following (changes highlighted in bold):

You are now finished with the changes to the configuration file. Save your changes and then go back into the web.config file and make the following addition (in bold):

This step sets up the availability of the newly created trust level, WSS_cssfriendly. You can see that you are simply giving it a name and then giving the physical path to the policy file you just created.

The only step left is to set your site to use the new configuration. So, back in web.config, locate the trust setting and change it to the following:

You have now created a custom trust level based off of the WSS_Minimal trust level and set your site to use this new trust level. A summary of the steps involved would be:

• Create a new policy configuration file (wss_cssfriendly.config)
• Create a new trust level in web.config to reference the new policy configuration file
• Set the site's trust level to use the newly created trust level in web.config

Now, if you reload your application, it should resemble Figure 13-10.

At first glance, you will probably think this didn't work. After all, both the top-level navigation and the QuickLinks are missing. However, if you look at the rendered HTML code, you will see the following for the top-level navigation:

So, this rendered code proves that the adapters are working. The rendered output is now DIV, UL, and LI elements rather than tables. This is the point of the adapters.

So why doesn't it look like it's working? Well, the answer is quite simple: There are no CSS rules set up for this control. Look back at the rendered code again and you will see all kinds of new CSS class references like “AspNet-Menu-Horizontal.” There are currently no CSS rules set up for this class. Or, for that matter, any of the class elements rendered out. So you have to set those up. Although setting up the CSS rules is not really the focus of this chapter, some pointers for doing this can be found in the next section. You can also find out where you can get a deeper dive into styling the adapters at the end of that section.

Tips for Styling Your New Controls

While the point of this entire section is to point out the usefulness, especially in regards to accessibility, of the adapters and how to get them integrated into your SharePoint installation, you are going to have to style the controls at some point. This chapter wasn't really intended to be a long CSS tutorial. Even so, it might be helpful to cover a few important styling considerations.

The first thing to think about is to always use the designated custom property of any control you are overriding to set its CSS class. This property has been named “CssSelectorClass.” For example, in the top-level menu, you might want to set it up as follows:

Doing this will change the first DIV element in the rendered navigation menu to the following:

As you can see, this gives a CSS class to the DIV element. Why is this important? Well, if you have more than one horizontal menu, you are going to need more than one class of CSS rules. This allows you to distinguish one control from another in the page. With the menu control, this might not be that big of an issue. But as you begin overriding more controls, this will probably come in handy.

The next thing to remember is something that is fairly unique to SharePoint (that doesn't happen in standard ASP.NET pages). When you create your menu, if you haven't noticed, it has a slightly different hierarchy than you might expect. Specifically, the navigation is set up as follows:

• Wrox
• Services
• About Us
• MOSS 2007 Navigation

Even though the navigation comes through in one line in the tables version, in the CSS version, there is one main menu item and then the others come in a second UL list immediately below it. This can cause some unique challenges when styling these menus. It's not as cut and dry as some of the walkthrough examples that assume all of the main menu items are on the same level. So, as you dive into the menu control adapters, make sure you keep this nuance in mind.

The next thing to think about is using the proper DOCTYPE. While this might seem like a master page issue, it has some serious repercussions for how your CSS works in any given browser. For example, you probably will want to use the XHTML Strict Document Type Definition (DTD) to ensure standards parsing mode by your browser. For example, place the following line at the top of your master page (or modify the one that is there) to ensure you are using the XHTML Strict DTD:

Finally, with all of the styles coming from CSS, make sure you test this a lot and in several different browsers. The thing that makes this tricky is that, not only are you providing cosmetic styling, you are providing positioning, which will always make a CSS developer cringe just a bit. Every browser seems to handle floats and position differently. So you need to make sure that if you get the menu styled the way you want it in IE7 it works in IE6. And then jump over to Firefox and maybe even Safari. If your site passes all of those, you're probably okay. But it wouldn't hurt to hit a few more browsers if you have the time and means.

To get some more tips on CSS, consider picking up Beginning CSS: Cascading Style Sheets for Web Design, 2nd Edition (Wrox Press, ISBN: 978-0-4700-9697-0) by Richard York. It has some really great detail on floats and positioning that will probably help you out in this endeavor.

CSS Friendly Control Adapters Resources

Hopefully, if you have gotten this far, you have a fair understanding of what the CSS Friendly Control Adapters do and how they can help you with your own sites, especially in regards to accessibility. As you saw earlier in the book, SharePoint, out of the box, doesn't even meet Priority 1 compliance, which are the guidelines for what every site must have. With this in mind, it's important to dissect where SharePoint fails and what you can do about it. As you saw in the checklist provided early in this chapter, there are some very specific points where SharePoint fails that it just shouldn't. Some of these failures are directly related to the rendering behavior of the controls that SharePoint uses. The CSS Friendly Control Adapters help overcome this hurdle. They allow you, as the developer, to take over the rendering habits of these controls and make them provide output that is much more accessible. For example, with the menu control, you saw that you could take a completely tables-based navigation system that fails accessibility compliance and make it provide a CSS navigation system using HTML elements, such as DIVs and ULs, to provide the hierarchy of the navigation system and then CSS rules to provide the styling. This can really help the accessibility-conscious developer move towards a more compliant solution in the SharePoint sites he creates.

However, at this point in your exposure to the adapters, you will almost surely want to find out more. Unfortunately, there aren't a whole lot of places out there yet that deal with the adapters, especially in regards to SharePoint. However, there are a few really good resources.

The first is the original site of the adapters: http://www.asp.net/cssadapters/. This site has some really amazing walk through discussions, code examples, and white papers to help you get started. Granted, it's all targeted towards standard .NET 2.0 Web applications, but the content is really good and you will find a lot of solid examples on how to implement the adapters (which you will probably be able to take directly into your SharePoint installations).

Of course, the CodePlex site where the project is currently maintained is a good source of information as well: http://www.codeplex.com/cssfriendly/. This site has discussions and an Issue Tracker and other relevant tools to help you get started and get you through the difficult scenarios you will almost surely find yourself in. While the adapters take some work to get going properly, it's worth the payload and this site can help you with the work.

There is also a dedicated forum at www.asp.net for the adapters: http://forums.asp.net/1018.aspx. This site is routinely reviewed by the adapters' creator, Russ Helfand and several other experts in the field, not to mention several people that may not be experts but have gone through some of the same things you might be going through and might be able to share some fixes they figured out. This is always a good place to go try to find answers to issues you run into or to ask for help.

Finally, you might also consider picking up Professional ASP.NET 2.0 Design (Wrox Press; ISBN: 978-0-4701-2448-2) by one of the co-authors, of this book, Jacob J. Sanford. This book has an entire chapter of the ASP.NET 2.0 CSS Friendly Adapters and discusses them further in the chapter on navigation (using the adapters for the menu control) and then in the “Bringing It All Together – A New Theme” chapter (to show how to turn off the adapters in some scenarios). While this book is targeted at ASP.NET 2.0 Web applications, it provides a solid foundation of the adapters and some real-world advice on their use.

A Final Thought on the CSS Friendly Control Adapters

This majority of this section relied on the assumption that you were going to use the CSS Friendly Control Adapters as some sort of compiled application rather than using open source code on your server. As such, you were first shown how to compile your own code and install it into your Global Assembly Cache so that it is sharable among all of your .NET applications. This approach provides the extra flexibility so that you can adjust the adapters if you like and then compile and share them among all .NET applications, not just SharePoint. You also saw how to use the precompiled version provided in the CodePlex project in a single SharePoint installation. This approach involved adding the DLL to your BIN directory and allowing access to the DLL by creating a custom code access security level.

However, there is at least one other option that is worth mentioning (and will make more sense in the next section): using uncompiled C# source code files in the App_Code folder of your Web project. As stated earlier, this is not a good idea because you are leaving source code on a production server that can be opened by any text editor (such as Notepad). If there is a list of best practices of Web application deployment, on the top of the list there would probably be something like “Never ever leave open source code files on a production server.” However, that being said, it is possible.

So, if you want the easy way out, you could simply add the “App_Code” folder to the physical directory for your SharePoint site and add the class files you need in your project there. You can then use the browser file in the same way you have done up to this point.

The final result would be a directory structure that resembles Figure 13-11 on the server and a browser file that resembles the following (this example is only for the menu adapter):

As you can see by Figure 13-11, you actually need MenuAdapter.cs and WebControlAdapterExtender.cs in the App_Code folder for things to work. This is because the MenuAdapter class references the WebControlAdapterExtender class so, if they're not both in there, things will break.

This will work. However, it would not be considered a best practice.

The Accessibility Kit for SharePoint (AKS)

One of the nicest things to come out in recent times, at least as far as SharePoint accessibility, is the Accessibility Kit for SharePoint (AKS) created by HiSoftware: http://aks.hisoftware.com. Before this came out, there just wasn't much out there for initiatives in making SharePoint accessible. In fact, most developers were of the mindset “if you want accessible design, SharePoint may not be right for you.” But there has been a tangible shift in momentum recently and accessibility is becoming a first-class citizen and the AKS is evidence of that.

So what is the AKS? Well, first, it's important to understand what the AKS is not: It is not a turnkey solution. This means that, while it is great at what it is, you as the developer should understand that it's not something you install on the server and by some dark magic your site is all of a sudden accessible.

Rather, AKS represents a means to make your site more accessible. Not surprisingly, one of its critical components is its own set of control adapters. Similar to the CSS Friendly Control Adapters already discussed, the AKS includes adapters to help override the rendering habits of controls often used in SharePoint. Currently there are more than 50 adapters to help you with a variety of things, including search boxes, blogs, wikis, Web parts, Excel, and more.

The adapters, as described in the discussions of the CSS Friendly Control Adapters, are just C# class files that you can use in your projects. However, one thing of interest is that the description of how to set up each of these adapters that comes with the download tells you to put the class files in the App_Code directory of your Web server for the SharePoint application. As stated earlier, this really isn't a good practice when it comes to production servers. So one thing you might consider is compiling these class files into a single signed DLL and installing that DLL in the server's GAC. This way, you get the benefit of the adapters on all installed applications on that server and also avoid having to leave open source code in the production environment.

The AKS also includes master page and CSS examples to help illustrate how to make more accessible designs. These include changes to the standard CSS files (such as core.css) and master pages (such as BlueBand.master) to modify things like absolute sizing, table structuring, and deprecated elements. These are a much better place to get started than the master pages and CSS files that ship standard with SharePoint.

The AKS even includes a few tools that may help you in your design tasks. For example, there is a tool called the AKS Size Utility that helps you convert fixed sizes to relative ones. For example, if you were using a 50 pixel width for a DIV element, this tool would help you calculate how many Ems (em is a relative unit of measurement used in CSS rules) that would represent. Unfortunately, it doesn't take an existing CSS file and modify it for you. Rather, it has a textbox that allows you to enter a number, a source format (pixel or point), and what the conversion should be to (em or percentage), and it calculates the conversion for you. This tool is kind of neat, but it would be nice if it included a bit more functionality.

And remember, this kit is meant to help you get on your way by showing you some best practices and providing some really useful control adapters specific to SharePoint. But understanding how to implement them is something else. In this chapter, you learned how to implement the control adapters. Similarly, you saw how to appropriately use and modify master pages and CSS rules earlier in this book. With the knowledge gained in this book and the help of the files provided in the AKS, you have a good start on creating a more accessible SharePoint design.

Tools and Validators

Now that accessibility is (hopefully) at the front of your mind, you will probably want to implement some tools to help you in this cause. Fortunately, there are few out there that are free and really helpful.

The Web Accessibility Toolbar was created by Vision Australia: http://www.visionaustralia.org.au/ais/toolbar/. This toolbar integrates directly into Internet Explorer (versions 6 and 7) and has some pretty cool features. For example, you can toggle CSS, JavaScript, and even images to get a better idea of how your site might appear to someone accessing your site through assistive technology. One of the best tests it to actually turn off CSS and JavaScript and see what happens. If your site looks unmanageable and un-navigable, then you know you have a problem that needs to be addressed.

Another great free resource is the accessibility validator from WebAIM (Web Accessibility In Mind): http://wave.webaim.org/. Using this site, you can enter in the URL of your site, and it will give you a report on how compliant the site is. If your site happens to be inaccessible from the Internet, you can actually copy in the rendered HTML code into a textbox and it will still run the report for you.

And, of course, as the author of accessibility compliance standards, the W3C has its own validator: http://validator.w3.org/. This validator, like the one from WebAIM, allows you to validate code based on a provided URL, an uploaded file, or direct input (by copying and pasting the rendered code into a textbox).

Finally, a similar tool is available from HiSoftware, the creators of the Accessibility Kit for SharePoint: http://www.contentquality.com/.

While nothing beats planning and thought in your design, these tools should help quantify exactly where you are at with your design. There are probably several other worthy candidates, but these will provide a robust set of tools to help get you on your way.

Summary

This chapter was probably a bit different from some of the preceding ones. While accessibility was mentioned in some of the earlier chapters and brought up here and there in some of the later ones, it wasn't the main focus. For this chapter, it was first and foremost the most important topic on the table. And, as you continue in your career (or hobby) as a Web designer, you will find accessibility will be more and more important as time progresses.

This chapter was also slightly different because it wasn't focused so much on what SharePoint does well, but more on what it could do better at. And then how you can help make it do better with a few free tools in your arsenal.

First, you were introduced to control adapters and their implementation in accessible Web design through the CSS Friendly Control Adapters project. You saw how these adapters can take over the rendering habits of many of your favorite .NET controls, like the menu control, and force it to use much more accessible HTML output than it does by default (no more tables!). You saw a few ways to go about integrating these adapters in your SharePoint sites. You can compile a strongly named DLL and install it in your GAC; you can use a compiled DLL in your BIN directory with a custom trust level; or you could simply use the open source code files in your production environment.

This provided a logical segue to the Accessibility Kit for SharePoint, which relies heavily on the control adapters. You also got a brief overview of what the AKS is and what it isn't and maybe you saw a little on how to use the files included in the kit.

And finally, you saw some free tools that can help you verify your site is accessible after you spend all that time trying to ensure that it is.

But, when it's all said and done, this chapter was meant to point out where SharePoint fails in regards to accessible Web design and how the developers in the world can work to make it better. And hopefully, after reading this chapter, you will go out and do exactly that.