What is accessibility?

In this context, accessibility is the process and practise of enabling people of all abilities to use technology. Therefore, organisations must consider disabled individuals’ needs in IT solutions and services.

The World Health Organisation estimates that there are 1.3 billion people with a disability. Any organisation is almost certain to employ individuals with a disability, and have customers who have a disability. IT accessibility 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 fall into the legal category of ‘disabled’ despite not identifying as disabled.
• In many places, working age is increasing as governments delay retirement ages and changes to social security require people to work later into life. Given that you become more likely to be disabled the older you get, IT accessibility is becoming increasingly relevant for retaining skilled and experienced staff.
• Disabilities can occur to anyone at any stage of life. They can be permanent or temporary.

Therefore, it makes sense to remember that, even if accessibility is not important to an individual right now, in the future they may well feel differently.

For more information about the importance of accessibility, see our resource ‘How accessibility benefits your business.’

Why create an IT policy on accessibility?

We brought together a working group to create this guide, because we found:

• 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. (Our resource ‘Obtaining management buy-in’ has more information.)
• Organisations’ IT functions are complex and different teams may not understand what they should do individually about accessibility.
• IT functions often have a governance process that supports the use of policies, principles and standards.

Creating an IT policy on accessibility can create one single point of reference for all areas of IT. This enables a cohesive approach to accessibility that fits in to enterprise IT governance structures.

How to use this guidance

The guidance is designed to help you understand what you need to think about when implementing IT policies on accessibility in your own organisation.

You may initially focus on specific areas, and extend their reach and depth over time. All organisations must start somewhere.

The details of implementing policies can vary depending on the organisation’s approach to IT governance. This guidance provides 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.

This guidance includes examples focused on four key themes:

• Ensuring the organisation recognises the needs of disabled users.
• Ensuring the organisation knows which assistive technology (AT) disabled users need.
• Ensuring that when new IT systems are deployed, they are accessible to disabled users.
• Ensuring that the organisation can effectively support its disabled users.

If you implement any IT accessibility policies, we (the Technology Taskforce) would like to hear from you. We always seek feedback so we can improve this guide with case studies of putting policy in to practice.

What goes into an IT policy on accessibility?

If your organisation does not have a specific framework for developing policies, we recommend including the following information in an IT accessibility policy.

• Core policy detail – When publishing a policy, your organisation may have a specific template with key information that is required. We recommend that the following information accompanies the policy.
• Ownership – Who should readers of the policy go to if there is any ambiguity or feedback about it? This person or group most likely deals with this topic day-to-day.
• Commitment statement – A statement of the organisation’s commitment to the policy. This should include how it fits in to the organisation’s strategy and commitments, and an expression of support from a senior figure – for example, Chief Information Officer or CEO.
• Policy intention – Why the policy was created in the first place? How should it be used? For example, it may be that the policy is a way of bringing together a collection of other policies and standards under a single umbrella, so that they are easier to consume.
• Policy principles / strategy – The principles of the policy may be that the it enables the entire organisation to have a holistic understanding of how to provide accessible products and services. The strategy alignment is key, because the policy may be implemented in support of a specific strategy – for example, in support of a commitment to the Accessible Technology Charter.
• 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.
• 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.

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.

Below are some simple steps that any organisation can apply to relationship management with respect to accessibility.

Listen to your customers

• Systems that interact with customers must provide a mechanism that lets customers provide feedback on improvements that can be made to the user experience.
• 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 – for example, email, phone, accessible web pages, text relay.

Let your customers know what you have done

• Ensure that you feed back to customers on their suggestions and whether you have made any changes. Appropriately credit them with the ideas.
• Broadcast the changes that you have made, using social media to show what you have done. If the idea came from one of your customers, demonstrate that have listened to your customers.

Internal and external

• Develop a staff forum to get feedback from your internal colleagues. Many of them will likely have disabilities themselves, or they may 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.
• To develop a successful staff forum, ensure that you are open and available to individuals. Publicise effectively its events and outputs.
• Do not limit forum meetings to people who identify as disabled – provide an open invitation to all regardless of identity. Many people who are legally disabled (or who could otherwise benefit from a good IT accessibility policy) do not identify as disabled. Furthermore, non-disabled 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 external as well as internal issues. For example, they may also be users of your products or services, and could provide you with valuable feedback on what could be better.

Setting customer expectations on IT accessibility

• Always be clear on what is achievable, and when.
• Only promise what you can deliver. Even if it’s done with good intentions, it isn’t constructive to raise expectations that are later disappointed.

Policy examples

Examples that could be included in an IT accessibility policy about relationship management could be:

