PUBLICLY AVAILABLE SPECIFICATION

PAS 78:2006

Guide to good practice in commissioning accessible websites

ICS 35.240.30

PAS 78:2006

This Publicly Available Specification comes into effect on 8 March 2006

© BSI 8 March 2006

ISBN0 580 46567 5

 

Amendments issued since publication
Amd. No.	Date	Comments

PAS 78:2006 © BSI 8 March 2006 i

Contents

Page

Forewordii

Introduction 1

1Scope 5

2Normative references 5

3Terms and definitions 5

4General principles 11

4.1 Development of an accessibility policy 11

4.2 Upholding W3C guidelines and specifications 11

4.2.1 General 11

4.2.2 Content formats 11

4.2.3 Authoring tools 11

4.3 Conformance checking 12

4.4 Involving disabled people in the requirements gathering and conceptual design process 12

4.5 Regular testing by disabled people 12

4.6 Additional accessibility provisions 12

5How disabled people use websites 13

5.1 General 13

5.2 Operating systems 13

5.3 Access technology and other considerations for blind and partially sighted people 14

5.4 Access technology and other considerations for deaf and hard of hearing people 15

5.5 Access technology and other considerations for people with learning disabilities 15

5.6 Access technology and other considerations for people with cognitive impairments (eg dyslexia) 16

5.7 Access technology and other considerations for people with motor impairments 16

6Defining the accessibility policy for the website 17

6.1 General 17

6.2 Content of the accessibility policy 17

6.3 Publicly available accessibility policy statement 19

6.4 Accessibility guidelines 19

PAS 78:2006 ii © BSI 8 March 2006

7Web technologies 21

7.1 Common web technologies 21

7.2 Structural languages 22

7.3 Style sheets eg CSS 22

7.4 Client side scripting and programming languages eg _javascript_ and Java 23

7.4.1 Object models 23

7.5 Plug-in rich media formats 23

7.5.1 General 23

7.5.2 Portable Document Format (PDF) 24

7.5.3 Flash 24

7.5.4 Audio-video content 25

7.6 Visual-orientated anti-robot tests 26

8Accessibility testing and maintenance 26

8.1 General 26

8.2 Creating a test plan 28

8.3 Determining technical accessibility 28

8.3.1 Automated testing 28

8.3.2 Validation 29

8.3.3 Testing with assistive technology 29

8.4 Determining usable accessibility 29

8.4.1 Expert review 30

8.4.2 Conformance inspection 30

8.4.3 User testing 31

8.4.3.1 Why is user testing necessary? 31

8.4.3.2 User testing methods 31

8.4.3.3 Budgetary considerations 32

8.4.3.3.1 Sample sizes 32

8.4.3.3.2 User recruitment 32

8.4.3.3.3 Using specialized evaluators 32

8.5 Maintaining accessibility 33

9Contracting web design and accessibility auditing services 34

9.1 Choosing a website developer 34

9.2 Agencies providing web accessibility consultancy 35

PAS 78:2006 © BSI 8 March 2006 iii

Annex A (informative) Suggested user profiles include: 36

Annex B (informative) Possible criteria for determining success 37

Annex C (informative) Suggested questions for suppliers 38

Annex D (informative) Accreditation 40

Annex E (informative) Various references 41

Annex F (informative) Contracting usability testing services 44

Annex G (informative) How to select a CMS system 45

Bibliography 47

Standards56

Useful websites56

Relevant publications57

Index50

PAS 78:2006 iv © BSI 8 March 2006

Foreword

This Publicly Available Specification (PAS) has been developed by the Disability Rights Commission (DRC) in collaboration with the British Standards Institution (BSI). No copying without permission of BSI except as permitted by copyright law.

Acknowledgement is given to the following organizations that were consulted in the development of this specification.

Abilitynet

British Broadcasting Corporation (BBC)

Cabinet Office (e-Government Unit)

Cxpartners (representing the Usability Professionals Association)

IBM

RNIB (Royal National Institute of the Blind)

Tesco.com

University College London

Usability Professionals Association (UPA)

Wider comments from other interested parties were invited by BSI. The expert contributions made by the organizations and individuals consulted in the development of this Publicly Available Specification are gratefully acknowledged.

Please note that during the production of this PAS Macromedia was bought by Adobe and all resources regarding Flash accessibility will eventually be available at access.adobe.com.

This Publicly Available Specification does not replace, contradict or supplement any of the World Wide Web Consortium (W3C) guidelines or specifications. This PAS is vendor neutral and product neutral. Generic terms are used in preference to brand names to ensure impartiality.

PAS 78:2006 © BSI 8 March 2006 v

Summary of pages

This document comprises a front cover, an inside front cover, pages i to v, a blank page, pages 1 to 56, an inside back cover and a back cover.

The BSI copyright notice displayed in this document indicates when the document was last issued.

This Publicly Available Specification does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.

This Publicly Available Specification has been prepared and published by BSI, which retains its ownership and copyright. BSI reserves the right to withdraw or amend this Publicly Available Specification on receipt of authoritative advice that it is appropriate to do so. This Publicly Available Specification will be reviewed at intervals not exceeding two years, and any amendments arising from the review will be published as an amended Publicly Available Specification and publicised in Update Standards.

Compliance with this Publicly Available Specification does not of itself confer immunity from legal obligations.

This Publicly Available Specification is not to be regarded as a British Standard.

blank PAS 78:2006 © BSI 8 March 2006 1

Introduction

Why make your website accessible to disabled people?

The introduction of the Disability Discrimination Act 1995 (DDA) [1] is only one reason why it is in the interest of website commissioners to develop accessible websites. Accessible websites also have the potential to widen a website?s current audience and reach new ones:

? The Family Resources Survey [2] found that there are almost 10 million disabled people in the UK with a combined spending power in the region of 80 billion pounds per annum. Furthermore there are millions of other individuals that are affected by sensory, physical and/or cognitive impairments, including those resulting from the ageing process.

? Research undertaken by the DRC ?The Web: Access and inclusion for disabled people? [3] has confirmed that people without disabilities are also able to use websites that are optimized for accessibility more effectively and more successfully.

? Content developed upholding World Wide Web Consortium (W3C) guidelines and specifications can be more easily transferred to other media, such as interactive TV, mobile phones and handheld computers.

? Accessible content, for example where a text equivalent is provided for graphical elements, is highly visible to search engines, often leading to higher rankings.

Ensuring accessibility can also be a source of good publicity, as social inclusion results in a fairer world with equality of opportunity. Further business benefits achieved by making websites accessible are given at http://www.w3.org/WAI/bcase/benefits.html.

The main focus of this document is the commissioning of public-facing (internet) websites but the principles can also be used by commissioners of intranet or extranet websites.

It is important to note that not all web developers will have practical accessibility design experience and/or accessibility expertise; see Clause 9 for advice on how to find suitable web developers.

PAS 78:2006 2 © BSI 8 March 2006

The Disability Discrimination Act 1995 (DDA)

The DDA and the secondary legislation applied within Northern Ireland have placed a legal duty on service providers to make reasonable adjustments to the way they provide services to ensure that disabled people can use them. The DDA states that disabled people should not be treated less favourably than other people when accessing services. This duty extends to the provision of websites where a website falls within the definition of a service under the terms of the DDA. For the purposes of this document, website commissioners are assumed to have responsibility for this duty.

It is not possible to provide a definitive specification for a fully accessible website which will satisfy the requirements of the DDA, however the guidance set out in this Publicly Available Specification represents what the Disability Rights Commission (DRC) believes to be good practice.

The Disability Rights Commission (DRC)

The DRC is an independent body established in April 2000 by an Act of Parliament to stop discrimination and promote equality of opportunity for disabled people. The DRC?s goal is ?a society where all disabled people can participate fully as equal citizens?.

In 2002, the DRC published a Code of Practice entitled ?Rights of Access ? Goods, Facilities, Services and Premises? [4] to accompany Part 3 of the DDA. The Code makes explicit reference to websites as ?services? in accordance with the DDA?s definition of the term. At the time of publication the DRC were updating the Part 3 Code of Practice.

The DRC Formal Investigation into website accessibility

In April 2004, the DRC published the report of their Formal Investigation into web accessibility in the UK. One significant finding was that 81 per cent of websites surveyed failed to uphold the most basic W3C accessibility guidelines and specifications, even though many website commissioners and developers claimed to be aware of the importance of making websites accessible.

PAS 78:2006 © BSI 8 March 2006 3

The DRC has concluded that there is a need for best practice guidance on the process of commissioning accessible websites. This Publicly Available Specification has been commissioned to provide guidance to website commissioners on:

? the steps that should be taken to commission accessible websites

? the W3C guidelines and specifications to be adopted

? the role of the guidelines and specifications, software tools and user testing within the development life cycle.

Another important finding of the Formal Investigation involved accessibility testing. All the websites surveyed were tested using automated conformance testing tools (see 3.5); however subsequent user testing with disabled participants uncovered further instances where websites did not uphold the W3C guidelines and specifications. Therefore it can be concluded that automated testing alone cannot provide a complete testing solution.

Ensuring accessibility

The web will only be truly accessible when all of the following work in harmony, using the relevant W3C guidelines and specifications:

? website developers ensure that their web content upholds W3C?s Web Content Accessibility Guidelines (WCAG) (see 3.22)

? website developers ensure that any non-W3C formats used on the website incorporate accessible design elements or follow accessible design guidelines applicable to that format

? authoring tool developers ensure that their products produce web content that upholds WCAG

? browser developers ensure that their products uphold W3C?s User Agent Accessibility Guidelines (UAAG)

? operating system (OS) developers provide accessibility features within their operating system, and work with access technology developers to ensure their products work in harmony

PAS 78:2006 4 © BSI 8 March 2006

