Blind man’s feet from Shutterstock
In an ideal world, every staff member would be able to access the intranet regardless of role, location or disability. In reality, many staff do not have access to the intranet and accessibility needs are rarely thought about, let alone acted on. However, worldwide legislative changes to create equality in web sites are having a positive impact on improving intranets.
In this article we focus on the three tiers of action necessary to provide broader accessibility for intranets:
- strategic: making the commitment to provide an accessible intranet
- technical: building accessible components into systems
- tactical: providing education and tools for content publishers
The common definition for accessibility is that a product, service, environment, or facility should be usable by people with the widest range of capabilities. A rule-of-thumb definition for accessibility on intranets is that any staff member, regardless of disability, age, cultural or linguistic background or situation, should be able to use the intranet, and its tools.
An accessible intranet can be a fundamental part of an overall positive user experience for all staff.
International standards exist for web accessibility and these are also applied to intranets. These standards are commonly referred to as Web Content Accessibility Guidelines (WCAG 2.0). Within the standard there are three levels of compliance from A (basic) to AAA (highest).
Accessible intranets are easier for everyone to use
Disabilities that impact staff
Many different types of disabilities can impact a staff member’s ability to use an intranet. The main categories relating to intranets specifically include:
- Visual – from blindness and impaired vision, to colour blindness
- Physical – limited motor skills, or repetitive strain injuries, making it difficult to type or use a mouse
- Cognitive or neurological – difficulty concentrating, comprehending or remembering, or attention deficiencies
- Situational – difficulty in noisy and/or distracting environments
For example, within Australia 18.5% of the population have some type of disability. While many disabilities do not affect using an intranet, it is not a small figure. (Source: Australian Bureau of Statistics: Survey of Disability, Ageing and Carers, 2009). Predictions by the World Wide Web Consortium indicate the range of disabilities will increase with our ageing population and workforce.
Benefits of an accessible intranet
An accessible intranet will ensure that all staff are treated fairly and are able to access this important organisational resource. While many organisations focus on the legal compliance requirements of an accessible intranet, the strongest benefit of an accessible intranet is that it is more usable for all staff.
Current moves towards multi-channel delivery of intranets to desktops of varying sizes, kiosks, mobiles and tablets, are much easier with an accessible intranet. Intranet teams who have already put thought and effort into accessibility will have an advantage in repackaging content for different devices.
Other benefits of having an accessible intranet include:
- A focus on accessibility demonstrates the organisation’s commitment to all staff. This moral consideration is a compelling benefit.
- As the intranet becomes the focus for the digital workplace and the launch pad for staff to access other systems, accessibility problems within the intranet can effectively limit staff access to these other systems.
- Other non-disability related issues, such as slow connections in regional offices, can be improved by accessibility options.
- Improved accessibility can also increase usability for older people, people with low literacy or users not fluent in the language of the intranet.
- Sensible accessibility guidelines can standardise document formats, and for example, encourage the use of PDFs when sensible, not because it is easier for the publisher, providing a benefit to all staff.
An accessible intranet is the path to other systems
Understanding assistive tools
Many tools exist to assist people with disabilities in everyday life, for example wheelchairs, hearing aids or large button phones. Internet-related assistive tools need to be incorporated into thinking about intranets too.
One of the most common issues that the intranet team will need to address is providing access for visually impaired staff. Inclusion, and customisation, of a screen reader is one way to do this.
Screen readers are important tools for visually impaired people, enabling them to listen to web pages. Screen readers translate written text from a screen into audio, allowing users to hear word for word what is on each web page. Most screen readers have synthesised voices and can sound very robotic, but the pitch, speed and tone of the voice can be altered to speed up the process. Customising the screen reader enables staff to work faster and more efficiently with the intranet.
Both Windows and Mac computers include basic screen readers, however many visually impaired staff use dedicated programs, such as Jaws (for Windows).
Legislation may provide visibility but action is needed
Strategic: the commitment to have an accessible intranet
Senior executives can state “our intranet must be accessible”, but these are hollow words without commitment of resources to deliver an accessible intranet.
A strategic commitment to an accessible intranet includes:
- formal acknowledgement of which sites are included
- stated owners for accessibility (both business and technical)
- time allocated within projects for accessibility testing
- money to skill team members in accessibility techniques and / or engage external expertise
- genuine belief in accessibility principles held by intranet team, developers and senior stakeholders
The benefits of accessibility can take time to become clear in an organisation, and even longer to be firmly embedded in practice. Legislative changes can provide the momentum but true commitment is achieved by understanding the benefits.
Technical: building accessible components into systems
Most intranets are run on a content management system (CMS) or other publishing platform. Different products provide varying levels of accessibility compliance with WCAG 2.0 standards.
The first aspect is the page templates and designs that are used for the intranet. In many publishing tools, these are developed separately and then ‘loaded into the CMS’. If these templates are designed to be accessible, then a good CMS should not get in the way of publishing them.
(Note that earlier versions of SharePoint, however, are particularly problematic in this regard – see later in this article for more).
The other aspect is the content written by authors using the publishing tool. Ideally, the product should assist (and even enforce) accessibility at the point of authoring. Products vary greatly in this regard, and this should be assessed carefully when choosing a new publishing tool.
Separately from this is any applications or custom code developed for the intranet, either by a vendor or in-house. It is much easier for developers to build in accessible components from the start. The development and update process must then have embedded accessibility awareness, design and testing.
Tactical: education and tools for content publishers
Ideally technical solutions can minimise any accessibility issues on the intranet. However the last piece of the puzzle is to ensure that content publishers do not introduce any accessibility issues for example with poorly designed tables or graphs in page content or attachments like PDFs.
All staff working on the intranet need some accessibility skills
The varying degrees of ability and interest found among decentralised publishers can be daunting for intranet teams. Sometimes it is hard enough to get clear structured content, let alone make it accessible.
The successful approach is two-pronged:
- Build understanding and empathy by demonstrating how difficult inaccessible pages are to use. A live demonstration of someone using a screen reader is a powerful persuader.
- Minimise the skills publishers need by developing simple cheat sheets that match your CMS and explain the basic standards for accessible content in the organisation.
A word of warning: don’t make accessibility an extreme sport and punish those who stray from the standard. Little progress will be made, as fear and trepidation can stall content publishing. Instead empower, reward and recognise good examples of accessible content to help create long-term commitment to accessibility.
For more information see the earlier article How to empower authors.
Good accessibility can be 90 per cent taken care of with good templates (technical) and governance (tactical). If everyone does their job, from the content author to graphic designer, to web publisher, the intranet can be highly accessible.
Building accessibility capability
At the strategic level, a clear understanding of why accessibility is needed and how it affects staff will be essential. Seeing examples from other organisations and understanding how staff work can develop this capability.
For technical staff, formal training or mentoring by accessibility experts will be required. As the impact of accessibility on web sites has been clear for a few years now, there are also many developers who have this capability.
For the intranet team, capability building in accessibility can be a mixture of self-education, on-the-job training and attending seminars and workshops. Some web-oriented higher education courses now include an accessibility component. WCAG 2.0 requirements naturally fit with people who prefer detail-orientated work, so consider this when assigning responsibility within the intranet team.
Many organisations offer expertise in accessibility in the form of mentoring, workshops and consulting. Seek these out to build up capability within the organisation.
Building understanding is more effective than a big stick
Elements of an accessible intranet content page
There are many variations to page layout and design on intranets. This list is a small snapshot of ways in which accessibility can be improved on content pages.
- Describe meaningful images in text
- Do not rely on colour for meaning, and use sufficient colour contrast
- Make sure link purposes are clear
- Explain graphs and charts
- Summarise tables and make sure they can be read line by line
- Include captions and transcripts of video content
There are subtle variations for many of these elements and this is where a detailed understanding of accessibility is needed. For example, useful image descriptions can be interpreted merely as an alt text for each image, which displays text describing the image to be read by a screen reader. But if an image is on the page only to increase the visual appeal, it adds no value for the screen reader to recite “dog called Rosco running on green grass in park with blue sky”. It may be more appropriate to say nothing.
The intranet team’s detailed understanding of the purposes of every element of the design needs to be informed by specialty accessibility expertise along with consultation with the content authors.
SharePoint and accessibility
Many teams we work with use SharePoint for content and document management and collaboration. Over the years SharePoint has greatly improved its built-in accessibility compliance with WCAG 2.0 standards. From version 2010 onwards, many parts are compliant with 2013, rating even higher.
Out of the box, later versions of SharePoint have a reasonable degree of accessibility. But the story does not end there customisation changes by in-house developers or implementers can reduce the overall accessibility of the intranet. For example, teams need to ensure that developed web parts do not include non-visible components that cannot be read by a screen reader.
At the tactical level, it may be necessary to provide more than one way to do things.
For example, Vision Australia’s intranet includes the ‘people picker’, which is provided as a quick way to assign permissions and tasks to other users for collaboration.
This function is accessible for some users but is not well supported by assistive technology. Rather than try and customise this functionality, Vision Australia decided to adopt the use of the alternative address book (select people and groups) function in addition.
(These two approaches are shown in the screenshots on this page.)
For more details on accessibility in SharePoint 2010, see the Vision Australia SharePoint 2010 Accessibility white paper
There are a number of tools in the marketplace to test the accessibility of an existing intranet, for example the WAVE tool (wave.webaim.org). These include simple tests you can do, such as pressing the tab key to on your keyboard to see where the cursor moves to. It is also possible to engage specialist organisations that provide comprehensive testing services and reports.
The results of these tests can be both a blessing and a burden. In many cases being able use a report to highlight the poor state of accessibility can garner support and action to improve accessibility. However we have also seen the opposite effect as the ‘accessibility problem’ becomes overwhelming and gets put into the too-hard basket.
Consider what effect the results will have in your organisation before proceeding. Whatever the results are, each organisation still needs to focus on strategic, technical and tactical approaches to accessibility.
As part of any intranet team’s self-education journey, these resources are useful:
- Web Content Accessibility Guidelines (www.w3.org/TR/WCAG/)
- Developing a web accessibility business case for your organisation (www.w3.org/WAI/bcase/Overview.html)
- For Twitter users watch the hashtag #a11y (accessibility has 11 letters hence the cute adaption)
- Designing with people, some examples of what people can and cannot do (www.designingwithpeople.rca.ac.uk)
- A list maintained by W3C initiative on the applicable legislation for different countries (www.w3.org/WAI/Policy/)
Achieving an accessible intranet
Many intranet teams, especially within government organisations, are achieving accessible intranets. However this does take commitment, time and resources. The ideal time to do most of the work is when a publishing process is implemented rather than trying to retrofit an existing system. However, with care, retrospective approaches can work.
Don’t get overwhelmed by the task. Start at the strategic end and secure commitments, ensure technical solutions are as accessible as possible and involve staff with disabilities in testing. Then finally empower and support content publishers to deliver accessible content.
Thanks to Raven Calais, Dey Alexander and Andrew Arch for their input into this article.