• Feedback must be captured about customers’ experiences from an accessibility perspective.
• A forum must be available where anyone to provide casual feedback on accessibility and openly ask any questions.
• Where a process exists to support a stakeholder, the user must be directed to it – for example, reasonable adjustments / accommodations. However, if the user is not following the process for any reason, it should be understood why – in case there are problems with the process.
• When an accessibility feature is introduced, publicise it so users know that the organisation is active on this topic.

Assistive hardware and software

• Users with accessible technology (AT) needs may require specific software or hardware. Recognising what these are will allow the organisation to respond quickly to its users’ needs.
• It may be useful to standardise these categories (and technologies within them) to help ensure consistency in procurement and testing of accessible technologies.
• Some agility is required in the provision of AT, as disabled users’ needs are unique to the individual. Users with similar AT needs may actually benefit from using different solutions to support them – for example, different screen reading or voice recognition software.

Our resource ‘Assistive technology catalogues’ has more information about the types of AT available.

Policy examples

Examples that could be included in an IT accessibility policy about AT:

• Per organisational processes, if a user has been found to need a specific AT, IT teams will try to provide it.
• Any AT in use will be identified to ensure that IT build knowledge on what end users may need help with.
• IT teams test for compatibility with AT following a change – such as a change to a user’s computer or a major software update.
• End users of AT must be regularly consulted to understand how effective they are and whether improvements may be necessary.

Solution delivery lifecycle

When an organisation delivers solutions to its users or customers, it needs to factor in accessibility at appropriate points in the lifecycle.

An effective policy will state what role accessibility has in the lifecycle, what is expected, by whom, and how.

While delivery lifecycles can vary by organisation, typically these could be:

• Planning – Does the solution include accessibility as a requirement? What are the accessibility considerations the project team is expected to deliver?
• Design – Does the user interface design meet industry and organisational accessibility standards? Is the user experience as good for those who use AT as it is for those who don’t (or as close as is reasonably possible)?
• Build – Is the solution built according to industry and organisational accessibility standards, so reducing the risk of costly remediation later?
• Testing – Is the solution tested from the viewpoint of a user with an accessibility need? Has the solution been tested with AT – and does it operate as expected? If there are any accessibility constraints, are they documented and understood, including what the implications are? Is there an action plan for addressing them?
• Deployment – Does deploying the solution consider the needs and capabilities of a user with a disability? Are support processes in place to ensure users’ accessibility-related questions are addressed appropriately?
• Support – When a user with an accessibility need encounters difficulty, are there processes in place to ensure that they can ask for help? Will the people who provide help understand their needs? Will their request for help be taken seriously?

Policy examples

Examples that could be included in an IT accessibility policy on the solution delivery lifecycle:

• The solution delivery lifecycle must factor in accessibility.
• All projects must include accessibility as a non-functional requirement.
• All user interface design must conform to corporate accessibility standards.
• End user testing must include users using AT such as a screen reader.
• End user support materials must have sections tailored to the needs of users who may need accessibility features.

Examples from Technology Taskforce members

EY uses a web accessibility standard which incorporates points from Section 508 of the US’ Rehabilitation Act, the Web Content Accessibility Guidelines (WCAG), and WAI-Aria. This standard is used in all projects where EY deploys a web-based solution to ensure that they meet a minimum criterion of industry web accessibility compliance.

Atos uses a decision tree to decide on the appropriate standard to apply in a situation – see below.

Atos: Technology accessibility standards decision tree.

Accessibility as a core requirement

Every IT project should include accessibility as a core requirement.

Why should accessibility always be a core requirement?

Organisations have legal duties to anticipate disabled users’ needs and make adjustments / accommodations to include disabled people.

It is also good business to design project with accessibility as a core requirement. Customers who can’t use your products will simply go elsewhere. Research in the UK in 2019 found that the value of trade that businesses lost due to people simply ‘clicking away’ was £17.1 billion.

Furthermore, including accessibility as a core requirement from the beginning can save your business huge sums in retrofitting the product after it has been created. There is an old adage that an IT problem that costs £1 to fix in the design stage will cost £10 to fix in testing and £100 in live. The more rework you have to do, the slower and more costly the fix, and you can’t recover the reputational impact.

There are significant economic gains from accessible design. If your systems are easier to use, which accessible design tends to be, your staff will work more quickly and accurately, and spend less time on the phone to helpdesks. Customers will be more likely to access your digital services successfully, which in real terms means your customers and the computers will be doing most of the work for you. There is another saying about inclusive design: “If you design for the edges, you get the centre for free.” In other words, making things easier for disabled people to use also makes them easier for everyone.

How to specify accessibility as a requirement

