This was part of a workshop on developing policy held in the Middle East in 2011 - the workshop looked at the issues that need to be considered within public and organisational policy to address the needs of people with a disability

1. Developing an Accessibility Policy
David Banes
Mada Center January 2011

2. Why Develop a Policy for Accessibility?
• Policy development establishes expectations for accessibility. For accessibility for people with
disabilities to be a consistent reality, an organization has to establish that accessibility will be
required and expected. Treating accessibility as an afterthought, or an add-on, ensures that people
with disabilities will have to struggle to get equal treatment.
• Policy development fosters cost savings on an organizational level.Planning for accessibility can
help to save time and money in the course development process. While accessibility training and
retrofitting will cost more up-front, such efforts should result in long-term savings as developers
become more skilled in creating accessible content.
• Policy development helps protect against costly litigation.As of this writing, there are no effective
standards for accessibility in distance learning or information technology access. However,
organizations could face future litigation seeking to enforce their rights under the UN Convention.
An organization with a policy in place for accessibility in this area will be much more likely to be
able to defend themselves against such litigation than an organization without such a policy.
• Policy development helps confirm organizational commitments to accessibility.Most
organizations have a strong commitment to inclusion and diversity which includes people with
disabilities. Drafting and implementing a strong policy regarding electronic accessibility reinforces
that commitment and helps to ensure that the campus will continue to be a welcoming
environment for all people.

3. Business Case
• Websites and technologies must address the needs of people
throughout the country. An accessible website can provide access
to information on a far wider scale than previously possible. Social
incentives for accessibility include:
– Disabled people have easier access to printed, audio or visual
material.
– Citizens can access services and information, regardless of experience
or ability.
– Everyone will find the website easier to use, improving their ability to
successfully complete goals online.
– People using all kinds of devices, from the oldest to the newest, will be
able to use the website, helping to reduce the impact of the digital
divide.
– Greater interaction between citizens and government is possible with
a user friendly, accessible website.

4. Business Case
• A user friendly and accessible website can help reduce costs both
directly and indirectly. Accessibility is often viewed as an expensive
afterthought, but it can provide many cost benefits. The key is to
build in accessibility from the outset, making inclusive design a
priority throughout the development lifecycle of the website.
Financial incentives for inclusive design include:
– Accessible web pages tend to be lighter (physically smaller) which
reduces bandwidth costs and improves page response times - leading
to an improved customer experience.
– Increasingly, people will be able to access services and information
online, representing a reduction in costs needed for ancillary
resources such as call centres.
– Ongoing maintenance and hosting costs can be significantly reduced.
– Providing one website that supports multiple audiences is more
efficient than running multiple websites for multiple audiences.

5. Business Case
• Technical concerns vary. According to capability, needs
of a small NGO will be different to those of a central
government body. However, improving technical
performance and delivering reliable digital services is
important across the board. Technical incentives for
inclusive design include:
– Following recognised standards and guidelines for
accessibility can help ensure that future technologies will
have access.
– Compatibility with more technologies such as mobile.
– Access to a wide range of assistive technologies.
– Improved levels of traffic may be driven to the site through
Search Engine Optimisation (SEO).

6. Developing an Accessibility Policy
• For organizations that do not have a policy in place, there may
be a tendency to spend a great deal of time developing a new
policy. However, there is little need to "reinvent the wheel" in
policy development. Many organizations have already
developed policies which cover information technology
accessibility, and others have developed policies that are
specific to the distance learning environment. Following the
best parts of these practices can be beneficial in developing a
new policy.

7. Document Sections
Purpose
Policy Statement
Scope
Compliance Requirements
Procurement
Testing and Validation
Monitoring
Designated Individuals
Complaint Process
Contact Information
Adoption & Implementation

8. Accessibility statement
• An accessibility statement is a statement of intention. At its most simple, an
accessibility statement will provide an open commitment to accessibility. An
example of a simple accessibility statement would be:
[Organisation name] is committed to ensuring that this website (or other forms of
technology) is accessible to the widest possible range of people. If you have any
questions or suggestions regarding the accessibility of this, or if you have difficulty
using any part of it, please contact us.
• An accessibility statement should contain the following parts:
– A clear statement that demonstrates the organisation's commitment to accessibility.
– Information about any areas of the system that do not yet conform to the overall accessibility
targets.
– Contact details for people wishing to report problems.
– A link to the accessibility policy.
• Accessibility statements should assume that the user has little or no knowledge of
design issues and should therefore limit the use of technical jargon (e.g. levels of
conformance to accessibility standards).