? software developers, disability advocacy groups (such as AbilityNet, RNIB (Royal National Institute of the Blind)) and public sector organizations (such as BBC and the Government) provide advice to disabled people on how to optimize their computer setup

? educators and training organizations that provide training on web design include accessible web design in the curriculum of design courses.

The DRC recommends a combined approach to accessibility testing, including as essential requirements:

? the application of W3C guidelines and specifications (in particular WCAG)

? testing conformance to guidelines and specifications (in particular WCAG, see Clause 8)

? user testing with potential users, including disabled users (see Clause 8), during the design and development stages of the website development.

Summary for commissioning an accessible website

a) Consider what the site should do and for whom:

? write the accessibility policy/specification (see Clause 6).

b) Consider who is going to create it, and how accessibility can be assured:

? investigate the reputation of those designing and developing the site and the guidelines/processes they uphold (see Annex C).

c) Consider how the web developers are going to create and maintain the website:

? investigate whether the website will be created and maintained manually, using a CMS, or by using an automated web application (see 6.5.3)

? ensure that a plan is in place to maintain levels of accessibility during the website lifecycle (see 8.5).

d) Consider how accessibility will be tested (see Clause 8).

PAS 78:2006 © BSI 8 March 2006 5

1 Scope

This Publicly Available Specification outlines good practice in commissioning websites that are accessible to and usable by disabled people.

It gives recommendations for:

? the management of the process of, and guidance on, upholding existing W3C guidelines and specifications;

? involving disabled people in the development process and using the current software-based compliance testing tools that can assist with this.

It is applicable to all public and private organizations that wish to observe good practice under the existing voluntary guidelines and the relevant legislation on this subject and is intended for use by those responsible for commissioning public-facing websites and web-based services.

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies.

W3C guidelines and specifications available at http://www.w3.org/

3 Terms and definitions

3.1

access technology

hardware or software used to adapt or make computer systems and services accessible to a disabled person

NOTE 1 Examples include the provision of screenreaders and text-to-speech systems; screen-magnification software; tactile braille display, trackballs, touch pads/screens etc; alternatives to standard computer mice, keyboards, switches and voice-recognition software.

NOTE 2 Also referred to as assistive technology, adaptive technology.

3.2

accessibility

ability of people with disabilities to perceive, understand, navigate, and interact with websites

PAS 78:2006 6 © BSI 8 March 2006

3.3

Authoring Tool Accessibility Guidelines (ATAG)

Authoring Tool Accessibility Guidelines published by the W3C WAI

3.4

authoring tool

software that generates web content

3.5

automated conformance testing tools

software tools used, without direct human intervention, to assess whether authoring of a website upholds guidelines and specifications

3.6

Cascading Style Sheets (CSS)

languages designed to specify what document elements should look like, eg colours, borders, spacing, font style

NOTE 1 Also referred to as style sheets.

NOTE 2 Typically used to define what pages should look like eg colours, borders, spacing, font style. Aural CSS enable web authors to define how their pages should be read aloud by screenreaders that support them.

NOTE 3 Also referred to as content production system (CPS).

3.7

cognitive impairment

decline in mental functioning, ranging from mild impairment, such as lack of concentration, to extreme impairment including increased problems with distraction, exhaustion by tasks that require mental energy, or problems with handling complex information

NOTE In more extreme impairment, people may have difficulties with the sleep/wake cycle, changes in mood, or disorganized thinking and speech.

PAS 78:2006 © BSI 8 March 2006 7

3.8

content management system (CMS)

software that is used to create, modify, delete and archive content

NOTE Typically a CMS is also used as a way of publishing content to a website.

3.9

disability

<DDA> physical or mental impairment which has a substantial and long-term adverse effect on [a person?s] ability to carry out normal day-to-day activities

NOTE The above definition is that included in the 1995 DDA and is the one that would be considered by a County or Sheriff's Court judge when ruling on a case of potential disability discrimination. See also impairment (3.12).

3.10

Flash

rich media programming format that allows web developers to add animation, multimedia and interactive applications to websites

NOTE 1 Flash content (.swf files) is viewed through a user agent plug-in called the Flash Player.

NOTE 2 Flash file formats and authoring tools are proprietary.

3.11

heuristics

guidelines or rules that are used to guide the process of evaluation

3.12

impairment

physical, sensory or mental or cognitive impairment

NOTE 1 Physical impairments include motor impairments; sensory impairments affect the senses, such as sight and hearing; cognitive and mental impairments include learning disabilities and mental health problems.

NOTE 2 Some people might have a number of impairments.

NOTE 3 Impairments can differ in degree.

PAS 78:2006 8 © BSI 8 March 2006

3.13

interoperability

the ability of software and hardware on different machines from different vendors to share data

3.14

learning disabilities

cognitive impairment affecting the way someone learns, communicates or does some everyday activities

NOTE A learning disability affects someone?s intellectual and social development all their life.

3.15

mark-up

code used to structure, identify and format content on websites, eg HTML

3.16

plug-in

additional piece of software users need to download to enable them to view non-HTML content (such as PDF files, Flash or Java) in their browser

3.17

Portable Document Format (PDF)

file format for the distribution of content that retains the formatting and layout it was given at its creation and can be viewed on different computers and platforms via a specialized reader or via a browser plug-in (see 7.5)

NOTE 1 A useful feature of PDF files is that they look exactly the same for all senders and receivers of document regardless of hardware or software used.

NOTE 2 PDF files are viewed through a plug-in.

NOTE 3 PDF is a proprietary but published specification. Documentation about PDF and accessibility can be found at access.adobe.com.

PAS 78:2006 © BSI 8 March 2006 9

3.18

usability

extent to which a [website] can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

[adapted from ISO 9241-11:1988, definition 3.2]

3.19

user agent

software (including web browsers and plug-ins) that retrieves and renders internet content or services, including text, graphics, sounds, video

NOTE 1 Examples include media players (including Adobe Flash Player for Flash content) and other software that renders web content (including Adobe Acrobat Reader for PDF content).

NOTE 2 Access technology might sometimes be considered a user agent.

3.20

User Agent Accessibilty Guidelines (UAAG)

User Agent Accessibility Guidelines published by the W3C WAI

NOTE The version of UAAG in use at the time of publication is 1.0.

3.21

W3C

see also World Wide Web Consortium (3.29)

3.22

W3C/WAI guidelines

accessibility guidelines (ATAG, WCAG and UAAG) published by the W3C WAI

3.23

W3C specifications

documents published by the W3C that define and describe all aspects of how to code different types of web mark-up

PAS 78:2006 10 © BSI 8 March 2006

3.24

Web Accessibility Initiative (W3C WAI)

body of the W3C that, in coordination with organizations around the world, pursues accessibility of the web through five primary areas of work:

? technology

? guidelines

? tools

? education and outreach

? research and development.

3.25

Web Content Accessibility Guidelines (WCAG)

Web Content Accessibility Guidelines published by the W3C WAI

NOTE The version of WCAG in use at the time of publication is 1.0.

3.26

webpage template

pre-defined generic page format that is used to create web pages

3.27

website commissioner

individual or organization responsible for commissioning the creation of a website or web content

3.28

website developer

individual or organization responsible for designing and building a website or web content

3.29

World Wide Web Consortium (W3C)

international consortium of organizations that develops interoperable technologies (specifications, guidelines, software and tools) to lead the web to its full potential

PAS 78:2006 © BSI 8 March 2006 11

4 General principles

4.1 Development of an accessibility policy

Website commissioners should develop and document an accessibility policy in accordance with Clause 6.

4.2 Upholding W3C guidelines and specifications

4.2.1 General

The website should uphold WAI guidelines and referenced W3C specifications to ensure interoperability and accessibility to disabled people.

4.2.2 Content formats

4.2.2.1 Web commissioners should give careful consideration to the proposed formats used to design and deliver web content eg PDF (see 7.5.2), _javascript_/ECMAScript (see 7.4) or Flash (see 7.5.3).

4.2.2.2 Content formats that are not covered by WCAG eg PDF and Flash should only be used if it is determined that these are the most appropriate formats for content delivery in each case (for example if they enhance understanding and functionality for a group of users at whom the material is primarily aimed) and used in accordance with available authoring tool guidance.

4.2.2.3 When non-compliant content is provided, or content that is only available in certain modalities, accessible and equivalent alternatives should be provided.

4.2.2.4 Common Office file types such as word processing and spreadsheet documents should be authored in accordance with the accessible authoring techniques available for these formats.

4.2.3 Authoring tools

4.2.3.1 Website commissioners should ensure that authoring tools that uphold ATAG (see 6.4.3) are used for the creation of web content wherever possible.

4.2.3.2 In the choice and procurement of tools the commissioners should require suppliers to list any deviations from ATAG.

NOTE At the time of publication, no single authoring tool that supports all ATAG Priority 1 checkpoints is known.

PAS 78:2006 12 © BSI 8 March 2006

4.3 Conformance checking

4.3.1 Website commissioners should not rely solely on automated conformance testing tools to assess conformance with the relevant W3C guidelines and specifications (see Clause 8).

4.3.2 Automated tools may be used as part of the validation process, but additional manual checks and user testing with disabled people are essential to be confident that the website is accessible to disabled people.

4.3.3 Where content on the website is being supplied by a third party the website commissioner should ensure that this content has also been included in all conformance testing.

4.4 Involving disabled people in the requirements gathering and conceptual design process

Website commissioners should ensure that requirements are gathered from disabled people at the earliest stage and that the methods chosen accurately capture these users? particular requirements. You should seek expert help to facilitate this.

NOTE The best method for gathering these requirements will depend on a number of factors, including how easy it is to recruit and elicit useful data from people with different disability profiles (see Clause 8).

4.5 Regular testing by disabled people

Website commissioners should conduct user testing with disabled participants to ensure that their websites are accessible and usable by disabled people (see Clause 8).