You do not need to start with a blank sheet of paper: there are international standards that clearly lay out accessibility requirements for IT (both hardware and software). These standards have converged, so what meets the requirements in one market will likely work in the others.

For example, European Union governments have agreed on EN301 549, “Accessibility requirements suitable for public procurement of ICT products and services in Europe.” The US Government has Section 508 of the Rehabilitation Act of 1973. Although these only apply to IT supplied to Government or State-supported organisations, from a practical point of view it makes sense to develop products to meet them whatever your intended market. These standards are likely to meet the requirements of almost all customers, and there is plenty of guidance available to explain them.

Both EN301 549 and Section 508 refer to WCAG, the Web Content Accessibility Guidelines from the Worldwide Web Consortium. They extend the requirements of WCAG, which are solely about web-based systems, to cover all IT software.

As an organisation procuring IT, you do not need a wealth of technical knowledge to specify what is needed. You just need to say which standard(s) your supplier should meet.

The WCAG Standards include a requirement to be ‘Robust’, which includes the capability of working with assistive software (AS) packages. If you are procuring a system to be used internally, you can specify the AS to be used so that new software has definitely been tested with the packages your staff use.

There are suggested questions and examples in BDF’s Accessible Technology Procurement Protocol to provide guidance for staff dealing with procurement.

You can also download our Request for Proposal guide, with some helpful information to include in your organisation’s documentation.

As a developer or coder producing IT, you do need technical knowledge. The free WCAG website is there to help – it includes step-by-step guidance and examples of code to help you meet the standards.

It is crucial that procurement processes factor in accessibility in purchase decisions.

To help guide organisations with this, Business Disability Forum has produced a Procurement Protocol. This helps organisations set out a commitment to factoring accessibility into procurement across the organisation. It also includes questions to ask suppliers.

Business Disability Forum has also created a Procurement Toolkit, which contains further guidance.

Policy examples

Examples that could be included in an IT policy on accessibility about procurement:

• Any technology purchases must conform to the organisation’s accessibility standards and policies.
• All Requests for Proposal (RFPs) must contain base questions about accessibility and should be enhanced depending on the proposal.
• Vendors must be able to demonstrate how accessibility has been tested and validated in their products.

Testing

User experience testing

A policy regarding user experience testing for accessibility ensures that products and services the organisation delivers meet acceptable criteria for accessibility – rather than finding out from end users.

The policy must state how accessibility fits into the testing framework. This includes which standards or guidelines the testing will use, how any failures will be dealt with, and how testing will be performed.

End user testing

• When in project planning stage, consider user testing for AT – including text-to-speech, speech-to-text, screen magnifiers and other frequently used technology (see ‘Assistive technology catalogues’ for more information). Begin by identifying what AT you already have within your organisation.
• User testing for AT could be carried out by employees who are already familiar with the software. They may also be able to advise you on what improvements need to be made.
• If internal resources are not available (for example, due to pressure on time or priorities), external agencies can provide user testing of your systems. These include Digital Accessibility Centre and Freeney Williams.
• Test software before it is rolled out through your organisation. This could save money and ensure that you are providing an equal playing field for all your users.
• Consider user testing for both internal and external projects.

Policy examples

Examples that could be included in an IT policy on accessibility about testing could be:

• All end user-facing solution projects are to factor in accessibility in testing plans.
• Testing for accessibility complies with organisation accessibility standards.
• In the event of non-compliance with standards, the project must either change to comply, or to seek a standard waiver on a temporary basis. (What does temporary basis mean? In many organisations, teams may just seek a standard waiver because compliance is too expensive. To make this robust, advice should be given on what is meant by a temporary basis – for how long, why etc. This may be covered in your organisation’s approach to the governance of standards.)
• Testing must be performed with AT in use in the organisation.

IT accessibility policy for disabled staff

An organisation’s IT accessibility policy should recognise that:

• Some of its disabled staff may have different needs from non-disabled staff – for example, users with sight loss and wheelchair users may not be able to check their machines to make sure all the cables are plugged in.
• Some disabled staff also will use specialist software and hardware which, like any other IT, might need specialist helpdesk support.
• Disabled staff who use specialist equipment may not be able to work if their IT malfunctions – for example, they may not be able to switch to other generic devices in an office where those devices do not include the equipment they need. This might also apply to disabled staff that use specialist furniture (for example, raised desks). Such cases may therefore have to be prioritised or escalated.
• Disabled staff can find it difficult to explain to a helpdesk that they have disability, especially if they feel they have to justify their need for help.
• Some staff may have issues using IT which, whilst not severe enough to meet the legal definition of disability, may need support from the IT helpdesk – for example, help with basic accessibility features provided by devices.
• Confusion over who is responsible for funding an adjustment (or accommodation) can hold up the process of deploying the adjustment. We recommend centralising funding to streamline the process and avoid questions of funding. This should be mentioned in the IT accessibility policy, with the detail covered in finance policies.

