About these guides
We understand that while there can be common aspects, organisations work in different ways and what works for one, might not fit so well with another. These guides are written as an example of what best practice might look like in your organisation, but it may be that you have to adjust what is recommended to accommodate your particular circumstances.
Similarly the guides do not include detailed technical information as this would tie them to a specific technology or set of circumstances.Instead the guides convey important principals and approaches that can be applied in any industry and using any technology.Where appropriate the guides reference other sites and resources which contain more technical detail at the time of publication/last review.
Introduction
This document is intended to give the reader guidance about what considerations they need to make when creating an IT Policy on Accessibility in their own organisation. The sections within can be used as sections in an organisation’s own policy. There are examples of policy statements that you may wish to tailor for your own use.
This document was created based on the experiences of Business Disability Forum members and is expected to be improved over time based on feedback.
Authors: John Wootton, EY
Lucy Ruck, Business Disability Forum
Sean Smith OBE, HMRC
Curt Holst, Barclays
Neil Milliken, Atos
Neil Eustice, KPMG
Matthew Legge, Lloyds Banking Group
Stephane Halle, Cisco
Vera Mogensen, GSK
Editors: Lucy Ruck and Bela Gor
28
Contents
About these guides 1
Introduction 1
Contents 2
1. Introduction 4
2.1 What is Accessibility? 4
2.2 Why create an IT Policy on Accessibility? 5
2.3 How to use this guidance? 6
2. What goes in to an IT Policy on Accessibility 7
2.1 Core Policy Detail 7
2.2 Ownership 7
2.3 Commitment Statement 7
2.4 Policy Intention 7
2.5 Policy Principles\Strategy 7
2.6 Related Policies 7
2.7 Policy Maintenance 7
3. Examples of policies focusing on understanding what your disabled users want, not what you think they want 8
3.1 Relationship Management 8
3.2 Listen to your customers 8
3.3 Let your customers know what you have done 8
3.4 Internal and External 8
3.5 Setting customer expectations on ICT accessibility 9
4. Examples of policies focusing on the range of hardware and software your disabled users might use 10
4.1 Assistive Hardware and Software 10
4.1.1 Examples of Assistive Hardware and Software Categories 10
4.2 Mobile\Cellular Devices 12
4.2.1 Hardware 12
4.2.2 Software 12
4.3 Communications Systems 14
4.3.1 Voice 14
5. Examples of policies to help ensure IT systems deployed are accessible to users with a disability 15
5.1 Solution Delivery Lifecycle 15
5.2 Procurement 17
5.3 Testing 17
5.3.1 User Experience Testing 17
5.3.2 End User Testing 17
6. Policies to help users who have a disability 19
6.1 Support Capabilities 19
6.1.1 Staff 19
6.1.2 Lloyds Banking Group (LBG) Reasonable Adjustments case study 20
6.1.3 Customers 22
6.2 Training 23
6.2.1 Classroom training 23
6.2.4 Web based / computer based training (e-Learning) 23
6.3 On boarding New Joiners and Integration with Other Processes 25
6.3.1 Prior to hiring a new joiner: 25
6.3.2 After having been hired: 25
7. Appendix 1 – Voice Communication Systems Requirements Used at Cisco 27
7.1 Hardware 27
7.2 Telephony 28
1. Introduction
2.1 What is Accessibility?
In the context of this document, accessibility is concerned with the process and practise of enabling people of all abilities to use technology. Therefore individuals who have a disability need to have their needs considered in IT solutions that are bought or built by an organisation, or the services it provides.
The World Health Organization estimates that there are over 1Billion people with a disability. The case for accessibility is that an organisation is likely to employ individuals with a disability or have customers who have a disability. Ensuring technology is accessible to all abilities can be a compliance requirement in many jurisdictions, it can also be commercially beneficial as it can open access to a marketplace that competitors may not be supporting as well as they could.
Disability and impairment may affect an individual in different ways. For example:
· Many people will not describe themselves as having a disability even though they have an impairment that means that they have legal protection from disability legislation in their country
· In several geographies working age is increasing as people work beyond traditional retirement ages. As a person is more likely to develop a new disability or impairment later in life this topic is becoming ever more relevant for retaining skilled and experienced staff in the workplace.
· There is always the possibility that a person can become disabled either temporarily through illness or permanently in their lifetime.
It therefore makes sense from a personal angle to remember that even if accessibility is not important to an individual right now, in the future they may well feel differently.
2.2 Why create an IT Policy on Accessibility?
The Technology Taskforce brought together a working group to create this guide because forum members observed:
· Accessibility can be seen as niche, complex and difficult to understand.
· While accessibility has a positive impact, it can be difficult to get buy-in from those not personally affected by it.
· Enterprise IT functions are complex and different teams may not understand what they should do individually about accessibility.
· Enterprise IT functions often have a governance process that supports the use of policy\principle\standards.
Creating an IT Policy on Accessibility can provide one single point of reference for all areas of IT to enable a cohesive approach to accessibility that fits in to enterprise IT governance structures.
2.3 How to use this guidance?
The guidance is just that, a guide to help you, the reader understand what you need to think about when implementing IT Policies on Accessibility in your own organisation.
It may be that you initially focus on specific areas and over time extend their reach and depth. All organisations have to start somewhere.
The details of implementing policies within an organisation can vary depending on their approach to IT governance. This guidance gives the reader a basic knowledge of what should be in an IT policy (in the absence of existing guidance in your organisation), as well as examples of areas to focus on.
If you implement any accessibility policies, we (The Technology Taskforce) would like to hear from you so we can improve this guide with real life examples of putting policy in to practice.
This guidance includes examples focused on four key themes:
· Ensuring the IT organisation recognises the needs of disabled users
· Ensuring the IT organisation knows which assistive technology disabled users need
· Ensuring that when new IT systems are deployed, they are accessible to disabled users
· Ensuring that the IT organisation can effectively support its disabled user base
2. What goes in to an IT Policy on Accessibility
If your organisation does not have a specific framework for developing policies, typically this is the information recommended by the authors.
2.1 Core Policy Detail
When publishing a policy, your organisation may have a specific template with key information that is required. It is recommended that the following information accompanies the policy.
2.2 Ownership
Who is the person or group, that readers of the policy should go to if there is any ambiguity or feedback about it? This person or group most likely deals with this topic on a daily basis.
2.3 Commitment Statement
A statement of the organisation’s commitment to the policy. This should include how it fits in to the organisation’s strategy, commitments and an expression of support from a senior figure e.g. CIO, CEO.
2.4 Policy Intention
Why the policy was created in the first place and what the expectations are on its usage. For example, it may be that the policy is a means of bringing together a collection of other policies and standards under a single umbrella so that they are easier to consume.
2.5 Policy Principles\Strategy
The principles of the policy may be that the policy enables the entire IT organisation to have a holistic understanding of what it needs to do to provide accessible products and services. The strategy alignment is key because the policy is possibly implemented in support of a specific strategy e.g. in support of a commitment to the Accessible Technology Charter http://technologytaskforce.org/accessible-technology-charter/.
2.6 Related Policies
The organisation may already have policies in place that should be referenced. For example polices relating to security and procurement. The relationship to them should be defined.
2.7 Policy Maintenance
The policy will need ongoing maintenance to ensure it is responding to the organisation’s needs. A maintenance cycle helps with this because on a regular cycle, the policy is tested to make sure it is valid, or needs further improvement.
3. Examples of policies focusing on understanding what your disabled users want, not what you think they want
3.1 Relationship Management
All organisations need to manage their relationship with their customers. A consumer facing organisation will have public customer considerations, a business to business organisation will have commercial considerations and an IT department needs to consider managing its relationship with its internal customers. There are a number of simple steps that can be applied to relationship management in any organisation with respect to accessibility which are summarised below.
3.2 Listen to your customers
· Systems that interact with customers must provide a mechanism to allow a customer to provide feedback on any improvements that can be made to the user experience. E.g. Barclays ‘Your Bank website’ that allows their customers to see the ideas that they have instigated because of their direct feedback https://www.yourbank.barclays.co.uk
· A disability may limit the capabilities of an end user from interacting with a system or service. To reduce the impact of this, alternative interface methods must be provided to enable the interaction that may be easier for the user e.g. email, phone, accessible web pages, text relay.
3.3 Let your customers know what you have done
· Ensure that you feedback to them on their suggestions and any changes that you have made and appropriately credit them with the ideas.
· Broadcast the changes that you have made, using social media (twitter, LinkedIn etc) to show what you have done. If the idea came from one of your customers demonstrate this as a means of listening to your customers.
3.4 Internal and External
· Develop a staff forum to get feedback from your internal colleagues, many of them will likely have disabilities themselves and have spoken to external contacts that have disabilities. Your colleagues should be able to provide you with honest feedback on how to make your system more efficient and to get more out of them.
· In order to develop a successful staff forum, ensure that you are open and available to individuals and publicise the events and outputs.
· Disabled individuals can often feel uncomfortable labelling themselves as disabled, provide an open invitation to all. Individuals who are carers or who have another interest in disability can also provide a valuable resource to you.
· Ask your staff forum to comment on internal as well as external issues. For example, they may also be users of your service and be able to provide you with valuable feedback on how to make improvements.
3.5 Setting customer expectations on ICT accessibility
· Always be clear on what is achievable and when.
· Only promise what you are able to deliver on, even if it’s done with good intentions, it won’t be constructive to raise expectations that are not met.
4. Examples of policies focusing on the range of hardware and software your disabled users might use
4.1 Assistive Hardware and Software
· Users with an accessible technology need may require specific software or hardware. Recognising what these are will help ensure that the organisation is well prepared for what end users may need.
· An organisation may find it useful to standardise these categories and technologies within them to help ensure testing of accessible technologies and procurement is more consistent.
· Some agility is required in the provision of assistive technology as rarely are the needs of two people consistent and users with similar assistive technology needs may actually benefit from using different assistive technologies to support them e.g. different screen reading or voice recognition software.
4.1.1 Examples of Assistive Hardware and Software Categories
Software
· Screen Readers (Text-to-Speech)
· Voice Recognition (Speech-to-Text)
· Screen Magnifiers
· Proofing tools, Note-taking & Literacy Aids
· Ergonomic Aids ad RSI (Repetitive Strain Injury)
· Mind Mapping & Organisation Aids
· OCR (Optical Character Recognition)
· Software for creating and reading sound files (eg Daisy files) such as Easy Producer and Easy Reader
· Software for creating Braille such as Duxbury
Hardware
· Keyboards
· Mice & Pointing Devices
· Headsets, Microphones & Recording Devices including Dictaphones
· Braille Devices e.g. Braille Displays, Pacmates and Embossers
· Telephony and equipment to support hearing impaired users (e.g. in face to face meetings)
· Magnifiers including CCTV systems
· Ergonomic Support Equipment
· Large monitors and monitor arms
· Scanners
· Personal printers e.g. for visually impaired users, or users with limited mobility
· Hardware specifically to enable a user to work from home or while out of the office. For example, laptops for users who would ordinarily have a desktop, 3G and / or broadband at home.
4.2 Mobile\Cellular Devices