As part of the development of a new Intranet product in Parity, I’ve recently spent some time looking into how making collaboration sites in SharePoint 2010 accessible.
First, we need to begin our discussion by defining what accessibility is:
Web accessibility refers to the inclusive practice of making websites usable by people of all abilities and disabilities. When sites are correctly designed, developed and edited, all users can have equal access to information and functionality. – Wikipedia on Web Accessibility
Accessibility is becoming increasingly important for all organisations. In the United Kingdom, there are some 10 million disabled people, who have a wide range of physical and mental impairments. The number of people with a disability is expected to increase as the UK’s population ages. As more services and information are made available online, it is important this web content is accessible to all users, and increasingly legislation is used to ensure organisations do so.
In the UK, public sector organisations are advised by the Central Office of Information (COI), that sets the minimum standard of accessibility for public sector web content as the W3C WCAG 2.0 AA guidelines. [Note, the COI will close down on 31st March 2012.] The RNIB also recommends this level of accessibility for all websites.
So, how accessible is SharePoint 2010, and does it meet the WGAC 2.0 AA guidelines?
SharePoint 2010 is designed with the WCAG 2.0 AA accessibility guidelines in mind, and offers a substantial improvement in accessibility compared to MOSS 2007. In particular, the following features have improved:
- Enhanced keyboard accessibility access to all functionality, to maximize device compatibility.
- Support for high contrast and different zoom modes.
Despite the new accessibility features (and in the case of ARIA, because of it), SharePoint 2010 is not fully compliant to the WCAG 2.0 AA, with the main issues being:
- Legacy markup in master pages and page layouts that does not meet web (XHTML and CSS) standards.
- Use of Silverlight web parts.
- WebPartZone and WebPartPage introduce invalid HTML.
- ImageField – uses invalid HTML 4.1 to store image value.
- Rich Text Editor – makes use of WAI:ARIA markup that is not included in the XHTML specification.
The ARIA features significantly help improve the accessibility of SharePoint 2010. However, ARIA is a new specification, and has not yet been adopted as a standard, so older browsers and screen readers do not support the ARIA implementation. Additionally, the WAI ARIA attributes have not been defined in the DTDs for XHTML or HTML, so will cause validation errors when a web page using them is checked using an automated validation service such as W3C’s Markup Validation Service. This is not a minor issue – many automated accessibility validators will also validate a web page against the web standards and so raise errors against ARIA accessibility features. In order to be fully compliant to the WCAG 2.0 AA guidelines, some of the ARIA accessibility features would need to be stripped from SharePoint 2010, reducing it’s usefulness to users using assistive technologies.
The ARIA issue also points to a more general issue. Simply using an automated accessibility checker will not give you a proper understanding of how accessible a website is. In general, accessibility checkers are good for raising issues around invalid HTML markup, and for identifying possible regions that may need further manual inspection. But to fully assess accessibility will also involve user testing by people who have different disabilities and who make use of different assistive technologies. Typically, the user testing will be conducted by an organisation with experience in providing accessibility audits, such as the RNIB.
As an aside, the various accessibility validators (WAVE, TAW, etc) do not give identical results when checking the same page against WCAG 2.0 AA, so if meeting the guidelines is a part of a contractual obligation and will be used in user acceptance testing, the validation tool to be used must also be agreed in advance.
Of course, the above only deals with developing an accessible SharePoint solution. In order to maintain a site’s accessibility, the content uploaded to the site must be assessed as part of a content approval process to ensure that it is accessible. HiSoftware’s Compliance Sheriff for SharePoint is a compliance tool recommended by Microsoft to aid this process.
Whilst the accessibility of SharePoint 2010 has significantly improved, there is a substantial effort to implement a site that is fully compliant to the WCAG 2.0 AA guidelines. However, making a site accessible is not the same as being compliant with the accessibility guidelines.
In Parity, we have looked at the above issues, and have put in place solutions to fix the common accessibility issues for SharePoint 2010. If you are interested in discussing our new SharePoint Intranet solution, please get in touch.
You may find the following articles of interest:
- Accessibility and SharePoint 2010
- Achieving Accessibility in SharePoint 2010 [PDF] [Word]
- SharePoint 2010 – Web Standards and Accessibility [Online slideshow, with download option]
- Evaluating Website Accessibility – an old but still relevant guide to assessing website accessibility for developers.
- Problems with using Website Validation Services – an analysis of the issues when attempting to validate a website using only automated tools.