9. Accessibility Statement
• An accessibility policy must:
– demonstrate disability awareness;
– explain how disabled users are to be involved in the development of the website;
– state the level of conformance to be upheld; and
– plan how the level of accessibility will be maintained over time.
• The process for maintaining accessibility shall always include:
– a description of the target user population;
– the core tasks that users should be able to carry out;
– an analysis of user needs;
– the steps taken to meet those needs; and
– an evaluation of how successful the site or system is in meeting those needs.
• If there are areas of the website or system which pose potential problems for users with
particular impairments, an accessibility policy should contain:
– how the potential accessibility issues are to be addressed;
– how long it is likely to take to repair;
– how the service can be accessed by alternative means; and
– who to contact if there is a specific problem.

10. Policy

11. Scope
The Scope section should identify the entities (e.g., departments, authorities, universities,
contractors, grantees, etc.) that are required to comply with the policy. In the scope, you
also need to identify the service and programmatic reach of the policy. For instance, does
the policy require that all technologies conform to the accessibility policy and standards?
Key factors to consider when addressing the scope of applicability are:
• Who is issuing the policy?
• What entities fall under the authority of the issuing entity?
• Are they bound by the policies and standards that are issued?
You may want to cite any statutory authority, executive order, etc., under which the policy
is issued.
Care should be taken to use consistent terms to identify required entities. You also should
consider including the terms in the Terms & Definitions section of the policy.

12. Compliance
The Compliance Requirements section should address the specifications for
compliance with the policy, including the timeframe for implementation of the
policy and standards for new websites and technologies as well as for remediation
of existing ones.
Guidelines and Standards
Websites and online applications,
Public access terminals, such as ATMs, information kiosks, ticket vending
machines, Information displays, and card readers,
Telecommunication devices and services, such as desktop telephones, mobile
phones and Interactive Voice Response services,
Application software,
Smart cards and related media.

13. Procurement

14. What is a disability compliant IT solution?
• Answer 1: No idea
– How do you measure?
– How do you test for it?
– Does an IT supplier understand it?
• Answer 2: Everything
– All IT solutions are compliant with needs until…
– They create disadvantage for someone with a
disability which is then not addressed and…
– That person successfully complains.

15. What’s a better question to ask?
• Is your IT solution
accessible to people
with disabilities?
Specific and open

• What accessibility
standards does your IT
solution meet?
Too ambiguous


16. Vendors - Don’t take their word for it
• Has their solution been tested by people with
disabilities?
• How will they involve disabled people in the
development of the solution?
• Do they have reference sites?
• Will they let you test the solution yourself?

17. A recipe for success
4 simple questions

18. Do not purchase
Ok to purchase

Does
it meet recognised
standards?
Does
it pass your
testing?
Will
they commit to
compliance?
Is there an
acceptable interim
position?
Yes No
No
No
Yes
Yes
NoYes

19. Do not purchase
Ok to purchase

Does
it meet recognised
standards?
Does
it pass your
testing?
Will
they commit to
compliance?
Is there an
acceptable interim
position?
Yes No
No
No
Yes
Yes
NoYes

20. Testing and Validation
• Requirements for the testing and validation of accessibility should consider some of the known issues and
best practices that are related to evaluating accessibility.
• Known issues and recommended practices include: Automated and semi-automated testing tools can
provide valuable information about your product in an efficient manner. Both automated and manual
reviews, however, are necessary to ensure a comprehensive evaluation.
• Many automated evaluation tools are available on the market; each tool has different strengths and
weaknesses. An array of testing tools should be evaluated to determine which tool most effectively meets
your identified needs and requirements.
• Manually evaluating your entire system or site may not be possible. A manual evaluation should be
completed on a subset by individuals experienced with the applicable standards or guidelines.
• User testing is critical. Testing by persons who use, but are not reliant on assistive technology as their
normal means to access the web or technology, can result in unreliable results. A percentage of
evaluations should be completed by individuals with different types of disabilities, including those who are
experienced in using different assistive technologies.
• If individual entities are responsible for developing and implementing testing and validation protocol, it
could result in inconsistent practices and reporting. Consider devising a documented testing protocol to
ensure consistent and comparative evaluations across all entities responsible for testing and validation.

21. Monitoring
• In the Monitoring section, you should describe
the monitoring that will take place to
determine implementation and compliance
with the policy and standards.

22. Co-ordination, Complaints and Contact
In the Designated Individuals section you should identify an individual or an entity as
the contact point for questions or complaints about implementation and/or
compliance with the access policy and standards.
The Complaint section should address the complaint provisions that are in place
including the information that is required for a complaint, the process that is used to
file a complaint, and the actions or events that will occur once a complaint is
received.
In the Contact Information section of the policy, you should specify whether covered
entities need to identify a person or entity that is responsible for answering questions
and handling problems with the website or system.
Is this person different from the person or entity to whom formal complaints can be
submitted ?