Given the above, an IT accessibility policy may require:

• Staff records to be flagged in some manner so that disabled users can be readily identified at the start of an IT helpdesk call. Disabled users to be asked if they consent to IT helpdesks keeping records about their AT needs.
• Standard questions asked by IT helpdesk staff to be tailored for a disabled audience.
• The helpdesk provides expertise in specialist tools – for example, by a dedicated team, with standard helpdesk questions designed so that appropriate cases are filtered to this expertise.
• All helpdesk staff to have basic disability awareness training and specialist staff to have higher levels of disability training.
• Not all calls to an IT helpdesk may be able to be resolved remotely. Arrangements may need to be put in place for provision for local support – for example, from engineers, managers, colleagues. As with IT helpdesk staff, field engineers need basic disability awareness training.
• An IT accessibility policy may require organisations to measure the support given to disabled staff for comparison with data for staff generally. With more products to go wrong, it is likely that disabled staff may raise more calls per head than the average for all staff generally. Organisations may have a policy that resolution times for disabled staff should be no longer than the average for all staff.
• Given that disabled staff may be disproportionately affected by IT faults, organisations may wish to monitor this data and include disabled staff representatives in its helpdesk performance analysis and discussion.

Training

When providing training, you must ensure that it is accessible for all delegates including those with visible and less visible disabilities. This applies to classroom and online or computer-based training (e-learning).

This section gives you prompts for the things you need to think about to include in your policy.

Classroom training

Explain where and how the training will be delivered – for example, the trainer will use PowerPoint slides, videos, computer based or paper-based learning. For example, the training will be in a room that is on the second floor accessible by a lift; parking will or will not be available.

The trainer should anticipate access needs and have ensured that the training will be in an accessible venue and that videos will be subtitled. Delegates must be informed in advance of the materials that will be used, and invited to ask for alternative formats.

At the booking stage, ask every delegate if they have any access or communication needs. If any are mentioned that go beyond those anticipated, contact the delegate in advance to discuss their needs.

Mention any processes that delegates need to comply with for the training organiser to meet their needs.

Tip: Obtain this feedback with enough time that you can act on it before the training begins.

Preparing for the delegate

Have guidance for trainers / training organisers about:

• Making room for helpers and / or guide dogs to be sat with delegate(s).
• Allowing for additional time in exams, if the examining body makes this available for disabled candidates.
• Ordering printed material in correct format in enough time to be delivered to training facility. A delegate with sight loss may need larger print or may request a braille copy.

During training

Mention that course leaders should make themselves aware of any guidance about paying attention to needs of the disabled delegate(s) and of inclusion tips. For example, for delegates with sight loss who cannot see visual materials.

Online training

This type of training has its own challenges, and it is essential that you set out what you will accept as approved training material.

• State that all online or computer-based training is made accessible to a specified standard.
• State that the training is tested to ensure it complies with the chosen standard.
• If necessary, state that alternative formats will always be made available if the training cannot be made accessible to this standard.
• Mention documented guidance for any in-house course writers to show that your courses meet the approved standard.

Preparation for the learner

Ensure learners are prepared for any online or computer-based learning by being given:

• Guidance about equipment needed in advance.
• Assistance to order relevant equipment in a timely fashion before any course deadlines.
• Contacts for questions on accessibility needs if they cannot find what they need within the course itself.

Buying training in

If you are going to purchase your training from third-party suppliers, you must ensure that they adhere to your in-house standards. Show in your policy that you:

• Ensure you have documented the standards and levels you require your training to be built or prepared to. Make that documentation available to third party suppliers.
• Have all procurement or training teams made aware of training course requirements documentation for third parties.
• Have any procurement policies include accessible training procurement in them.

See our Procurement Protocol and our Procurement Toolkit for more information.

Disability training for IT personnel

IT departments can be extensive, so it is important that each part understands its role in providing an IT accessible environment. Examples include:

• General awareness of what disability and accessibility mean and why the organisation sees it is important. Ensure everyone understands the basics to enable a disability-inclusive IT team.
• Support personnel will need specific training on how to support end users who may have a disability or be reliant on an AT.
• Software engineering personnel must understand how to deliver accessible software products, in accordance with the organisation and industry standards.
• Testing teams must perform end user testing in the context of a user who may have a disability and highlight any challenges or barriers that they may face.
• Customer relationship management may need to educate their own customer contacts on the importance of accessibility. They will need to be prepared for potential challenges about why accessibility is important and what the benefits to the organisation would be.