4.6 Additional accessibility provisions

Additional accessibility provisions are not essential and should never replace upholding W3C guidelines and specifications.

NOTE 1 It is more appropriate for website commissioners and developers to view these as a supplementary enhancement that users might choose to employ if a website upholds W3C guidelines and specifications.

NOTE 2 Additional accessibility provisions can be useful where the anticipated users of the website are prohibited from using the accessibility feature in their browser?s operating systems due to local administration policies.

PAS 78:2006 © BSI 8 March 2006 13

5 How disabled people use websites

5.1 General

5.1.1 A range of access technologies have been developed that enable disabled people to use computers and access websites.

5.1.2 It is not necessary for website developers to be experts in the use of the vast range of technologies and techniques deployed by disabled people to access and use websites. General consideration should be given to the fact that disabled people might rely upon a range of alternative input and output devices on a website that is authored in conformance with W3C guidelines and specifications.

5.1.3 Web commissioners should ensure that the website upholds the W3C guidelines and specifications. Web commissioners may consider providing additional accessibility versions eg low graphics versions and easy-to-read versions that further help disabled users who do not have sufficient access technologies to help them access the website.

NOTE 1 It is the responsibility of the disabled user or their purchasing agent (eg an employer) to ensure that access technology and techniques purchased and deployed uphold W3C (UAAG) guidelines and specifications.

NOTE 2 W3C WAI has published a collection of pointers to information and, where possible, demonstration versions of alternative browsing methods. The document is called ?Alternative web browsing? [http://www.w3.org/WAI/References/Browsing/].

NOTE 3 Attention is drawn to the W3C draft document ?How People with Disabilities Use the Web? found at http://www.w3.org/WAI/EO/Drafts/pwd-Use-web.

5.2 Operating systems

5.2.1 Most disabled people experience mild to moderate impairments and do not require specific access technology to access websites. Many benefit from features within their operating system that enable them to alter screen colours and text sizes, control the size of the mouse pointer, control the flash rate of the cursor, etc.

PAS 78:2006 14 © BSI 8 March 2006

5.2.2 The BBC, along with disability and technology charity Abilitynet, has published a website to inform disabled people of changes they can make to their operating system to optimize accessibility: [http://www.bbc.co.uk/accessibility].

NOTE 1 Microsoft publishes detailed information on changes that can be made to the Windows operating system: [http://www.microsoft.com/enable/].

NOTE 2 Apple publishes detailed information on changes that can be made to the Mac operating system: [http://www.apple.com/accessibility/].

NOTE 3 Detailed information on changes that can be made to Linux can be found at: [http://lars.atrc.utoronto.ca/] [http://accessibility.kde.org/] [http://developer.gnome.org/projects/gap/].

5.3 Access technology and other considerations for blind and partially sighted people

Blind and partially sighted people might use any of a number of different techniques to help them access websites:

a) Screenreader software reads web mark-up and translates it into audible, synthetic speech accessible via computer speakers or a headset. Screenreaders can also be used to translate web mark-up into output for braille display hardware.

b) Partially sighted people might use screen magnification software to magnify their view of the whole web page, or use facilities in the browser or operating system to magnify the size of the text or override the foreground and background colours on web pages with ones which help them read the text.

c) People who have some form of colour-blindness will benefit from website designers ensuring that all information which is conveyed using colour on web pages is available without colour, for example from context or mark-up. A useful technique in testing this is to view your pages in black and white, and check if all of the information is still conveyed. These people may also override the foreground and background colours on web pages with ones which better allow them to read the text.

PAS 78:2006 © BSI 8 March 2006 15

5.4 Access technology and other considerations for deaf and hard of hearing people

5.4.1 There are two types of deaf people within the deaf community:

a) Deaf people for whom English is not their first language. These people benefit from clear and appropriate language or the provision of material in British Sign Language.

b) Deaf and hard of hearing people for whom English is their first language who will benefit from captioning of any audio materials.

5.4.2 Signing avatars (computer animations) are currently being developed to allow the creation and delivery of sign language content on the web. Avatars can be used for other purposes, including virtual personalities to which the user might relate in a more natural way, and lip speaking avatars.

NOTE 1 Deaf Connexions has a prototype signing avatar, developed in conjunction with RNID, available for download: [http://www.deafconnexions.org.uk/].

NOTE 2 Deaf and hard of hearing people do benefit from the use of textphone, instant messaging and email customer services.

5.5 Access technology and other considerations for people with learning disabilities

5.5.1 People with learning disabilities benefit from the ability to increase text size, use of clear and appropriate language and images, and clear and consistent design in navigation on websites.

5.5.2 There is specific text to speech software and symbolizing software designed to help people with certain learning disabilities or cognitive impairment.

PAS 78:2006 16 © BSI 8 March 2006

5.6 Access technology and other considerations for people with cognitive impairments (eg dyslexia)

The cognitive disability audience is diverse and includes individuals who have a learning disability. Such disabilities affect the way a person learns and communicates. ?easy-to-read? has no precise definition and no clear specification but it is a generic term for accessible methods of communicating with people with learning disabilities. There are differing views on what this means for websites, including whether ?easy-to-read? should be a separate channel. The basic features are:

? use of simple, concise content

? a sensory focus considering use of colour, use of typefaces, use of larger type, avoiding the use of capital letters

? the use of ?speech enablement? or specifically available sound files

? simple layout and use of images / illustrations or symbols to support the text

? clear links to home page and contact details.

NOTE 1 Mencap has published ?Am I making myself clear ? Mencap?s guidelines for accessible writing?: [http://www.mencap.org.uk/download/making_myself_clear.pdf].

NOTE 2 Attention is also drawn to ?Guide to making your website more accessible?: [http://www.mencap.org.uk/html/accessibility/accessibility_guides.htm#2].

5.7 Access technology and other considerations for people with motor impairments

People with motor impairments might use alternative input and output devices to read web content including but not limited to:

? alternatives to the standard computer mouse

? pointing devices to input via the keyboard

? voice recognition software.

NOTE Further details: [http://www.bbc.co.uk/accessibility/].

PAS 78:2006 © BSI 8 March 2006 17

6 Defining the accessibility policy for the website

6.1 General

6.1.1 The website commissioner should ensure that an accessibility policy is in place for the website and this policy should be prominently displayed on the website.

NOTE The accessibility policy for each website can be adapted from an existing organizational policy.

6.1.2 The accessibility policy should outline the accessibility targets that will be set and any measures that will be taken to broaden access (see 6.2).

6.1.3 The accessibility policy should be referenced in tender and contract documents and contain requirements for contractors undertaking the development and maintenance of the website.

6.1.4 All contractors should be asked specifically to commit to helping the organization meet its accessibility policy and this should be reflected in all contracts.

6.1.5 There should be a summary of the accessibility policy available on the website (see 6.3).

6.2 Content of the accessibility policy

6.2.1 Website commissioners should include a declaration of accessibility on the website.

6.2.2 The declaration should avoid jargon and be written in clear and appropriate language so that people understand its implications.

6.2.3 The declaration should reference the W3C guidelines and specifications that the website upholds.

NOTE Where self-awarded logos are used, these should only be displayed when the website conforms to the standards indicated and conformance should be checked on a continuous basis.

PAS 78:2006 18 © BSI 8 March 2006

6.2.4 The content of the accessibility policy should include the following:

a) A description of the disabled users to be consulted during the development of the website (see Annex A for user profiles).

b) An explanation of the core tasks users should be able to achieve on the site eg buy a book and the criteria for determining success (see Annex B).

c) A description of the process to be used for developing and maintaining content to meet the needs of these users, including:

1) identifying user needs

2) developing the website to meet those needs

3) measuring the performance of the website in meeting those needs.

d) Details of the accessibility level to be upheld (eg ?conformance to W3C WAI WCAG 1.0 Level AA?).

e) If an area or element of the website is unlikely to be accessible to people with particular impairments, an explanation should be provided of:

1) any repairs to be made to improve accessibility, along with a reasonable estimate of when the repairs will be made,

2) how disabled people can access this information or these services via alternative means.

f) If neither e) 1) or e) 2) are possible, an explanation of why it is considered reasonable for the area to remain inaccessible.

NOTE Attention is drawn to the DRC?s ?Code of Practice ? Rights of Access, Goods, Facilities, Services and Premises?.

g) Contact details (eg email, postal, telephone, textphone and typetalk) for requesting further information about the accessibility policy.

NOTE Advice on the provision of textphone facilities is provided by RNID (Royal National Institute for Deaf People).

h) Provision for users to lodge suggestions, comments and complaints with the website commissioner.

PAS 78:2006 © BSI 8 March 2006 19

6.3 Publicly available accessibility policy statement

6.3.1 A summary of the accessibility policy should be made available on the website. This summary should include information on how to access details of optimizing the website user experience, eg how to change the screen colours and text sizes followed by an outline of the information covered in 5.3.

NOTE Details of how to optimize the user experience of websites can be found at http://www.bbc.co.uk/accessibility. Website commissioners may consider linking to this site.

6.3.2 This summary should also provide contact details (eg email, postal, telephone, textphone and typetalk) for requesting further information about the accessibility policy and provision for users to lodge suggestions, comments and complaints with the website commissioner.

6.4 Accessibility guidelines

6.4.1 General

W3C WAI publishes three sets of guidelines which, when applied in combination, increase the likelihood of sites being accessible for disabled people.

