Around the world there are legislative requirements that guarantee that services are accessible by those with impairments. In the UK, the Disability Discrimination Act of 1995 and the subsequent Equality Act of 2010 enforce these rights and in the US Section 508 of the Rehabilitation Act enforces them. These acts essentially place a duty of “reasonable adjustment” on organisations to ensure that all services they provide are accessible. When services are only available electronically, like intranets and many other web-based systems, the impact can be significant.
Examples of the types of compliance that is required include:
- Being able to use a screen reader to read the content of a web page – the challenge here is to ensure that screen reader reads the content in a manner that makes sense based on the content, rather than a straight forward left to right manner that make not make sense
- Zoom – Allow a user to zoom in to make the content on the page much larger and therefore more legible – the challenge here is to ensure text isn’t lost underneath other page elements
- Text – Ensure that any non-textual information, e.g. images or icons has alternative text descriptions
- Colours – Ensure that any information conveyed through the use of colour can be inferred without the colour. Allow the colours to be changed to those that are higher contrast – the challenge here is to ensure colour changes don’t have an adverse impact on the legibility of the content
How is this measured?
These challenges have been defined in many different ways via legislative bodies but there is only one technical way to measure accessibility: Web Content Accessibility Guidelines (WCAG) 2.0
It used to be that many web sites would have a self-certification on a page saying that their site was best viewed using certain browsers and that the site met on of the WCAG levels of compliance: A, AA or AAA, with AAA being the best.
With the advent of so many more ways of accessing web-based content using different browsers and different devices, less sites are self-certifying.
These challenges have been approached in many ways by different developers and that is fine if a custom solution is being built, but what about a platform such as SharePoint?
Historically, all versions up to and including SharePoint 2010 were woefully lacking in any type of compliance to accessibility requirements.
SharePoint 2013 made important improvements in the output of the HTML that allowed it to broadly adhere to accessibility requirements. The key with SharePoint is that it depends on the different features that are in use. There are no clear indications of the compliance of each feature in relation to the WCAG 2.0 guidelines.
The lack of compliance guidelines is in a great part down to the fact that there is so much dependence on “Content Creators” to ensure that their own content is compliant. However, Microsoft has provided guidance on “Accessibility features in SharePoint Online” which also applies to SharePoint 2013 and SharePoint 2016.
Other resources that contribute to accessibility for SharePoint are
- The ability to use Keyboard shortcuts which eliminates a dependence on a mouse.
- Specific consideration for accessibility in Office 365 Video
And finally, Microsoft have produced a “Voluntary Product Accessibility Template” in relation to the US Section 508 legislation. This is a summary of whether SharePoint meets the key regulations of Section 508. The overall rating is “Generally Supported”.
SharePoint is generally compliant with accessibility requirements, but to ensure full compatibility, all content editors should be fully aware of the requirements and be responsible for adhering to published guidelines setting out the do’s and don’t’s when producing accessible content.
The W3C has published the Web Accessibility Initiative which includes WCAG 2.0 and other standards and advice for general use of the web
BS 8878:2010 is a British standard to outline a frame work for accessibility when designing or commissioning web products.