Policy examples

Examples that could be included in an IT accessibility policy about training:

• Before any training takes place, delegates must have the opportunity to provide details of any accessibility needs they have.
• Training that is delivered online must conform to organisational standards for web accessibility.
• IT personnel must be trained on disability and accessibility – and how these apply to their own roles.

Onboarding new joiners

When a person with an accessibility need joins an organisation, there are extra considerations. Policies can help formalise this by ensuring that there is a consistent approach depending on the needs of the person.

Our Recruitment Toolkit has more advice on inclusive recruitment and onboarding.

Prior to hiring a new joiner

• Job application forms should be accessible. Applicants should be invited to ask for alternative formats or other methods of applying. For example, ‘download the plain text version here then send via email to xyzandxyz.com’ or ‘call / send email here for requesting assistance with this process.’ (See ‘Standardised application forms – Inclusive design and adjustments’ for more information.)
• Application forms should explain in detail what the application process will involve. Applicants must be able to ask for adjustments to any part of the process.
• Security / background vetting forms, if online, need to be accessible (or provide an accessible alternative version and process).
• More than one interview option – for example, online or in-person? What if the candidate has an accessibility need?
• Any online or computer-based assessments must be accessible. Applicants must be able to ask for alternative formats – or to demonstrate the competencies being tested in another way. (Our resource, ‘Designing inclusive tests and assessments,’ has more information.)

After having been hired

• New joiner forms should be accessible. Joiners should also be offered an alternative process or assistance (for example, to gain building access or to sign confidentiality agreements or contracts).
• Initial choice of (most wanted / common) accessible IT kit options – for example, for phone, laptop, keyboard, mouse.
• Access to guidance on how to customise IT kit (or workplace) to make it more accessible, and how to order additional adjustments or accommodations. For example, a web portal for information or process to raise adaptation requests.
• Ensuring onboarding training is accessible.
• Line managers should check in regularly with all members of their team and ask if they need any adjustments or accommodations, including to the IT they work with. These can be logged in a tailored adjustment agreement (if the organisation uses these). Our resource, ‘Tailored Adjustments Plans, Passports and Agreements for Businesses’ has more information.

Our People Manager Toolkit has more guidance for managers on supporting disabled members of their team.

Policy examples

Examples that could be included in an IT policy on accessibility about onboarding new joiners and integration with other processes could be:

• Online job application procedures must follow industry standards for web accessibility.
• An alternative procedure must be in place for candidates applying for roles who have difficulty in applying for accessibility reasons.

Procedures must be in place to keep in regular contact recent any new starters. This is particularly important if they have an accessibility need, to ensure that any adjustments / accommodations they need are being delivered.

See ‘Onboarding and induction’ in our Recruitment Toolkit for more information.

IT accessibility policy for disabled customers

An organisation’s IT accessibility policy should recognise that its external-facing websites, online services and other IT services must work for disabled users. It may or may not be appropriate for that organisation to offer direct support to those users:

• At one extreme, they may provide very specialist products to relatively small numbers of users and, under those circumstances, may feel it appropriate to support such users in a manner similar to the way staff are supported, with adjustments tailored to their individual needs.
• At the opposite extreme (for example, where any member of the public could access or purchase products or services), they may decide that such personal support is impractical at such a scale. In this situation, the organisation must anticipate the needs of their disabled customers and build systems that are as accessible as possible for disabled people with different access needs. However, this will not always be enough. If a disabled customer still cannot access a service because of their disability, the organisation must have a process in place whereby individual adjustments / accommodations can be made for that customer. Disabled customers must access the service in a way that is as similar as possible to the service enjoyed by non-disabled customers.

Organisations should also:

• Provide information on their website – for example, an accessibility statement, guidance on changing colours, font size and other features of the website.
• Provide information on their website about the accessibility of the service they are providing.
• Provide links to organisations who can provide more help.

Policy examples

Examples that could be included in an IT policy on accessibility about support could be:

• Supporting end users with a disability must not take any longer than users who do not. This would need additional context as there may be factors external to the organisation that affect this.
• Support staff need to be trained on how to support disabled end users. They must understand the organisation’s legal obligations to make adjustments / accommodations. For example, the user may not wish to discuss their disability or they may be frustrated at the impact the support problem is having on them.

Support staff must not make assumptions on what the end user can and cannot do. Treat all customers with respect and courtesy and ask them what they can do. For example, it may not be physically feasible for an end user to get under the desk and check a cable is plugged in.