23. Adoption and Implementation
This discussion is provided to explore strategies and activities that should be
considered to support the adoption and implementation of your accessibility policy
and standards.
It is not designed to be part of the policy document, but as a means to help you think
about what needs to be done to promote and support successful implementation.
First, you should consider your communications strategy.
How will you inform stakeholders of the policy and standards?
Will staff have the knowledge, skills, and tools to ensure compliance?
If not, what strategies need to be put in place to meet those needs?
Does training need to be provided? What level and what type of training is needed?

24. Adoption and Implmentation
Is awareness training needed at all levels (executives, developers, content developers,
contractors, etc.) to understand why accessibility is a necessary consideration and why
the you have adopted an accessibility policy?
Who needs skill development training?
How will training be provided?
For instance, will it be separate and distinct from other information technology training,
or do you want/need to consider developing and offering customized training curricula
to ensure that accessibility is considered within the general context of web development
training?
Will both strategies be necessary?
Multiple training approaches should be considered: face-to-face training, CD-based
training, and web-based training (interactive and/or one-way).
Devise methodologies, tools, and strategies to determine needs for initial and ongoing
training. For example, you may need to survey developers, consider user complaints, and
review results of any monitoring processes.

25. Adoption and Implementation
Is there an economy of scale to consider when making enterprise-wide buys of
development and testing tools, training tools, or other offerings?
Review existing authoring tools, evaluation tools, and user agents (browsers, media
players, etc.) for accessibility support.
Refer to the W3C's Selecting and Using Authoring Tools for Web Accessibility for
some guidance on considerations for authoring tools.
Do you need to consider the design and implementation of efforts to determine the
impact of the policy?
Do you need to establish a plan or timeframe to review the policy and standards to
ensure that it is consistent with other IT policy development and that it reflects the
most up-to-date web and platform development practices and tools?

26. Evaluating the Accessibility Policy
• Whether an organization is developing a new policy, or reviewing an
existing policy, it is still important to evaluate the policy to ensure that it
meets the needs of the organization and the people.
• Checking the effectiveness of the policy is key to providing equal access for
all people.
• The AccessIT project has identified the following characteristics of
information technology accessibility policies.

27. Evaluating the Policy
• What groups of people with disabilities are covered?
Effective policies cover all people with disabilities. Some policies, however, cover only people who
are blind or have low vision. While the majority of issues regarding accessibility deal with people
who are blind or who have low vision, other groups -- such as people with mobility disabilities,
people who are deaf or hard of hearing, or people with photosensitive epilepsy -- should be
considered in policy development. Additionally, more and more people with learning disabilities are
beginning to use screen readers and other pieces of assistive technology originally developed for
people who are blind -- and may encounter similar barriers. An effective policy should be as
inclusive as possible, and apply on a cross-disability basis.
• What types of technology are covered? One weakness of many policies is that the policies
incorporate only web accessibility Initiative standards. However, these "first generation" standards
do not cover the "second generation“ content frequently found -- such as PDF files, PowerPoint
presentations, and other non-HTML elements. Policies should be written to cover many different
types of information technology products and services -- not just HTML pages on websites.
Additionally, an effective policy should cover the procurement of information technology.
• Which entities are covered? Some existing policies only cover one department. Some have a policy
that covers a library system but not the curriculum. Some have policies regarding website design,
but not regarding communications tools accessibility. Having one policy for an entire organisation
helps to promote uniformity and raises expectations for access.

28. Evaluating The Policy
• How is compliance measured?
• Implementing and enforcing the policy is just as important as developing the policy in the first
place. Who is responsible for evaluating information technology? What penalties are there for
failure to comply with the policy? How are complaints and grievances handled?
• How will the policy be disseminated? How will staff know about the policy? Is it publicly posted? Is
training available?
• What if the technology changes? Will the policy continue to apply to new and emerging
technologies? Or will the policy need to be assessed periodically as assistive technology and
information technology products become more sophisticated?
• Does the policy meet the needs of all people? Might some people still experience barriers even
after the policy has been fully implemented? What procedures are in place for people to request
additional accommodations? Have people with disabilities and representative organizations been
included in the policy development process?
• Asking questions such as these helps to clarify the policy and insure that it meets the stated goal of
achieving accessibility for people with disabilities.

29. Sources
• COI - Delivering Inclusive Websites
• W3C - Developing Organizational Policies on Web
Accessibility
• MLA – Delivering your access policies and plans
• HSE – Website Accessibility Policy
• CATEA - Developing Effective Policies for Information
Technology Accessibility for people with Disabilities
• G3ICT - Introduction to developing policy
• JISC - Accessible e-Learning in Higher Education
• NDA - Universal Design guidelines and standards for ICT
• ITTATC - Access Policy & Standards Construction Tool