Web Content Accessibility Guidelines (WCAG): [http://www.w3.org/TR/WCAG]

Authoring Tool Accessibility Guidelines (ATAG): [http://www.w3.org/TR/ATAG]

User Agent Accessibility Guidelines (UAAG): [http://www.w3.org/TR/UAAG]

6.4.2 Web Content Accessibility Guidelines (WCAG)

6.4.2.1 WCAG are the most important accessibility guidelines for web commissioners to be aware of, as they are considered to be the de facto standard for accessible web design.

6.4.2.2 WCAG comprises a set of checkpoints ranked into three conformance levels, with priorities 1, 2 or 3, according to W3C WAI?s view of their relative importance in enabling web access. Conformance with all the checkpoints in a conformance level (and those above it) qualifies a site for the designation Conformance Level A, AA or AAA.

PAS 78:2006 20 © BSI 8 March 2006

6.4.2.3 Commissioners should specify the WCAG Conformance Level in their accessibility policy (see Clause 6).

NOTE W3C WAI has published resources to assist website developers in the application of WCAG. These include:

a) Checklist of checkpoints for WCAG 1.0 [http://www.w3.org/TR/WCAG10/full-checklist.html]

b) Techniques for WCAG 1.0 [http://www.w3.org/TR/WCAG10-TECHS/]

c) Web content accessibility guidelines [http://www.w3.org/WAI/intro/wcag.php]

d) Additional resources [http://www.w3.org/WAI/Resources/]

6.4.3 Authoring Tool Accessibility Guidelines (ATAG)

6.4.3.1 ATAG are the guidelines for authoring tool developers.

6.4.3.2 Website commissioners using an authoring tool or CMS to develop their website should strive to use one that upholds ATAG.

6.4.3.3 Website commissioners commissioning an authoring tool or CMS to create or maintain their site should ensure that it upholds ATAG, so that its output is accessible.

NOTE 1 W3C WAI has published a set of companion techniques to help software developers implement ATAG in their products: [http://www.w3.org/TR/ATAG10-TECHS/].

NOTE 2 W3C WAI has published a document to assist website developers in procuring authoring tools that uphold ATAG: ?Selecting and using authoring tools for web accessibility? [http://www.w3.org/WAI/impl/software.html].

NOTE 3 W3C WAI has published ?Authoring Tool Accessibility Guidelines Overview? [http://www.w3.org/WAI/intro/atag.php].

6.4.4 User Agent Accessibility Guidelines (UAAG)

6.4.4.1 UAAG are the guidelines for user agent developers.

PAS 78:2006 © BSI 8 March 2006 21

6.4.4.2 Website commissioners should aim to develop websites that are usable and accessible on a reasonable range of web browsers and operating systems. For examples of current browsers please see [http//:www.bbc.co.uk/guidelines/newmedia/technical/browser_support.shtml].

6.4.4.3 Website commissioners should ensure that web developers are aware of UAAG. Web developers should promote the use of UAAG by designing web content that upholds W3C guidelines and specifications, so that browsers that uphold the UAAG guidelines will provide an accessible experience.

6.4.4.4 User-agent (or functionality) detection scripts and work arounds will be necessary so that a similar experience is provided for users of popular browsers that do not uphold W3C guidelines and specifications.

NOTE 1 It is not the responsibility of the website commissioner to ensure that the browser used upholds W3C guidelines and specifications, including UAAG.

NOTE 2 It is the responsibility of user agent developers to comply with UAAG.

NOTE 3 Browsers that do not uphold W3C guidelines and specifications might not interpret standards-compliant mark-up correctly.

NOTE 4 W3C WAI has published ?User Agent Accessibility Guidelines Overview? [http://www.w3.org/WAI/intro/uaag.php].

7 Web technologies

7.1 Common web technologies

7.1.1 All relevant W3C guidelines and specifications should be used (see 6.4).

7.1.2 Content should be separated from presentational attributes.

NOTE This allows users to view the same content in different presentational styles, eg one website could be viewed using a number of CSS, one of which is designed for users with low vision.

7.1.3 Content should be coded using structural languages (see 7.2).

7.1.4 Presentational attributes should be coded using style sheets (see 7.3).

7.1.5 Any website that relies on scripting languages such as _javascript_ should be tested thoroughly.

PAS 78:2006 22 © BSI 8 March 2006

7.1.6 Event driven behaviours should be coded using DOM (see 7.4.1).

7.2 Structural languages

These are languages designed to specify the structure of a document and its contents. It is recommended that the full semantics of the language is used in the coding of web pages. The W3C-recommended (current) specifications include:

Hypertext Mark-up Language (HTML) 4.01 [http://www.w3.org/TR/html4/]

NOTE This is generally used as a development format.

Extensible Hypertext Mark-up Language (XHTML) 1.0 [http://www.w3.org/TR/xhtml11/]

NOTE This can be used as the format for mobile phone browsers.

Extensible Mark-up Language (XML) 1.0 [http://www.w3.org/TR/REC-xml/]

NOTE This is generally used for structuring data.

Scalable Vector Graphics (SVG) 1.1 [http://www.w3.org/TR/SVG11/]

NOTE This is generally used for graphics and maps (Flash can also be used for these purposes).

Mathematical Mark-up Language (MathML) 2.0 [http://www.w3.org/TR/MathML2]

NOTE Generally used for mathematical equations.

7.3 Style sheets eg CSS

7.3.1 Using CSS allows presentation attributes (eg colours, borders, spacing, font style, etc) to be coded.

7.3.2 The W3C-recommended (current) specification for CSS is Level 2, which offers the ability to layout page designs without using html tables [http://www.w3.org/TR/REC-CSS2].

7.3.3 Style sheets are also implemented as XSL.

NOTE Browser support issues may arise as a result of using CSS Level 2.

PAS 78:2006 © BSI 8 March 2006 23

7.4 Client side scripting and programming languages eg _javascript_ and Java

These are languages used to create scripts, or sets of instructions, that can control various elements of a web document, such as the user interface, styles, and HTML mark-up. The core language of this type is _javascript_, referred to as ECMAScript by the ECMA Standards Organization:

ECMAScript-262 (third edition) [http://www.ecma-international.org/publications/standards/Ecma-262.htm]

NOTE 1 Due to accessibility issues with client-side scripting languages such as _javascript_ it is worth investigating whether the same functionality can be provided using server-side scripting languages such as ASP or PHP.

NOTE 2 _javascript_ is not considered a W3C technology.

7.4.1 Object models

These are platform and language-neutral interfaces that specify how the content, structure, and appearance of a document can be updated with scripts or other programs. They provide a standard set of objects for representing HTML and XML documents, a standard model of how these objects can be combined, and a standard interface for accessing and manipulating them. The W3C-recommended (current) specifications are:

Document Object Model (DOM) Level 1 (core) [http://www.w3.org/TR/REC-DOM-Level-1]

DOM Level 2 (core) [http://www.w3.org/TR/REC-DOM-Level-2-Core]

7.5 Plug-in rich media formats

7.5.1 General

7.5.1.1 There are a number of rich media formats, in addition to plain HTML pages, that website developers may use.

7.5.1.2 The user might require additional user agents (plug-ins) in order to play content in these formats. In this case, website commissioners should ensure website developers provide access to information in clear and appropriate language that explains why additional user agents (plug-ins) are required to read content, how to download and install them, and how to operate them.

PAS 78:2006 24 © BSI 8 March 2006

7.5.1.3 When new technologies or versions are proposed web commissioners should consider waiting until those technologies are supported by updates in assisted technologies before implementing those technologies on their websites.

NOTE This information is available at BBC Webwise ?Plug-in information sheets? [http://www.bbc.co.uk/webwise].

7.5.2 Portable Document Format (PDF)

7.5.2.1 As PDF is not a W3C technology, technically its use does not uphold WCAG (at the time of publication); however Adobe has stated its intention that future versions of PDF and its user agent (plug-ins) will be designed in accordance with the principles of WCAG.

7.5.2.2 PDF accessibility relies on the Tagged PDF specification, which only became available with Acrobat 5 and can be found in the PDF Reference Manual, available at:

[http://partners.adobe.com/public/developer/pdf/index_reference.html]

NOTE 1 Website developers using PDF authoring tools that do not conform to Adobe?s accessibility guidelines may use Acrobat to make the content of the PDF accessible retrospectively. This applies to legacy PDF content generally.

NOTE 2 At the time of publication, Adobe stated its intention that future versions of PDF will uphold the forthcoming WCAG 2.0, which is anticipated to be format-neutral. Further information and guidelines on accessible PDF content authoring are available at [http://www.adobe.com/accessibility].

NOTE 3 A working group in which Adobe and other organizations participate under the sponsorship of AIIM (Association for Information and Image Management) is developing a standard for authoring accessible PDF content entitled ?PDF/UA?. At the time of publication, this document was in draft format only.

7.5.3 Flash

7.5.3.1 From version 6 Flash Player and the authoring tool (Adobe Flash MX), functionality for creating more accessible content was included.

PAS 78:2006 © BSI 8 March 2006 25

7.5.3.2 Website commissioners should ensure that developers consider the accessibility of any Flash content and use the Flash authoring tool in combination with the supporting content and techniques documents provided by Adobe.

7.5.3.3 Website commissioners should ensure Flash content is specifically tested for accessibility.

NOTE The Adobe Accessibility resource centre includes detailed information on accessibility standards, authoring techniques, tutorials and examples: [http://www.macromedia.com/macromedia/accessibility/].

7.5.4 Audio-video content

7.5.4.1 Website commissioners should ensure that developers consider the accessibility of any audio or video content on the website. This is usually achieved using captions or subtitles and audio descriptions of the visual track.

NOTE Audio description is an additional narration that describes all significant visual information such as body language, facial _expression_, scenery, action, costumes ? anything that is important to conveying the plot of the story, event or image. For more information see http://www.rnib.org.uk/audiodescription.

7.5.4.2 Including transcripts should also be considered.

7.5.4.3 Website developers should strive to uphold WCAG 1.0 guidelines in providing these alternatives in synchronization with the presentation.

NOTE 1 Captioning software exists to produce captions (subtitles) for most audio-visual formats, eg CPB/WGBH?s free MAGpie software: [http://ncam.wgbh.org/webaccess/magpie/].

NOTE 2 There is varying support for accessibility amongst media player formats.

PAS 78:2006 26 © BSI 8 March 2006

7.6 Visual-orientated anti-robot tests

Website commissioners should ensure that security measures for websites do not make it impossible for disabled people, in particular blind and partially sighted people, to use the site. For example, if registration or sign-on to an online service requires the use of sight to view and entering a passcode (this method is known as ?Turing test? or ?Captcha?) it should be noted that a person with impaired sight including a screenreader user will require an alternative method of accessing the service that does not rely on human sight.

NOTE For more information on options available to increase web accessibility in this area see http://www.w3.org/TR/2003/WD-turingtest-20031105/.

8 Accessibility testing and maintenance

8.1 General

8.1.1 Measurable success criteria should be created from the website?s accessibility policy (see Clause 6), such as:

? conformance criteria, eg all pages must conform to WCAG ?AA?

? assistive technology support, eg Screen readers, voice input technologies etc

? assessment criteria, eg task success rates or user satisfaction for disabled people.

8.1.2 All organizations, regardless of size, should ensure that those testing the website are different from those developing it.

8.1.3 Website commissioners should develop a test plan (see 8.2) and ensure that all testing is documented and reported upon.

8.1.4 Website commissioners should allocate time and resources within the development plan for any necessary rework to be undertaken.

8.1.5 How and when the website is tested for accessibility should be documented as part of the overall quality plan.

PAS 78:2006 © BSI 8 March 2006 27

8.1.6 Website commissioners should test for accessibility compliance throughout the website?s design lifecycle. The earlier accessibility problems are found, the easier and cheaper they are to fix. The key stages for testing are:

? Requirements: Learn what elements work and identify areas for improvement by running accessibility validations, user evaluations or expert reviews of your existing site or competitor sites.

? Design: Evaluate early designs with users using technically accessible prototypes; expert reviews of early designs can be conducted to identify potential problems.

NOTE Evaluating webpage templates before building the site is a much more effective way of ensuring that WCAG is being upheld.

? Build: Validate code against W3C guidelines and specifications and check using assistive technologies; identify usability issues with user tests; predict usability and accessibility problems with expert reviews.

? Maintenance: New pages and changes to existing pages should be tested for accessibility. Small changes, such as adding a new graphic, or writing a new paragraph should, as a minimum, be tested for conformance to WCAG ?AA?. Large changes that affect important tasks within the interface, ie how a user logs onto a site or buys a product, should undergo user testing.

8.1.7 Comprehensive evaluation of web site accessibility should involve a combination of conformance with the technical requirements of WCAG, and user testing of accessibility features.

NOTE 1 W3C WAI has published a document that describes approaches for preliminary review of website accessibility and conformance evaluations, including general procedures and tips for evaluation during website development and for the ongoing monitoring of established websites: ?Evaluating websites for accessibility? [http://www.w3.org/WAI/eval/]. This document was in the process of being updated at the time of publication.

NOTE 2 W3C WAI has published information about evaluation, repair, and transformation tools useful for website developers: ?Evaluation, Repair, and Transformation Tools for Web Content Accessibility? [http://www.w3.org/WAI/ER/existingtools.html].

PAS 78:2006 28 © BSI 8 March 2006

8.2 Creating a test plan

8.2.1 Website commissioners should develop an accessibility test plan that enables the accessibility targets to be achieved and performance measured, eg to achieve the usability success criteria, early user evaluations may be needed to identify any design issues.

8.2.2 The accessibility test plan should clearly state:

? which accessibility testing methods will be used

? how the method supports the accessibility targets

? when during the project lifecycle the tests will take place

? how the test results will be documented

? how the test results should be interpreted.

8.3 Determining technical accessibility

Approaches for determining technical accessibility include:

? Automated testing to determine whether the website upholds W3C guidelines and specifications.

? Validation testing of code to determine whether it upholds W3C guidelines and specifications; tools include validators for html and style sheets (see 8.3).

? Assistive technology tool testing to determine whether the website can be accessed using the tools commonly used by disabled users (see 8.3.3).

8.3.1 Automated testing

Website commissioners should ensure that website developers are aware of the capabilities and limitations of commercially available automated testing tools.

NOTE Although these tools check for a relatively small proportion of the WCAG guidelines, they can be useful for analysing a whole site for technical accessibility.

PAS 78:2006 © BSI 8 March 2006 29

8.3.2 Validation

Website commissioners should ensure that website developers begin the evaluation and repair process by validating their mark-up against W3C guidelines and specifications.

W3C?s Mark-up Validation Service should be used [http://validator.w3.org/].

W3C CSS Validation Service should be used to evaluate the validity of any CSS [http://jigsaw.w3.org/css-validator/].

8.3.3 Testing with assistive technology

8.3.3.1 Testing with assistive technology checks whether a range of assistive technologies can read and interact with web content and activate any controls.

8.3.3.2 If a website conforms to WCAG, assistive technologies should work with the site. Although it is not the responsibility of the website commissioners to change their code to make an assistive technology work correctly they may wish to provide work arounds if they exist.

8.3.3.3 Assistive technology tool tests can provide a relatively quick way for a tester with specialist knowledge of the tools to assess the website?s technical accessibility. However, these tests do not assess the usability of the interface; if a technical accessibility problem is found, it may not be obvious where the problem lies. In this case, a conformance inspection is the only way of testing compliance (see 8.4.2).

NOTE There are assistive technology resources available for all budgets from free software available on the web through to professional consultants.

8.4 Determining usable accessibility

Approaches for determining usable accessibility include:

? Expert reviews, involving specialists in usability and accessibility, to evaluate the website in order to find potential problems (see 8.4.1).

? Conformance inspections to determine the WCAG conformance level for the website or check that it meets a specified WCAG conformance level (see 8.4.2).

? User testing to identify any usability and accessibility problems they may have (see 8.4.3).

PAS 78:2006 30 © BSI 8 March 2006

8.4.1 Expert review

8.4.1.1 Reviews can be conducted on early designs and finished code and can be relatively quick and inexpensive. They are useful for identifying quality and consistency issues not typically identified during user testing. However, they do not find the same type or number of problems as user testing; they can identify problems that real users would not experience; and the quality of the findings is directly related to the skill and experience of the experts.

8.4.1.2 There are a number of different types of structured review processes, including heuristic evaluation, where an interface is inspected against a set of heuristics or guidelines, and a cognitive walk-through, where evaluators step through a series of actions with a goal of completing a typical user task. Experts can use assistive technology in their evaluation.

NOTE Specialist training is required in the use of assistive technologies to make sure they are using the technologies in the appropriate way as a disabled person would.

8.4.2 Conformance inspection

8.4.2.1 Conformance inspection is a systematic manual review of each webpage against WCAG guidelines as specified, which typically follows a validation test and involves reviewing each piece of content and control.

8.4.2.2 Conformance inspections provide a single method for determining whether a website upholds WCAG. However, they are time consuming and require an expert in accessibility, usability and website code due to individual interpretations of WCAG.

8.4.2.3 Due to the amount of effort that is required to inspect a page to a specified WCAG level, web commissioners could consider an approach that involves inspecting a sample number of pages on the site. This sample should include pages with high usage or involve critical functions such as form filling.

PAS 78:2006 © BSI 8 March 2006 31

8.4.3 User testing

8.4.3.1 Why is user testing necessary?

User testing involves recruiting a set of representative users and asking them to attempt to use the website to achieve a set of representative tasks. It provides the best evidence of the website?s accessibility as:

? people are unpredictable: how disabled users interact with a website is often different from the assumptions of website developers; user testing often uncovers unexpected requirements

? people are adaptable: designs that appear problematic may be usable in reality

? website developers become familiar with the features of their design solutions and frequently fail to notice problems that disabled users will experience

? website developers have different and sometimes conflicting goals to users, often user testing evidence is needed to qualify the relative merit of different design approaches

? website developers have computing skills, but may have limited knowledge of alternative computing environments; user testing provides real and often new insight into how different types of users access the web

? business objectives can sometimes conflict with the accessibility of the website eg third party delivered content such as advertising.

8.4.3.2 User testing methods

8.4.3.2.1 User testing should include users from a range of disabilities and preferences, including a mix of beginners and experienced web users using a range of assistive technologies.

8.4.3.2.2 Website commissioners should include user testing in any procurement and tender documentation and ensure that all user testing conforms to BS EN ISO 13407:1999, Human-centred design processes for interactive systems.

8.4.3.2.3 The expense of conducting user testing can mean that budgetary considerations only allow a very small sample; this can provide erroneous results which should be treated with due caution.

PAS 78:2006 32 © BSI 8 March 2006

8.4.3.2.4 A number of ethical and practical issues should be taken into account before embarking on user testing with disabled people.

NOTE Both the Usability Professionals Association (UPA) (see http://www.upassoc.org/) and Market Research Society (see http://www.mrs.org.uk/standards/guidelines.htm) have Codes of Conduct covering how consultants and researchers should conduct themselves.

8.4.3.3 Budgetary considerations

8.4.3.3.1 Sample sizes

If more than one user experiences the same problem during testing, this provides stronger evidence that the problem will affect a significant number of users. Consideration should be given to the expense of larger sample sizes versus confidence in the results.

8.4.3.3.2 User recruitment

Website commissioners may contract a recruitment agency to recruit users who exactly match the required criteria. This ensures the right user profiles are met and the randomness of the selection process provides added confidence in the results; however this service can be expensive and time consuming and will need to be repeated for each round of testing.

Website commissioners may convene a regular panel of users. This is less expensive and quicker to set up. However, these users will eventually develop expertise in using websites in general, and how the website to be tested works, making them less likely to experience the same usability problems as novice users.

8.4.3.3.3 Using specialized evaluators

There are many specialized usability groups with trained evaluators who can run user tests following this rigorous method. This ensures confidence that the recommendations have been based on data derived from a proven method and trained observers can not only identify usability problems, but explain why users are having difficulties. However, such evaluations can be expensive and take time to set up.

PAS 78:2006 © BSI 8 March 2006 33

A less expensive alternative is for an internal evaluator, who has not been involved in the design or development of the website, to sit beside selected users as they attempt to use it. The evaluator should not simply show a website to users and ask them what they think of it. They should ask users to perform given tasks to complete. They should observe whether they have any difficulties such as navigational issues, use of site search or system ambiguity.

Although focus groups are less expensive to run and easier to set up, they are inappropriate to use to identify usability errors. If they are used, the results will be less reliable because an untrained evaluator might not realize the underlying user problems, might attach more significance to a problem than there really is or allow personal opinions to get mixed into the results. It is also difficult to ensure that users feel at ease and confident to talk about the problems they are having with the interface. An untrained evaluator may inadvertently prevent the users from communicating problems they are experiencing.

8.5 Maintaining accessibility

8.5.1 Website commissioners should ensure a regular programme of accessibility testing after the website launch to maintain the desired level of accessibility, which should include:

? Benchmarking the site against the accessibility policy by running user evaluation or conformance inspections to identify accessibility problems

? Running tests using assistive technology with new tools or new versions of tools

? Testing the accessibility of new and changed pages

? Enabling feedback to be provided by all users.

8.5.2 Web commissioners should ensure awareness of any new specifications, devices, technologies, user behaviour and expectations that would change accessibility requirements.

PAS 78:2006 34 © BSI 8 March 2006

9 Contracting web design and accessibility auditing services

9.1 Choosing a website developer

9.1.1 It is not possible to provide a definitive specification for a fully accessible website which will satisfy the requirements of the DDA. Website commissioners should therefore be sceptical if contracting companies declare that they will create websites that are ?DDA-compliant? or ?compliant with the law?. Conversely, website commissioners should not require a web designer to design a website that is ?DDA-compliant? or ?compliant with the law?. Until case law has been established such claims cannot be made or honoured.

9.1.2 There is currently no nationally recognized system of accreditation (see Annex D) for website developers who claim to create accessible websites that uphold W3C guidelines and specifications. Website commissioners should therefore perform their own reference checks until they are satisfied that the website development contractor has competence and experience in developing accessible websites that uphold W3C guidelines and specifications (seeAnnex C).

9.1.3 Checks should include:

? a review of previous work

? references from previous clients

? a practical knowledge of PAS 78

? a practical knowledge of W3C guidelines and specifications

? an appreciation of the implications of ?The Disability Discrimination Code of Practice (Goods, Facilities, Services and Premises)? 2002 edition(see http://www.drc-gb.org/uploadedfiles/documents/2008223drccoprightsofAccess.doc)

? familiarity with assistive technologies.

PAS 78:2006 © BSI 8 March 2006 35

9.2 Agencies providing web accessibility consultancy

There is currently no accreditation board for web accessibility consultancy services in the UK and no harmony between web accessibility consultants (with the exception of members of EA).

Website commissioners should refer to the guidance in 9.1 when commissioning accessibility consultants.

PAS 78:2006 36 © BSI 8 March 2006

Annex A (informative)Suggested user profiles include:

A.1 Vision impairment

Users with severe vision impairment, eg users of screen reader software.

Users with medium vision impairment, eg users of magnification software.

Users with mild vision impairment, eg users who might enlarge text in the browser with high contrast and use Windows' colour preferences.

NOTE Because there are three main types of colour blindness it is unlikely that all problems would arise in user testing.

A.2 Mobility

Users with severe motor difficulties, eg users with Motor Neurone disease who might use switch access and an on-screen keyboard to interact with a computer.

Users with severe motor difficulties, eg users who are quadriplegic who might use voice recognition software.

Users with medium motor difficulties or upper limb disorder, eg users who might only use a keyboard, a mouse being too difficult to use.

Users with mild motor difficulties, eg users who might use a mouse or equivalent adaptive technology but who might have fine mouse control difficulties.

A.3 Cognitive and learning

Users with medium dyslexia, eg users who might change site colours and text formatting, and who in many cases might supplement this with text to speech software for reading sections of text (such as TextHelp).

Users with mild to medium learning or cognitive disabilities, eg users who might use a symbol browser to convert web pages to symbols or have no special access methodologies and rely on someone else assisting them.

NOTE Not all people with a learning disability read symbols. It is a language that has to be learnt, in a similar way to sign language.

PAS 78:2006 © BSI 8 March 2006 37

A.4 Deaf and hard of hearing

British Sign Language (BSL) users are especially relevant if there is multimedia content on the site or language issues.

Non-BSL deaf or hard of hearing users.

Annex B (informative)Possible criteria for determining success

B.1 Common website tasks

Tasks will depend on the aims of the website, but examples might include:

a) Find out how to contact the organization via email, phone or letter (for any site)

b) Find out what services are available on the site (eg a sitemap, for any site)

c) Find out a commonly searched-for bit of information (for information sites)

d) Buy a product in a reasonable length of time (for an e-Commerce site)

e) Successfully learn the thing you went to the site for (for learning/education sites).

B.2 Criteria for determining success

Criteria for determining success should include:

a) Effectiveness:

? How often can disabled users complete each task? (task completion rate)

? How well can they complete each task? (degree of completion, error rates)

b) Efficiency:

? How much effort does it take to complete each task? (number of keystrokes/clicks, time taken, pauses)

PAS 78:2006 38 © BSI 8 March 2006

c) Satisfaction:

? What is an appropriate experience? (different for education, banking, entertainment, buying products)

? Does the experience fit with your brand values?

? Perceived efficiency.

? Perceived effectiveness.

Annex C (informative)Suggested questions for suppliers

C.1 General

? Describe how your solution will meet the accessibility targets as outlined within our accessibility policy.

C.2 Requirements and design process

? Describe how your design process follows ISO 13407 Human-centred design processes for interactive systems.

? Provide a description of how requirements will be gathered from users and how the needs of disabled users will be taken into account.

? Provide an explanation of how your process will deliver an accessible design.

? Describe how you will validate early designs with users, including disabled users, and how feedback will be taken forward within your design process.

C.3 Packaged applications

? If your solution includes a packaged application that generates web pages, describe how your proposed package will ensure generated web pages meet the accessibility targets outlined within our accessibility policy.

? Describe any scenarios where the package application will not generate compliant WCAG [level] web pages and what will be done to correct this non-compliance.

? If your solution includes a package application that provides web-based application screens that will be used by employees, describe how these interfaces will meet the targets outlined within our accessibility policy.

PAS 78:2006 © BSI 8 March 2006 39

? Describe any scenarios where the package application will not generate compliant WCAG [level] web-based application screens and what will be done to correct this non-compliance.

? Where possible provide evidence that the packaged application has been tested for accessibility, including the methods that were used.

C.4 Development

? Describe the technologies that will be used to build the website and how these technologies will support our accessibility targets defined within the accessibility policy.

? If non-W3C technologies are used, provide a justification for using these technologies and how equivalent accessible functionality will be provided.

? Describe how your development process supports the creation of an accessible website.

C.5 Content creation

? If rich-media formats will be used, describe how these formats will be made accessible.

? If rich-media formats will be used that are not accessible, provide a justification for why these formats will be used and describe how equivalent accessible content will be provided.

C.6 Testing

? Explain how accessibility testing is included as part of the overall test plan.

? Provide a description of the accessibility test plan, and provide a rationale for the methods that have been included.

? Describe the accessibility testing methods and the list of accessibility test tools that will be used as part of the accessibility testing.

? List the usability testing techniques that are appropriate for this project and describe which standards will be followed and what measurements will be taken.

PAS 78:2006 40 © BSI 8 March 2006

? Describe the deliverables from the accessibility test plan and how the findings will be represented.

? Describe the process for correcting designs and code as a result of accessibility testing.

C.7 Maintenance

? Describe the governance process for ensuring that the website will remain accessible and usable.

? Describe the process for getting feedback from users who are using the site, including the process for making changes as a result of user feedback.

? Describe the process for evaluating how the website can be improved for usability and accessibility.

Annex D (informative)Accreditation

There is currently no UK government recognized accreditation scheme for website accessibility. Attention is drawn to the following initiatives because they are supportive of W3C.

D.1 EuroAccessibility Consortium (EA)

Recognition of the danger posed by fragmentation of web accessibility services and advice across Europe led to the creation of the EuroAccessibility Consortium (EA). This is a consortium of 23 European organizations working together to harmonize accessibility initiatives across Europe.

A primary objective of EA is the creation of an ?e-accessibility mark? or accreditation scheme for websites, based on harmonized web accessibility methodologies.

NOTE Website commissioners may refer to the EA website for the latest information: [http://www.euroaccessibility.org/].

D.2 Support-EAM (Supporting the creation of an e-Accessibility Quality Mark)

Support-EAM (Supporting the creation of an e-Accessibility Quality Mark) is a project of the Sixth Framework Programme of the European Commission (EC).

PAS 78:2006 © BSI 8 March 2006 41

The objective of Support-EAM is to create an e-Accessibility Quality Mark for Web services, as part of the EC Action Plan eEurope 2005: An information society for all.

Harmonization of Web Accessibility evaluation methodologies will result in a unified methodology that will allow the assessment of websites against the recommendations of W3C WAI.

Support-EAM began on 1 October 2004 for 18 months. Seven partners are involved in Support-EAM from seven European countries, including the UK.

The project refers to the Council Resolution on ?eAccessibility? ? improving the access of people with disabilities to the Knowledge Based Society (doc. 5165/03), inviting the Commission and the member states ?to consider the provision of an ?eAccessibility mark? for goods and services which comply with relevant standards for eAccessibility?.

For further information visit http://www.support-eam.org/.

In the absence of a W3C, UK Government or EU-recognized e-accessibility mark it should be noted that the Royal National Institute of the Blind (RNIB), who is a member of EA and a member of WAI, has developed the ?See it Right? accreditation mark for website accessibility.

NOTE Website commissioners may refer to the RNIB website for more information: [http://www.rnib.org.uk/wac/].

D.3 W3C WAI resources

Website commissioners and developers should refer to the W3C WAI document ?Evaluating websites for accessibility? for information about benchmarking and quality assurance: [http://www.w3.org/WAI/eval/].

Annex E (informative)Various references

E.1 Relevant industry bodies

The Usability Professionals' Association (UPA): supports those who promote and advance the development of usable products, reaching out to people who act as advocates for usability and the user experience [http://www.upassoc.org/].

PAS 78:2006 42 © BSI 8 March 2006

Web Standards Project (WaSP): a grassroots coalition campaigning for standards that ensure simple, affordable access to web technologies for all [http://www.webstandards.org/].

World Wide Web Consortium (W3C) and Web Accessibility Initiative (WAI): in coordination with organizations around the world, pursues accessibility of the web through five primary areas of work: technology, guidelines, tools, education and outreach, and research and development [http://www.w3.org/wai/].

E.2 Other relevant research, projects, guidelines and initiatives

eEurope 2005 Action Plan: launched at the Seville European Council in June 2002 and endorsed by the Council of Ministers in the eEurope Resolution of January 2003. It aims to develop modern public services and a dynamic environment for e-business through widespread availability of broadband access at competitive prices and a secure information infrastructure. [http://www.eu.int/information_society/eeurope/2005/].

e-Government Unit (eGU): a unit within the UK Government Cabinet Office that works with other government departments to deliver efficiency savings by improving the delivery of public services by joining up electronic government services around the needs of customers.[http://e-government.cabinetoffice.gov.uk].

NOTE The eGU publishes guidelines for the design of UK government websites that reference W3C guidelines and specifications.[http://e-government.cabinetoffice.gov.uk/Resources/WebGuidelines/].

European Design for All e-Accessibility Network (EDeAN): established in July 2002 in accordance with one of the specific goals of the eEurope 2002 Action Plan: ?to ensure the establishment and networking of national centres of excellence in design-for-all and create recommendations for a European curriculum for designers and engineers?. [http://www.e-accessibility.org/].

European Internet Accessibility Observatory (EIAO): a project that will assess the accessibility of European websites and participate in a cluster developing a European Accessibility Methodology. [http://www.eiao.net/].

IBM: the technology solutions provider publishes developer guidelines to help website commissioners (and developers) understand why and what they need to do to make their technology and information accessible to people with disabilities. [http://www.ibm.com/able/guidelines/].

PAS 78:2006 © BSI 8 March 2006 43

BenToWeb: aims to support the European public and private sector to implement the recommendations of the eEurope 2005 Action Plan by providing benchmarking tools that support the W3C guidelines and specifications. Their objectives are: to develop and assess test-suites for benchmarking of web accessibility evaluation and repair; to support W3C WAI in the improvement of the Evaluation and Repair Language (EARL) and the activities of the Evaluation and Repair Tools Working Group to be able to cope with large scale evaluations and complex statistical analysis. [http://www.bentoweb.org/].

E.3 Further sources of independent information and advice

Abilitynet: provides free information and advice, individual assessment of technology needs, the supply of assistive technology with free support, a programme of awareness education, and consultancy for employers on system and workstation adaptations. [http://www.abilitynet.org.uk/].

British Dyslexia Association: Aims to influence government and other institutions to promote a dyslexia friendly society. [http://www.bda-dyslexia.org.uk].

Disability Rights Commission (DRC): an independent body established by an Act of Parliament to eliminate discrimination and promote equality of opportunity for disabled people. [http://www.drc-gb.org/].

Mencap: The UK?s leading learning disability charity. [http://www.mencap.org.uk].

Royal National Institute of the Blind (RNIB): the UK?s leading charity offering information, support and advice to over two million people with sight problems. [http://www.rnib.org.uk/].

Royal National Institute for Deaf People (RNID): the largest charity representing the nine million deaf and hard of hearing people in the UK. [http://www.rnid.org.uk/].

Scope: A disability organization in England and Wales whose focus is people with cerebal palsy. [http://www.scope.org.uk/].

PAS 78:2006 44 © BSI 8 March 2006

Annex F (informative)Contracting usability testing services

F.1 Questions for suppliers

? Which usability testing techniques are appropriate for this project, eg interviews, surveys, focus groups, expert reviews and testing with real users?

? What standards are followed and what measurements will be taken?

? Can the supplier work to recognized ISO standards?

? What users will the supplier test?

? Will helpful and accurate answers be generated?

? How usable will the deliverables be?

? Can the deliverables be tailored to meet needs?

? Do the deliverables contain analysis, illustrations, raw data, and recommendations?

? Are the deliverables easy to digest: are findings prioritized and grouped meaningfully?

? Can the supplier provide support in the understanding and uptake of findings?

F.2 Criteria for assessing responses

? Can the supplier discuss the relative benefits of a range of methods?

? Can the supplier give examples of previous successes of different methods?

? Can the supplier distinguish between different types of real-user testing and advise accordingly?

? Does the supplier offer a range of expert review options?

? Can the supplier discuss the appropriateness of measurements and standards?

? Does the supplier use meaningful and actionable measurements?

? Can the supplier discuss the limitations of measurements in terms of statistical significance?

? Can the supplier provide screening documents for user recruitment, and justify their inclusions?

PAS 78:2006 © BSI 8 March 2006 45

? Does the supplier understand the importance of sample size, in relation to needs?

? Does the supplier focus on demonstrated problems and not users? feelings?

? Does the supplier use closed questions or lead users?

? Does the supplier use meaningful scenarios to test the website?

? Can the supplier work to technical and commercial constraints, where appropriate?

? Can the supplier suggest actionable solutions, not just state problems?

Annex G (informative)How to select a CMS system

A Content Management System (CMS) enables controlled update of the content of websites where many pages of content are published and/or many people are involved in the workflow processes needed to create and publish that content.

Modern CMS applications use templates (HTML styles that will surround the content to give each page the same look and feel). If the templates are not accessible then neither will the website be on which they are used.

Here are the following criteria that should be checked when selecting a CMS application:

? Are the CMS templates ?free-form? (that is, can have any HTML and CSS style in it) and you are not limited in ways that prevent you writing the templates to be accessible?

? When inserting non-text content such as images, does the CMS application enable content creation staff to add accessible attributes such as the ?ALT? attribute of the image tag?

? Does the CMS application write any code (such as _javascript_) that would undermine accessibility?

? Are the CMS control screens (usually HTML pages themselves) accessible?

? Several major CMS applications use flow diagrams which can be created when building a workflow ? are these diagrams accessible?

PAS 78:2006 46 © BSI 8 March 2006

? Many CMS applications offer the ability to transform files such as word processing documents, email, spreadsheets and databases into HTML ? but is it accessible? This is very important if automated transforms are to be used in the CMS workflows.

? Does the software manufacturer of the CMS application warrant that accessible web pages can be created by their system (as long as templates are accessible)?

? Does the CMS application have ways of testing for inaccessible content (for example, a content writer may add HTML or script inside their text which could ?confuse? a browser or other accessible technology and make that page inaccessible)?

? Many CMS applications offer Application Programming Interfaces (APIs) and either scripting or full programming languages to completely customize workflows for your organization. Dynamic web page creation using such facilities is powerful but be sure that those who develop against these APIs have a full understanding of accessibility issues.

PAS 78:2006 © BSI 8 March 2006 47

Bibliography

[1] GREAT BRITAIN. The Disability Discrimination Act 1995. London: The Stationery Office.

[2] Family Resources Survey 2003/04. London: Analytical Services Division, Department for Work and Pensions 2005.

[3] Disability Rights Commission. The Web: access and inclusion for disabled people (2004). London: DRC.

[4] Disability Rights Commission. Code of Practice ? Rights of Access, Goods, Facilities, Services and Premises, The Stationery Office Bookshop.

Standards

ISO 9241-11:1998 Ergonomic requirements for office work with visual display terminals (VDTs) ? Part 11: Guidance on usability.

ISO 16071:2003 Guidance on accessibility for human-computer interfaces.

?Guidelines for standards developers to address the needs of older persons and persons with disabilities? ? Cen/CENELEC Guide 6 ? edition 1 published January 2002.

Useful websites

Abilitynet http://www.abilitynet.org.uk/

Adobe http://www.adobe.com/

Becta (British Educational Communications and Technology Agency) http://www.becta.org.uk/industry/advice/advice.cfm?section=2&id=4360 (Website accessibility guide)

Disability Rights Commission http://www.drc-gb.org/

How people with disabilities use the web http://www.w3.org/WAI/EO/drafts/PWD-Use-Web/

IBM http://www.ibm.com/

Macromedia http://www.macromedia.com/

Mencap http://www.mencap.org.uk/accessibility

Microsoft http://www.microsoft.com/

PAS 78:2006 48 © BSI 8 March 2006

Royal National Institute of the Blind (RNIB) http://www.rnib.org.uk/

TechDis http://www.techdis.ac.uk/index.php?p=9

Usability Professionals Association (UPA) http://www.ukupa.org.uk

Useit.com http://www.useit.com/

W3C Web Accessibility Initiative (W3C WAI) http://www.w3.org/wai/

Web Standards Project (WaSP) http://webstandards.org/

World Wide Web Consortium (W3C) http://www.w3.org/

Relevant publications

Am I making myself clear ? Mencap?s guide to accessible writing, 2002. London, UK, Mencap [http://www.mencap.org.uk/download/making_myself_clear.pdf].

Braun, K., Gadney, M., Haughey, M., Roselli, A., Synstelien, D., Walter, T., Wertheimer, D. (2002) Usability: the site speaks for itself. Birmingham, UK: Glasshaus.

British Bankers Association Accessible e-banking: making your online service accessible to all (2001). London, UK: BBA.

Gybels, Guido (2004) Deaf and Hard of hearing users and Web accessibility. London, UK, RNID [www.ictrnid.org.uk/docs/webacc.pdf].

Howell, J. (2000) Get the message online: making websites accessible to blind and partially sighted people. London, UK: RNIB.

Keates, S. and Clarkson, J. (2003) Countering design exclusion: an introduction to inclusive design. London, UK: Springer.

Keates, S., Clarkson, J., Langdon, P. and Robinson, P. (Eds) (2004) Designing a more inclusive world. London, UK: Springer.

Krug, S. (2000) Don?t make me think! A common sense approach to web usability. Indianapolis, Indiana, USA: New Riders.

MCCAWS What Every Web Site Owner Should Know About Standards: A Web Standards Primer http://www.maccaws.org/kit/primer/.

PAS 78:2006 © BSI 8 March 2006 49

Nielsen, J. and Tahir, M. (2001) Homepage usability: 50 websites deconstructed. Indianapolis, Indiana, USA: New Riders.

Nielsen, J. (2000) Designing web usability. Indianapolis, Indiana, USA: New Riders.

Paciello, M.G. (2000) Web accessibility for people with disabilities. Lawrence, Kansas, USA: CMP Books.

Pernice Coyne, K. and Nielsen, J. (2001) How to conduct usability evaluations for accessibility: methodology guidelines for testing websites and intranets with users who use assistive technology. Fremone, California, USA: Nielsen Norman Group.

Spool, J., Scanlon, T., Schroeder, W., Snyder, C. and DeAngelo, T. (1999) Web site usability: a developer?s guide. San Francisco, California, USA: Morgan Kaufmann.

Thatcher, J., Bohman, P., Burks, M., Lawton Henry, S., Regan, B., Swierenga, S., Urban, M.D. and Waddell, C.D. (2002) Constructing accessible websites. Birmingham, UK: Glasshaus.

Velleman, E. and Snetselaar, H. (2000) Site seeing: the development of an accessible website or web-based multimedia product. Zeist, Netherlands: Bartimeus.

Zeldman, J. (2003) Designing with web standards. Indianapolis, Indiana, USA: New Riders.

PAS 78:2006 50 © BSI 8 March 2006

Index

A

Abilitynet E.3

access technology 3.19

for blind and partially sighted people 5.3

for deaf and hard of hearing people 5.4

definition 3.2

for people with cognitive impairments 5.6

for people with learning disabilities 5.5

for people with motor impairments 5.7

accessibility

and changes to operating systems 5.2

definition 3.1

maintenance see maintenance

testing see testing

accessibility auditing services 9

accessibility consultants 9.2

accessibility guidelines 3.22, 6.4

additional provisions 4.6

upholding 4.2

see also User Agent Accessibility Guidelines (UAAG); Web Content Accessibility Guidelines (WCAG)

accessibility policies

content 6.2

defining 6

development 4.1

public availability 6.3

accreditation 9.1.2, Annex D

adaptive technology see access technology

assistive technology see access technology

assistive technology tool testing 8.3.3

audio description 7.5.4.1

audio-video content 7.5.4

auditing services 9

Aural CSS (Cascading Style Sheets) 3.6

Authoring Tool Accessibility Guidelines (ATAG) 3.3, 6.4.3

upholding 4.2.3.1, 4.2.3.2

PAS 78:2006 © BSI 8 March 2006 51

authoring tools 4.2.3

definition 3.4

automated conformance testing tools 3.5, 4.3.2

automated testing 8.3.1

B

BenToWeb E.2

blind people

access technology for 5.3

and security measures for websites 7.6

see also vision impairment

British Dyslexia Association E.3

British Sign Language (BSL) users A.4

budgetary considerations for user testing 8.4.3.2.3, 8.4.3.3

C

?Captcha? 7.6

captioning software 7.5.4.3

Cascading Style Sheets (CSS) 3.6, 7.3

client side scripting and programming languages 7.4

CMS

definition 3.8

selection of Annex G

cognitive impairment

access technology for 5.6

definition 3.7

user profiles A.3

see also learning disabilities

cognitive walk-through 8.4.1.2

colour-blindness 5.3, A.1

Common Office file types 4.2.2.4

conformance checking 4.3

see also automated conformance testing tools

conformance inspection 8.4.2

consultancy services for web accessibility 9.2

content creation, questions for suppliers C.5

content formats 4.2.2

PAS 78:2006 52 © BSI 8 March 2006

content management system see CMS

content production system (CPS) 3.6

CSS (Cascading Style Sheets) 3.6, 7.3

D

Deaf Connexions 5.4.2

deaf people

access technology for 5.4

user profiles A.4

definitions, terms and 3

design process, questions for suppliers C.2

development, questions for suppliers C.4

disability

definition 3.9

see also impairment; learning disabilities

Disability Rights Commission (DRC) E.3

disabled people

involvement of 4.4

regular testing by 4.5

use of websites 5

dyslexia A.3

E

e-accessibility Quality Mark D.2

e-Government Unit (eGU) E.2

?easy to read? 5.6

ECMAScript 7.4

eEurope 2005 Action Plan E.2

EuroAccessibility Consortium (EA) D.1

European Design for All e-Accessibility Network (EDeAN) E.2

European Internet Accessibility Observatory (EIAO) E.2

expert review 8.4.1

F

Flash 3.10, 4.2.2.2, 7.5.3

Flash Player 3.10, 7.5.3.1

focus groups 8.4.3.3.3

PAS 78:2006 © BSI 8 March 2006 53

H

hard of hearing people

access technology for 5.4

user profiles A.4

heuristic evaluation 8.4.1.2

heuristics, definition 3.11

I

IBM E.2

impairment

definition 3.12

see also cognitive impairment; motor impairments; vision impairment

industry bodies E.1

internal evaluators 8.4.3.3.3

interoperability, definition 3.13

J

_javascript_ 7.4

L

learning disabilities

access technology for 5.5

definition 3.14

user profiles A.3

M

Macromedia Accessibility resource centre 7.5.3.3

maintenance 8.1, 8.5

questions for suppliers C.7

mark-up, definition 3.15

Mencap E.3

mobility, user profiles A.2

motor impairments, access technology for 5.7

O

object models 7.4.1

operating systems, changes to optimise accessibility 5.2

PAS 78:2006 54 © BSI 8 March 2006

P

packaged applications, questions for suppliers C.3

partially sighted people

access technology for 5.3

and security measures for websites 7.6

see also vision impairment

PDF (Portable Document Format) 3.17, 4.2.2.2, 7.5.2

physical impairments 3.12

see also motor impairments

plug-in rich media formats 7.5

plug-ins, definition 3.16

programming languages, client side scripting and 7.4

publicly available accessibility policy statements 6.3

R

requirements, questions for suppliers C.2

Royal National Institute of the Blind (RNIB) E.3

Royal National Institute for Deaf People (RNID) E.3

S

sample sizes for user testing 8.4.3.3.1

Scope E.3

screen magnification software 5.3

screen reader software 5.3

security measures for websites 7.6

?See it Right? accreditation mark D.2

self-awarded logos 6.2.3

sensory impairments 3.12

see also blind people; deaf people

signing avatars 5.4.2

specialised evaluators 8.4.3.3.3

spreadsheet documents 4.2.2.4

structural languages 7.2

style sheets 3.6, 7.3

success, criteria for determination of Annex B

suppliers, suggested questions F.1, Annex C

supportEAM D.2

PAS 78:2006 © BSI 8 March 2006 55

T

technical accessibility, determination 8.3

terms and definitions 3

test plans 8.1.3

creation of 8.2

testing 8

key stages 8.1.6

questions for suppliers C.6

for technical accessibility 8.3

for usable accessibility 8.4

textphone facilities 6.2.4

?Turing test? 7.6

U

UAAG (User Agent Accessibility Guidelines) 3.20, 6.4.4

usability, definition 3.18

Usability Professionals' Association (UPA) E.1

usability testing services, contracting Annex F

usable accessibility, determination 8.4

user agent, definition 3.19

User Agent Accessibility Guidelines (UAAG) 3.20, 6.4.4

user profiles Annex A

user testing 8.4.3

budgetary considerations 8.4.3.2.3, 8.4.3.3

by disabled people 4.5

ethical and practical issues 8.4.3.2.4

methods 8.4.3.2

reasons for 8.4.3.1

recruitment for 8.4.3.3.2

V

validation 8.3.2

vision impairment

user profiles A.1

see also blind people

visual-orientated anti-robot tests 7.6

PAS 78:2006 56 © BSI 8 March 2006

W

W3C (World Wide Web Consortium) 3.29, E.1

W3C specifications 3.23

and additional accessibility provisions 4.6

upholding 4.2

W3C WAI (Web Accessibility Initiative) 3.24, E.1

W3C WAI (Web Accessibility Initiative) resources D.3

W3C/WAI guidelines see accessibility guidelines

web accessibility consultancy services 9.2

Web Content Accessibility Guidelines (WCAG) 3.25, 6.4.2

upholding 4.2.2.2

web design, contracting 9

Web Standards Project (WaSP) E.1

web technologies 7

webpage template, definition 3.26

website commissioners 3.27

website developers 3.28, 5.1.2

choosing 9.1

and the need for user testing 8.4.3.1

word processing 4.2.2.4

World Wide Web Consortium (W3C) 3.29, E.1