D 2.2a – User needs and System Requirements Specification

ACCESSIBLE Deliverable D2.2b -RE- Grant Agreement No. 224145

(Final Draft) of 174- SUN

SEVENTH FRAMEWORK

PROGRAMME

INFORMATION AND COMMUNICATION

TECHNOLOGIES

Project:

Accessibility Assessment Simulation Environment for New

Applications Design and Development

(ACCESSIBLE, Grant Agreement No. 224145)

Deliverable number and title:

D 2.2b – User needs and System Requirements Specification

Lead beneficiary: SUN

WP. no, title

and activity type

WP2 – User needs, benchmarking, accessibility and

simulation requirements

Contributing Task

(s)

T2.1, T2.2

Dissemination

level

RE

Delivery date September 2009

Status Final Draft

File name and

size

ACCESSIBLE-SUN-WP2-D2.2B-FD-09-2009.doc



Authors List

Leading Author (Editor)

Surname Initials Beneficiary Name

(Short Name

Contact email

Korn P. SUN [email protected]

Co-authors (In alphabetic order)

# Surname Initials Beneficiary Name

(Short Name

Contact email

1. Votis K. CERTH/ITI [email protected]

3. Tzovaras D. CERTH/ITI

[email protected]

4. Segouli S. CERTH/ITI

[email protected]

5 Bekiaris E. CERTH/HIT

[email protected]

6 Chalkia H. CERTH/HIT

[email protected]

7. Lopes R. FFCUL [email protected]

8. Kavadias C. SOLINET [email protected]

9. RIngler M. NETSCOUTS [email protected]

10. Papadopoulou M. FORTH [email protected]

11. Van Isacker KVI MCA [email protected]

12 Goranova-Valkova MGV MCA [email protected]

13 Lazarov AL MCA [email protected]

14 Van Isacker KVI MCA [email protected]

15 Loupis M. SOLINET [email protected]

17 Leuteritz J. USTUTT jan-

[email protected]

mailto:[email protected]






Peer Reviewers List # Surname Initials Contact email

1 Grudeva P. [email protected]

2 konschewitz H. [email protected]



Executive Summary This deliverable (D2.2.b) reports the final draft of the ACCESSIBLE user needs and

the captured user and system requirements and specifications for the ACCESSIBLE

environment, based on the deliverable D2.2.a” User needs and System Requirements

Specification (first version)” that has been delivered by month 6. The deliverable

D2.2 from Work package 2 is structured into two phases: the initial cycle (scheduled

for months 1-6) covers the definition of the initial user requirements (D2.2a), whereas

the second cycle (scheduled for months 6-12) extracts appropriate User needs and

improves the requirements on the basis of the feedback from end users. In addition to

the final requirements definition of the ACCESSIBLE components through the results

of the performed questionnaires and interviews, this deliverable D2.2b will try to

define ACCESSIBLE user needs and give answers to common accessibility questions

such as “Why developers don‟t develop accessible products”. The results of this

analysis will help developers better understand how the system designed in the first

phase of the Project fits the real end-user needs and how the whole framework is

perceived from an external point of view.



Table of contents

Authors List ................................................................................................................... 2 Peer Reviewers List ....................................................................................................... 3

Executive Summary ....................................................................................................... 4 Table of contents ............................................................................................................ 5 List of figures ................................................................................................................. 7 List of tables ................................................................................................................... 8 List of abbreviations and acronyms ............................................................................. 10

1 Introduction ............................................................................................................... 11

2 Glossary- Terminology ............................................................................................. 11

3 User Needs ................................................................................................................ 14 3.1 Introduction ........................................................................................................ 14 3.2 User Needs Methodology .................................................................................. 14 3.3 Target User Groups ............................................................................................ 16

3.3.1 First Category (Developers and designers) ................................................. 17

3.3.2 Second Category (Users with disabilities and elderly) ............................... 18

3.3.3 Organizations concerning people with disabilities ..................................... 20 3.4 User Questionnaires and Interviews .................................................................. 23

3.4.1 Methodological Structure – A Theoretical Approach ................................. 23

3.5 Analysis of Questionnaires and interviews ........................................................ 29 3.6 Overview collected data ..................................................................................... 30

3.7 User Group Analysis .......................................................................................... 32 3.7.1 Developers Group ....................................................................................... 32

3.7.2 Accessibility Assessors Group .................................................................... 34 3.7.3 Public Bodies/Governmental Agencies Group ........................................... 35 3.7.4 Service Providers Group ............................................................................. 38

3.7.5 Elderly and Disabled Users Group ............................................................. 39 3.8 Qualitative and Quantitative Evaluation of the Survey Data ............................. 41

3.8.1 Developers .................................................................................................. 41 3.8.2 Accessibility Assessors ............................................................................... 47 3.8.3 Public Bodies .............................................................................................. 50 3.8.4 Service Providers ........................................................................................ 59

3.8.5 Elderly and Disabled Users ......................................................................... 63

3.9 Extracting the User Needs / Requirements ........................................................ 67

4 ACCESSIBLE System Requirements....................................................................... 75 4.1 Requirements Taxonomy ................................................................................... 75 4.2 Requirements Prioritization ............................................................................... 76 4.3 ACCESSIBLE Architectural scheme ................................................................ 76 4.4 General requirements of ACCESSIBLE system................................................ 79

4.4.1 Generic functional requirements ................................................................. 81 4.4.2 Performance requirements .......................................................................... 82 4.4.3 Operational requirements ............................................................................ 82 4.4.4 Reliability requirements .............................................................................. 82 4.4.5 Maintainability & Interoperability requirements ........................................ 83

4.5 ACCESSIBLE Assessment Simulation Module Requirements ........................ 83

4.5.1 Generic functional requirements ................................................................. 83



4.5.2 Performance requirements .......................................................................... 85

4.5.3 Operational requirements ............................................................................ 85 4.5.4 Reliability requirements .............................................................................. 85 4.5.5 Maintainability & Interoperability requirements ........................................ 85

4.6 ACCESSIBLE ontological Knowledge Resource Requirements ...................... 86

4.6.1 Generic functional requirements ................................................................. 86 4.6.2 Performance requirements .......................................................................... 87 4.6.3 Operational requirements ............................................................................ 87 4.6.4 Reliability requirements .............................................................................. 87 4.6.5 Maintainability & Interoperability requirements ........................................ 87

4.7 ACCESSIBLE User Interface Requirements ..................................................... 87 4.7.1 User Interface Portal ................................................................................... 88 4.7.2 Stand alone tools user interface .................................................................. 90

4.8 ACCESSIBLE Developer/designer–aid module Requirements ........................ 91 4.8.1 Performance requirements .......................................................................... 92 4.8.2 Operational requirements ............................................................................ 92 4.8.3 Maintainability & Interoperability requirements ........................................ 92

4.9 ACCESSIBLE EARL-based reporting tool Requirements................................ 92 4.9.1 Generic Functional requirements ................................................................ 92

4.9.2 Performance requirements .......................................................................... 93 4.10 Ranking of system requirements ...................................................................... 93

5 Conclusions ............................................................................................................. 103 Annex 1: Methodology for User Needs Questionnaires Creation and Evaluation .... 104

The questionnaires ................................................................................................. 104

Survey format......................................................................................................... 104

Survey propagation ................................................................................................ 105 Construction of the Questionnaires ............................................................................ 108

Content of the Questionnaires ................................................................................ 108

Questionnaires per target group ............................................................................. 112 Questions sample ................................................................................................... 113

Target Groups ........................................................................................................ 115 Relationship between the Target Groups ............................................................... 118

Data Analysis – Data Management............................................................................ 120

Annex 2: ACCESSIBLE Questionnaires (in English Language) .............................. 122



List of figures Figure 1: The phases of the identification of User Needs ............................................ 14 Figure 2: ASK-IT user groups ..................................................................................... 19 Figure 3: ACCESSIBLE online questionnaire ............................................................ 27 Figure 4: ACCESSIBLE online questions ................................................................... 28

Figure 5: Age distribution - developers group ............................................................. 32 Figure 6: Accessibility engagement per country ......................................................... 33 Figure 7: Age distribution- accessibility assessors group ............................................ 34 Figure 8: Distribution of associations concerning accessibility - accessibility assessors

group ............................................................................................................................ 35

Figure 9: Age distribution – public bodies/governmental agencies group .................. 36

Figure 10: Interest in learning more about web accessibility - public

bodies/governmental agencies group ........................................................................... 37 Figure 11: Interest in learning more about mobile accessibility - public

bodies/governmental agencies group ........................................................................... 37 Figure 12: Age distribution - service provider group .................................................. 38 Figure 13: Age distribution - elderly and disabled people group ................................ 39

Figure 14: Disability distribution - elderly and disabled people group ....................... 39

Figure 15: Disability distribution by age - elderly and disabled people group ............ 40 Figure 16: Interests in further education - developers group ....................................... 42 Figure 17: Availability of an accessibility assessment tool – developers group ......... 46

Figure 18: Knowledge of the terms “usability” and “accessibility” – public

bodies/governmental agencies group ........................................................................... 51

Figure 19: Meaning of accessibility - public bodies/governmental agencies group .... 52

Figure 20: Methods to keep up to date – public bodies/governmental agencies group

...................................................................................................................................... 53 Figure 21: Interests in further education – public bodies/governmental agencies group

...................................................................................................................................... 53

Figure 22: Channels of dissemination of accessibility results - public


Figure 23: Expectations of an accessible website – Technical expectations – public

bodies/governmental agencies group ........................................................................... 55 Figure 24: Being in touch with people with disability – service provider group ........ 60 Figure 25: Device usage – elderly and disabled user group ........................................ 64

Figure 26: Problems in using ICT – elderly and disabled user group ......................... 65 Figure 27: Solving ICT problems – elderly and disabled user group .......................... 66

Figure 28: ACCESSIBLE architecture ....................................................................... 77 Figure 29: ACCESSIBLE multilayer ontological framework ..................................... 78 Figure 30: Questionnaire overview, available online via http://www.accessible-

project.eu/index.php/questionnaire.html .................................................................... 105 Figure 31: Article on Disabled.gr to attract participants -

http://www.disabled.gr/lib/?p=20322 ........................................................................ 106 Figure 32: Article in e-Inclusion Newsletter - 12/06/2009 ........................................ 106 Figure 33: Article in European ePractice Newsletter N. 282 - 9 June 2009 .............. 107 Figure 34: Example of ordinal scaled question from the Questionnaire for Elderly and

Disabled users ............................................................................................................ 113

Figure 35: Example of a Matrix Question ................................................................. 114 Figure 36: Example of a Multiple Answers Question ............................................... 115

Figure 37: Relationship between the target groups .................................................... 116



List of tables Table 1: ACCESSIBLE project beneficiaries‟ contacts .............................................. 15 Table 2 : ACCESSIBLE user groups (service providers, developers, etc.) ................. 18 Table 3: ACCESSIBLE user groups (people with disabilities and older people) ....... 20

Table 4: Contacts of Netscouts and MCA with end-users (organisations and

individuals) .................................................................................................................. 23 Table 5: Questionnaire dissemination per partner by country ..................................... 30 Table 6: Individuals surveyed by country .................................................................... 30 Table 7: Gender distribution per user group ................................................................ 31

Table 8: Methods of keeping up to date - developers group........................................ 33

Table 9: Methods of keeping up to date - accessibility assessors group ..................... 35

Table 10: Methods of keeping up to date - accessibility assessors group ................... 37 Table 11: Methods of keeping up to date – service provided group ............................ 38 Table 12: Familiarity with standards and guidelines – developers group ................... 42 Table 13: Usage of accessibility evaluation and AT tools – developers group ........... 44 Table 14: Desired usage of accessibility evaluation tools – developers group ............ 45

Table 15: Familiarity with standards and guidelines – accessibility assessors group . 47

Table 16: Keeping up-to-date on accessibility issues – accessibility assessors group 48 Table 17: Usage of accessibility evaluation and AT tools – accessibility assessors ... 48 Table 18: Desired usage of accessibility evaluation tools – accessibility assessors

group ............................................................................................................................ 49 Table 19: Reasons of dealing with accessibility – public bodies/governmental

agencies group ............................................................................................................. 51 Table 20: Difficulties faced in crating accessible website – public

bodies/governmental agencies group ........................................................................... 55 Table 21: Accessibility assessment – public bodies/governmental agencies group .... 56 Table 22: Accessibility assessment – public bodies/governmental agencies group .... 56

Table 23: Support in enforcing accessibility – public bodies/governmental agencies

group ............................................................................................................................ 57

Table 24: Accessibility evaluation software implementations – public

bodies/governmental agencies group ........................................................................... 57 Table 25: Usage of accessibility evaluation and AT tools – public


Table 26: Desired usage of accessibility evaluation tools – public


Table 27: Reason of dealing with accessibility – service providers group .................. 60 Table 28: Learn more about accessibility – service providers group .......................... 61 Table 29: Familiarity with standards and guidelines – service providers .................... 61 Table 30: Ways to evaluate accessibility developments – service providers group .... 62 Table 31: Usage of accessibility evaluation and AT tools – service providers group . 62

Table 32: Desired usage of accessibility evaluation tools – service providers group . 63 Table 33: Devices – elderly and disabled user group .................................................. 64 Table 34: Web sites enhancement for the improvement of their accessibility – elderly

and disabled user group ............................................................................................... 65 Table 35: Dedicated generic functional requirements, extracted from user

requirements ................................................................................................................. 74 Table 36: Ranking of ACCESSIBLE system requirements ...................................... 101

Table 37: ACCESSIBLE end-user group .................................................................. 116



Table 38: ACCESSIBLE ICT providers .................................................................... 117

Table 39: ACCESSIBLE service providers ............................................................... 117 Table 40: ACCESSIBLE resellers ............................................................................. 117 Table 41: ACCESSIBLE research centres ................................................................. 117 Table 42: ACCESSIBLE public bodies/government ................................................. 118

Table 43: Related target groups ................................................................................. 118



List of abbreviations and acronyms

Abbreviation Explanation

ASK IT Ambient Intelligence System of Agents for Knowledge based

and Integrated Services for Mobility Impaired Users

ASP Active Server Pages

DL Description Logic

EARL Evaluation And Report Language

GUI Graphical User Interface

HTML HyperText Markup Language

ICF International Classification of Functioning, Disability and

Health

IDE Integrated Development Environment

IEEE Institute of Electrical and Electronics Engineers

ISO International Organization for Standardization

JAR Java ARchive

JSP JavaServer Pages

MWBP Mobile Web Best Practices

NGO Non Governmental Organisation

OASIS Open architecture for Accessible Services Integration and

Standardization

OWL Ontology Web Language

RDF Resource Description Framework

RPC Remote procedure call

SDL Semantic Description Language

SPARQL SPARQL Protocol and RDF Query Language

SOAP Simple Object Access Protocol

SWRL Semantic Web Rule Language

URL Uniform Resource Locator

WCAG Web Content Accessibility Guidelines

WHO World Health Organization

WSDL Web Services Description Language

ACCESSIBLE Deliverable D2.2a -RE- Grant Agreement No. 224145

(Final Draft) 11- SUN

1 Introduction

This is the final version of the user needs and system requirements specification

document for the ACCESSIBLE system components. Its purpose is to provide a

collection of user needs and statements to form research directions for the project. The

requirements specified here are based on several inputs: Description of Work (DoW)

document, the pilot applications elaborated throughout T2.4, the current state-of-the

art in the technology fields addressed by ACCESSIBLE within the T2.1 (deliverable

D2.1), outcome from the project meetings (kick off meeting September 2008, Prague

– 2nd

plenary meeting January 2009, Genoa – WP2 meeting, December 2008

Stuttgart), input from several informal discussions among the project consortium as

well as opinions and expectations of potential ACCESSIBLE users through

questionnaires and interview survey (i.e.: developers, software companies, service

providers).

This document covers target user groups, generic functional and non-functional as

well as operational, reliable, and other requirements. Therefore this deliverable will

help us to focus on ACCESSIBLE system components providing requirements

specifications that will attempt to address in the best way the ideal functionality that is

expected for such a system.

The report begins (section 2) with a glossary thoroughly describing the technical

terms and definitions used throughout the deliverable. This glossary facilitates the

comprehension of many technical parts of the document and helps the reader to

understand technical details.

Section 3 presents the particular methodology that has been followed for the user

needs based on questionnaires and interviews and it continues with the identified

ACCESSIBLE target user groups. The extracted user needs and the evaluation results

of the questionnaires and interviews survey will be included to the D2.2b.

Section 4 provides an overview of ACCESSIBLE final system requirements based on

the initial requirements of D2.2a. In this chapter the different requirements of the

ACCESSIBLE modules are described.

This deliverable serves in reaching one of the main goals within the ACCESSIBLE

project; the integration of user‟s opinion into the project design and development

process to guarantee the high user acceptance of project results. Thus the document

also includes annex I which describes the methodology adopted for the creation and

the evalution of the questionnaires as well as annex II which includes the five

questionnaires (in English) that were used for the collection of user requirements.

2 Glossary- Terminology

Accessibility: The ability to access. Often tied to people with disabilities (e.g., total

blindness), accessibility thrives to break the barriers to information access. We follow

the strict sense of accessibility by embracing any situation where the ability to access

information can be disrupted by device or even surrounding environment constraints.

Accessibility Guidelines: A set of best practices (e.g. WCAG, Section 508, etc.) that

must be followed by designers and developers when implementing software solutions



(e.g., Web site) that will help on providing accessible information. By being

guidelines, it should not be assumed that content is accessible just by following them.

Checkpoint: A concrete verification task that materializes a (part of a) guideline.

Checkpoints can be fully automated if application technology provides corresponding

support (e.g., verifying if all images have associated textual captions).

Integrated Development Environment: A computer application used by developers

that provides several features to ease the task of developing applications, such as text

editor, compiler, automation features, etc.

Usability: A research field that studies how adequate user interfaces are to users, how

easily can they learn to perform tasks, and what are their levels of satisfaction when

interacting with user interfaces.

User Interface: The “visible” side of an application, where users can acquire and

interact with information.

ACCESSIBLE user interface: It can be thought of as a hyper-portal where

developers can use the Web based services of the ACCESSIBLE components, as well

as to download the standalone modules and finally to extract useful information for

accessibility guidelines, standards, etc. Where appropriate, Web based versions of the

ACCESSIBLE tools will be supported in addition to standalone applications and/or

plug-ins for appropriate Integrated Development environments (IDE) such as

Netbeans.

Web Accessibility: The subfield of accessibility that is targeted to the specific

technologies and architecture that compose the World Wide Web. This includes

technologies such as HTML, CSS and JavaScript, as well as the HTTP protocol.

ACCESSIBLE Assessment Simulation module: The module that will support the

overall analysis and verification in terms of accessibility for Web applications, Web

services mobile applications and description languages (UML, SDL, etc.).

ACCESSIBLE Open source developer & designer’s aid module: It can support

users to facilitate the design and development of accessible software applications.

ACCESSIBLE target user groups (developers, designers, etc.) will be supported with

specific tool(s) that afford designing and implementing accessible software

applications. These tool(s) will be based on already existing open-source software

architectures and technologies from SUN, such as the NetBeans IDE, JAAPI, etc.

ACCESSIBLE knowledge resource: A multilayer ontological framework in order to

provide a set of domain ontologies to describe users with disabilities, accessibility

guidelines and well known standards, assistive devices as well as how these concepts

can be integrated to form the semantic accessibility assessment of software

applications through appropriate SWRL (Semantic Web Rule Language) and

SPARQL rules and queries.

Semantic Web Rule Language (SWRL): is a proposal for a Semantic Web rules-

language, combining sublanguages of the OWL Web Ontology Language (OWL DL

and Lite) with those of the Rule Markup Language (Unary/Binary Datalog). The



specification was submitted in May 2004 to the W3C by the National Research

Council of Canada, Network Inference (since acquired by webMethods), and Stanford

University in association with the Joint US/EU ad hoc Agent Markup Language

Committee.

SPARQL: is an RDF query language that allows for a query to consist of triple

patterns, conjunctions, disjunctions, and optional patterns; its name is a recursive

acronym that stands for SPARQL Protocol and RDF Query Language. It is

standardized by the RDF Data Access Working Group (DAWG) of the World Wide

Web Consortium, and is considered a component of the semantic web. Initially

released as a Candidate Recommendation in April 2006, but returned to Working

Draft status in October 2006, due to two open issues. On 15 January 2008, SPARQL

became an official W3C Recommendation.

Evaluation and Reporting Language (EARL): The EARL which has been proposed

by W3C evaluation and Repair Tools Working Group (ERT WG) is a language to

express test results such as bug reports and conformance claims and enables any

person, entity, or organization to state test results for anything tested against any set of

criteria.

ACCESSIBLE EARL-based reporting tool: A relevant module to export

accessibility evaluation results in a form helpful to potential receivers of test results,

include designers, developers and business stakeholders.



3 User Needs

3.1 Introduction

The ACCESSIBLE project should define in a sufficient way the user needs in order to

understand the needs of the users, as well as to fulfil them. ACCESSIBLE project is

targeting different target user groups. Their needs should be identified for each one of

these target user groups, since they have different needs. It is also important to

investigate the reasons that have lead developers to not incorporate accessible

technologies to their tasks. This needs survey will provide information that will be

helpful for the project implementations.

This deliverable will try to analyse the user needs methodology process and its

phases. Once the methodology is well defined, the target user groups are described.

The questionnaires and the interviews are oriented to these target groups, therefore a

more detailed analysis of both of them follows. The determination of user needs is

practically based on a questionnaire survey and personal interviews (most of them by

phone), which could enhance the understanding of motivations of ACCESSIBLE

potential users. The deliverable D2.2a will be updated in M12 (D2.2b) in order to

incorporate the extracted user needs based on the results of the questionnaires and the

interviews survey.

3.2 User Needs Methodology

The methodology of identifying the user needs can be divided in three phases. These

three phases are illustrated in Figure 1.

Figure 1: The phases of the identification of User Needs

The first phase is the phase of Information Gathering. To identify the user needs, a lot

of information should be taken into account. The user requirement collection started

from the already assessed knowledge provided by ACCESSIBLE software developers

as well as representative organizations of people with disabilities.



The successfully extraction of User needs and system requirements specifications for

ACCESSIBLE was also enhanced through the investigation results of deliverable

D2.1: State of the Art Survey in Accessibility Research and Market Survey, which is

oriented to investigating the accessibility standards, methodologies, assessment

simulation tools and products. Additionally, a great amount of information can be

deducted from the analysis of current legislation and regulations concerning

accessibility in different countries. All the above mentioned information will be the

starting point and provide the basis for ACCESSIBLE project to fulfill the user needs.

The ACCESSIBLE User Community, according to the user needs methodology, is

represented by:

Professional users: such as Developers, Accessibility Assessors and Service

provides

End users: the two main categories of end users are people with disabilities

and older people.

Other Organizations: including Public and governmental Bodies

Since the organisations of ACCESSIBLE project beneficiaries represent different

groups in the aforementioned target user categories it was decided to use the contacts

and mailing lists from partners to reach relevant user groups (ref. as depicted to the

following table which has been prepared during the kick off meeting of the project).

Beneficiary /

Country Location

Accessibility

assessors

Developers Service

Providers

Elderly

/

disabled

Public bodies /

Governmental

organisations

CERTH / Greece x x x

FORTH- ICS /

Greece x x

SUN / Czech

Republic x x

USTUTT / Germany x x

ALDAG / Germany x x

FFCUL /Portugal x x x

SOFTECO /Italy x x x

NETSCOUTS /

Germany x x x

MCA / Bulgaria x x

CS / Switzerland x x

SOLINET / Italy x

Table 1: ACCESSIBLE project beneficiaries‟ contacts



Identified users from all abovementioned categories have been contributing to the

second phase, namely the interaction with users, which has been achieved via

questionnaires and interviews. The following strategy was applied:

Preparation and circulation of Questionnaires: Appropriate questionnaires

were drafted, each addressing a beneficiary group. These different

questionnaires were made available in an online and an offline printable

version. They were subsequently translated in Czech, English, French,

German, Greek, Italian and Portuguese.

Interviews: Interviews took place with software developers, designers, as well

as end users (older people and people with disabilities) and public bodies from

Italy, Germany, Greece and Bulgaria. The interviews (see annex 1) addressed

a wide range of topics regarding accessible design and development of ICT

applications. Particular problems in these areas will be documented and passed

to the ACCESSIBLE project team for further analysis and consideration for

inclusion in the project User needs and system requirements. All of the

interviews will be semi-structured, with a focus on accessibility issues

highlighted by the interviewees, but with as basis the developed

questionnaires. Interviews may be recorded, but only after the formal consent

of the interviewee. Developers and designers from ACCESSIBLE partners

were separately interviewed to allow them the opportunity to speak openly

about their current experiences with accessibility issues and the reason why

they don‟t develop accessible applications.

The main advantage of the questionnaires and the interviews is that the users

themselves, even if they are not familiar with the concept of accessibility (such as

elderly or public bodies) will have the opportunity to get informed regarding

accessibility for software applications and answer different kind of questions for

addressing their user needs concerning accessibility.

Thus, the evaluation phase that will be performed after the collection of

questionnaires and interviews data, it will address the user needs that will feed into

ACCESSIBLE final requirements and architecture definition. For that reason the

deliverable D2.2a will be updated in M12 (D2.2b) in order to incorporate the

extracted user needs.

3.3 Target User Groups

The Target User Groups consists of two main categories. The first category includes

the developers, designers, and accessibility assessors. This category will ultimately

benefit the most from the ACCESSIBLE tools and methodologies, providing them the

means to assess and improve the accessibility status of their ICT applications and

services. Equally, this group also contains the service providers, and the public bodies

and governments that will make use of ACCESSIBLE tools to render their services in

an accessible manner.

The second category includes people with disabilities and/or older people. The

disabilities/impairments that have been taken into account in the ACCESSIBLE

project include the cognitive, hearing, visual, communication receiving and producing

and upper-limb impairments.



In the following paragraphs we address each of these 2 main categories of target user

groups.

3.3.1 First Category (Developers and designers)

The first category of the ACCESSIBLE user groups is a rather heterogeneous group

because it includes users with different knowledge and expertise, often involved in all

stages and phases of the design and development process. These users have been

identified according to their job positions within software organisations and ICT

providers (Table 2). A similar approach has also been applied in WP8 for the

definition of potential stakeholders that will be targeted by the project‟s dissemination

activities.

Developers, service providers and other user groups

ICT providers

AT Tutors/instructors

Formal (e.g. Augmentative

Communication Specialist)

Informal

AT Trainers

Formal

Informal

ICT providers

Industrial players

(hardware/software)

(AT) designers

(AT) developers

Mainstream software developers

(AT) Specialist/Consultant

SMEs (hardware/software) (AT) designers

(AT) developers



Individuals

(hardware/software)

OS developers

Web application developers

Desktop developers

Mobile application developers

Mainstream software experts


Accessibility assessors

Service providers

Private Mobile service providers

Web service providers

Training institutions

Support services

Public Training institutions

Support services



Developers, service providers and other user groups

Resellers

AT resellers

Software resellers

Hardware resellers

Research centres

AT research centre

Public bodies/government

Disability agencies

Universities

Centres of VET1

Standardisation bodies

AT specialists

Table 2 : ACCESSIBLE user groups (service providers, developers, etc.)

3.3.2 Second Category (Users with disabilities and elderly)

The second category of the users with disabilities is equally quite heterogeneous. One

must not only consider the normal grouping of end-users, but has to consider

especially the functional limitations and (in WP3) its impact on the usage of software,

web and mobile applications.

In order to proceed in a structured manner, we will use and combine following already

existing resources, namely:

- The ICF (WHO‟s International Classification of Functioning, Disability and

Health), located at http://www.who.int/classifications/icfbrowser/2;

- ASK-IT‟s3 User groups classification and Potential demography of Mobility

Impaired People in Europe;

- OASIS4 Internal Deliverable 5.5.6 OASIS users‟ and stakeholders‟ groups.

From the ICF classification, we focus on the body functions (b) and the activities and

participation (d) as these are directly pinpointing whether a disability occurs or not

and we will select those components and chapters that are relevant for ACCESSIBLE,

and translate them into functional limitations. In a next step, these functional

limitations will be linked to specific disabilities as will be derived from the ASK-IT

user groups input (Figure 2), while in addition, the OASIS elderly grouping will be

considered.

1 Vocational Education and Training

2 The paper “Universal accessibility as a multimodal design issue” from Obrenovic et al provides some

clues about structuring ICF for Accessibility issues. Other papers from Obrenovic (c.f.

http://www.idemployee.id.tue.nl/z.obrenovic/index.html) further explore this. 3 ASK-IT FP6 IP project: http://www.ask-it.org/

4 OASIS FP7 IP running project: http://www.oasis-project.eu/

http://www.idemployee.id.tue.nl/z.obrenovic/index.html



Figure 2: ASK-IT user groups

We will however disregard the following groups as they are not targeted by

ACCESSIBLE project:

- Lower limb impairment

- Wheelchair users (but not those with upper limb impairments)

- Upper body impairment

- Physiological impairment

- Psychological impairment

Thus the following groups were retained for ACCESSIBLE:

Disability(ies) Disability(ies)

Cognitive impairment Dementia

Dysarthria

Down syndrome

Learning disability (LD

Learning disability (LD) - Speech and language

disorders

Learning disability (LD) - Academic skills disorders

Learning disability (LD) - Nonverbal Learning



Disability(ies) Disability(ies)

Disorder

Attention Deficit Hyperactivity Disorder (ADHD)

Traumatic Brain Injury

Alzheimer disease

Hearing impairments Conductive Hearing Loss

Sensorineural Hearing Loss

Profound hearing loss

Deaf-blindness

Vision impairments Low vision

• Loss of central vision

Low vision

• Loss of peripheral (side) vision:

Low vision

• Blurred vision

Low vision

• Extreme light sensitivity

Low vision

• Night blindness

Blindness

Colour-blindness

Communication received and producing

impairments

Autism

Asperger‟s syndrome

Expressive language disorder

Communication disability

Upper limb impairment Cerebral palsy

Multiple sclerosis

Parkinson disease

Dyspraxia

Arthritis

Tic disorders

Rett Syndrome

Tourette syndrome

Quadriplegia

Dystrophy

Absent limb/ reduced limb function

Table 3: ACCESSIBLE user groups (people with disabilities and older people)

3.3.3 Organizations concerning people with disabilities

The involvement of people with disabilities in order to define ACCESSIBLE user

needs as well as to evaluate the developed accessible software applications or services

will be supported by NETSCOUTS beneficiary as a fully owned subsidiary of the

“association for people with disabilities” in Nuremberg (www.behinderte-

nuernberg.de) and MCA, an NGO with close cooperation with numerous

organisations grouping people with disabilities as well as older people, and 100s of

disabled individuals.



In the context of WP2, a list of peer groups, organisations and participants to be

interviewed has been established and identifies the various end-users in Germany and

Bulgaria that are in reach of these 2 organisations, while additionally a wider

coverage will be reached via direct contacts with representative organisations in the

UK and Greece.

Country Intervi

ewer

(Partn

er)

User group Organization Purpose of the

organization (short

description)

Belgium MCA Portal addressing

people with

disabilities,

researchers

AccessForAll.eu Portal highlighting

ICT initiatives

addressing the older

people, as well as

people with

disabilities

Belgium MCA People with

disability and its

stakeholders

EDF (European Disability

Forum)

Largest European

umbrella organisation

for stakeholders of

people with

disabilities

Bulgaria MCA Service providers /

Elderly/ People with

disability

Horizonti Foundation Organisation of the

disabled/elderly

people. They also

provide services for

these targets.


Elderly/People with

disability

http://www.bezmishka.org/ Web site hosted by

people with visual

impairments

Bulgaria MCA Service provider Department of IT under

Plovdiv University „Paisii

Hilendarski‟

ICT expert


Elderly/People with

disability

Rehabilitation Center for

people with visual

impairments

Organisation of the

disabled/elderly

people. They also


these targets.


Elderly/People with

disability

National association of

people with hearing and

visual impairments

Organisation of the

disabled/elderly

people. They also


these targets.

Bulgaria MCA Service providers Association „Integration Organisation of the

disabled/elderly

people. They also


these targets.

Bulgaria MCA Service providers Dignified Life Foundation Organisation of the

disabled/elderly

people. They also


these targets.


Elderly/People with

disability

Union of Blind People, Organisation of the

disabled/elderly

people. They also

provides services for

these targets.

Bulgaria MCA Service providers / Union of People with Organisation of the



Country Intervi

ewer

(Partn

er)


organization (short

description)

Elderly/People with

disability

Disabilities disabled/elderly

people. They also


these targets.

Bulgaria MCA Elderly/People with

disability

6 indivuals as end-users Individuals

Germany Netsco

uts

Elderly & People

with disabilities

Stiftung Digitale Chancen German Association

for People with

disabilities

Germany Netsco

uts

Developer Forschungsinstitut

Technologie und

Behinderung Volmarstein

German Association

for People with

disabilities

Germany Netsco

uts

Elderly & People

with disabilities

Sigmeta Webdevelopment,

Webdesign

Germany Netsco

uts

Service Provider Ercas Webdevelopment,

Webdesign

Germany Netsco

uts

Service Provider mediadesign teleakademie University of applied

sience

Germany Netsco

uts

Elderly & People

with disabilities

Bildungsanstalt für Blinde

und Sehbehinderte

Nürnberg

vocational education

for blind and visually

impaired people

Germany Netsco

uts

Elderly & People

with disabilities

Integrative Wohformen

Stuttgart

housing area for eldery

people

Germany Netsco

uts

Public Body Stadt Nürnberg

Amt für Existenzsicherung

und soziale Integration -

Sozialamt

social welfare office

Nuremberg

Germany Netsco

uts

Public Body Stadt Nürnberg

Presse- und

Informationsamt

Press office

Nuremberg

Germany Netsco

uts

Elderly & People

with disabilities

web for all occupational

integration of People

with disabilities

Germany Netsco

uts

Service Provider Zentrum für

selbstbestimmtes Leben

Erlangen

German Association

for People with

disabilities

Germany Netsco

uts

Service Provider Access German Association

for People with

disabilities

Germany Netsco

uts

Elderly & People

with disabilities

SeniorenNet Franken e.V. Internet community

for elderly people

Germany Netsco

uts

Elderly & People

with disabilities

Gib Gehörlosen Institut

Bayern

deaf and hearing

impaired people

Germany Netsco

uts

Accessibility

Assessor

ISL Interessenvertretung

Selbstbestimmt Leben e.

V.

self-regulating

community of People

with disabilities

Germany Netsco

uts

Accessibility

Assessor

Nürnberger Initiative für

die

Kommunikationswirtschaft

e.V.

Business community

Germany Netsco

uts

Service Provider Conrad Electronics SE Mail order firm for

Electrinic

Germany Netsco

uts

Elderly & Disabled

People

Verein für Menschen mit

Körperbehinderung

German Association

for disabled people

Germany Netsco Elderly & Disabled Boxdorfer Werkstatt sheltered workshop



Country Intervi

ewer

(Partn

er)


organization (short

description)

uts People

Germany Netsco

uts

Elderly & Disabled

People

Boxdorfer Wohanlage housing area for

disabled people

Germany Netsco

uts

Elderly & Disabled

People

K-Schule Nürnberg training of secial needs

for physically

handicapped people

Germany Netsco

uts

Elderly & Disabled

People

K-Schule Chemnitz training of secial needs

for physically

handicapped people

Germany Netsco

uts

Elderly & Disabled

People

Brufsbildungs für Blinde

und Sehbehindert

Chemnitz

vocational education

for blind and visually

impaired people

Germany Netsco

uts

Accessible Assessor Paritätidcher

Wohlfahrtsverband

umbrella organisation

Germany Netsco

uts

Developer Siemens A&D Siemens Industry

Automation and Drive

Technologies

Germany Netsco

uts

Public Body Bildiungszentrum der Stadt

Nürnberg

Germany Netsco

uts

Accessibility

Assessors

KfbI- Kompetenz

barrierefreies Internet

Community for

dissemination of

accessible webdesign

Greece MCA People with

disabilities

Disability Now (Athens,

Thessaloniki)

Representative

organisation for

people with

disabilities in Greece

Ireland Netsco

uts

Elderly & People

with disabilities

Central Remedial Clinic Provides a range of

specialised services

for children and adults

with physical

disabilities.

UK Netsco

uts

Elderly & People

with disabilities

Hereward College School for children

with disabilities

UK Netsco

uts

Elderly & People

with disabilities

The Home Farm Trust Ltd National charity and

supporting people with

learning disabilities

and their families.

UK MCA People with

disabilities

RNIB (Royal National

Institute of Blind People)

National charity and

supporting people with

vision impairments.

Table 4: Contacts of Netscouts and MCA with end-users (organisations and individuals)

In addition to the abovementioned groups, both organisations as well as other

ACCESSIBLE beneficiaries equally have good contacts with European players such

as EASPD (European Association of Service Providers for People with Disabilities)

and AGE platform.

3.4 User Questionnaires and Interviews

3.4.1 Methodological Structure – A Theoretical Approach

It is the objective of the project to create an assessment environment which enables a

heterogeneous group of IT users and developers to develop an accessible environment



as well as to be able to use such environment in an accessible manner. To this end and

within the scope of this project‟s field research we developed questionnaires with the

aim of identifying the specific needs and requirements which a heterogeneous group

of IT users, IT developers and lobbyists expects from accessible programming and use

of multimedia-based terminals. The evaluation of such questionnaires shall contribute

to the user needs and requirements definition.

The first step towards a user analysis was the design of a target definition based on the

pivotal question:

How can we support developers so that they can write accessible application

programmes?

General objective: Development of an assessment simulation environment in

which tools that enable, facilitate and test accessible programming are

incorporated; long-term: Design of a harmonized (ontology-based) methodology

for accessibility.

Special objective: Identification of user requirements; main users are developers,

designers, service providers, accessibility experts, producers/supporters of

accessibility in addition to elderly and disabled people, government agencies,

public bodies, etc.

In order to obtain adequate information on actual user needs and user behaviour, this

survey has been based on the classical methods of empirical social research,

especially on the methods of User Centred Designs such as structured and semi-

structured user questionnaires.

Structured questionnaires have the great advantage that a huge number of people can

be consulted and the costs of the realisation and analysis are low, especially by using

closed questions. Furthermore, it‟s easy to draw comparisons and generalisations and

the criteria of objectivity and reliability can approximately be fulfilled. The

disadvantage of this method primarily lies in the fact that the interviewees are

obligated to answer the given questions with the already given possible answers – the

criterion of validity need not be assured. Using this method the researcher who is

going to evaluate the system must already know the system quite well. His huge effort

is to formulate the right questions and choices of answers.

In the case of the evaluation of ACCESSIBLE it is intended to use an offline in

addition to an online questionnaire as via the Internet it is quite easy to disseminate

the questionnaire amongst the European-wide-spread test group and to collect its

results. Also the ACCESSIBLE participants translated the questionnaires in seven

languages, namely Czech, English, French, German, Greek, Portuguese and Italian

based on ACCESSIBLE participant‟s languages (the questionnaires are included to

the Annex I of this deliverable).

Subsequently, the questionnaires were designed on the basis of discussing the

following topics:

Contents: Which questions must be raised; which information must be gathered?

Scope: Which scope (number of questions) is reasonable?

Time and procedure: How much time do we have for the survey? How is the

survey done – in writing or verbally, by post or e-mail?



Target group: Are the target groups, the sample known? Who provides access to

the sample? How large is the known sample?

Sequence: How are the questions ordered, e.g. demographic questions at the

beginning or at the end?

Item formulation

Types of questions

Variety of questions

Open-ended questions

Close-ended questions

Matrix

Dichotomy

Demographic questions

Question tendencies/control questions

Comments

Pre-test: Pretesting is essential in order to gauge acceptance and validity. Which

possibilities do we have?

Marketing/Approach: Who publishes/how is the questionnaire being published?

How can the samples be approached and motivated?

Instructions for interview partners: Who conducts the interviews? Phrasing of

concrete instructions and explanations for the interviewee.

Cover letter/e-mail

Feedback

The aforementioned was the basis for the development of five standardized

questionnaires in order to determine special user needs. With a view to the statistical

analysis, the questionnaires contain close-ended as well as hybrid questions. Hybrid

questions are necessary to complete incomplete item lists.

Questionnaire categories that have been selected by ACCESSIBLE were:

Demographic data: Required to identify significant connections between age

and IT needs. Such can especially matter with elderly and disabled users.

Comprehension of accessibility: Required to develop ontology and identify

similarities and differences within the EU.

Working with accessibility: Required to collect information on existing

know how and on the willingness to a steady learning of the topic; it is

assumed that experience with this topic correlates with the user requirements

for an assessment tool.

Expectation of accessibility: Required to identify user needs which the user

himself/herself might not be aware of.

Information on employment: Required to create correlation between work

situations, e.g. teamwork, decision authority and user needs. In this category



the following can be determined: Point in time when accessibility was

introduced as practice in the development; and the specific development

stage where problems arose.

Information on user behaviour on the internet and the PC: Relevant for a

possible market analysis on already existing accessibility of web presence,

software, etc.

Assessment tool: Direct survey of user needs.

In order to meet classification specifications (completeness, exclusivity, unambiguity)

we had to present the questions as a matrix as well as in lists with dichotomous and

multiple response options. It was also necessary to use hybrid questions in addition to

close-ended questions if we had to assume that the answer categories were incomplete

or if we had to be considerate of national circumstances. We included a “Don‟t

Know” category for all questions in order to minimize potential uncertainties by the

interviewee as well as to reduce the amount of missing values during statistical

evaluation.

We used open-ended questions if the interviewee was to have the opportunity to

provide personal details. In general it was impractical to apply standardized scales of

measurement for all questions. We developed mainly nominal-scaled questions but

ordinal-scaled questions were also integrated. These survey personal opinions and

requirements. The questionnaire is available online through the ACCESSIBLE project

Web site (following figures 3, 4), in the official language of each project partner.



Figure 3: ACCESSIBLE online questionnaire



Figure 4: ACCESSIBLE online questions

As we are dealing with heterogeneous target groups it is important to choose the

appropriate survey form. A mere online survey, without an interviewer, is to be

recommended if members of a special population are surveyed who are familiar with

methods and material and subsequently use the same. At the same time, interviewer

mistakes are being avoided.

Online surveys as well as face-to-face surveys should be implemented if it can be

expected that only interviewers can reach members of the sample who otherwise

cannot be reached. It can, for example, be expected that the target groups “Service

Provider”, “Accessibility Assessors” and “Public Bodies” have only limited

possibility to participate in an online survey (restrictions of internet access at the

workplace).

Personal interviews are recommended if one can assume that the presence of an

interviewer motivates the target group to participate in the survey. Personal interviews

provide room for asking questions and for clarifying ambiguities and uncertainness.

At the same time, the interviewee feels that their participation is essential for the

result of the research.

For the interviews implementation it has been agreed between the consortium the

following:

Developers: online and face-to-face through contacts of ACCESSIBLE

beneficiaries.



Service Providers: online and face-to-face through contacts of ACCESSIBLE

beneficiaries.

Public Bodies: online and face-to-face.

Accessibility Assessors: online and face-to-face.

Elderly and People with Disabilities: face-to-face and in some cases online (if

they are familiar with ICT).

3.5 Analysis of Questionnaires and interviews

To enable the capturing of the user requirements, both from developers and end-users,

a survey took place from April 2009 through July 2009. This was undertaken via face-

to-face interviews, as well as through online questionnaires in 7 countries (Bulgaria,

Czech Republic, Germany, Greece, Italy, Portugal, and the United Kingdom).

Developers, service providers, public bodies/governmental agencies and accessibility

assessors were mostly surveyed online, while interviews with elderly and disabled

users were mainly undertaken face-to-face.

The project decided that, while the online survey and user requirements extraction has

been completed, the survey itself will be kept online to allow for the collection of

further data in order to enlarge the representative character of the random sampling.

In the following sections, we aim to first give a short overview of the basic collected

data, where and how many individuals were surveyed. Also a detailed overview of the

actual user groups and what they consist of, what their background is included.

The survey goes deeper into the needs of each user group as they were reported

through the survey via a qualitative and quantitative evaluation of the survey data.



3.6 Overview collected data

The survey focused on all participating partner countries, and the partnership agreed

to pinpoint specific user groups to be targeted in the various countries (see Table 5).

Partner Location Accessibility

Assessors

Developers Service

Providers

Elderly /

Disabled

Users

Public Bodies /

Governmental

Agencies

CERTH GR X X X

FORTH- ICS GR X X

SUN CZ X X

USTUTT GER X X

FFCUL POR X X X

SOFTECO IT X X X

NETSCOUTS GER X X X

MCA BUL X X

CS CH X X

SOLINET GER X

- Other

countries X X X X X

Table 5: Questionnaire dissemination per partner by country

A total of 408 individuals were interviewed (see Table 6 for an overview of the

number of surveyed individuals per user group).

User group Number interviewed individuals

Accessibility Assessors 38

Developers 254

Elderly and Disabled Users 67

Public Bodies/Governmental Agencies 18

Service Providers 31

Total 408

Table 6: Individuals surveyed by country

An analysis of the gender distribution (see Table 7) indicates that 76,2% of the

random sample were male. This thus confirms recent findings of a European study

that indicated females represent less than 25 percent of all computing graduates in the

EU-275. The same study revealed that in the ICT sector, only 27.8 percent of

computer and information systems managers are women, and among computer

hardware engineers, a mere 9.6 percent are female. Also, only 5.8 percent of senior

academic positions in engineering and technology fields are held by women. This is

hardly any different for the accessibility ICT sector which equally still remains largely

dominated by men.

5 A. Gras-Velazquez, A. Joyce & M. Debry, White Paper “Women and ICT, Why are girls still not

attracted to ICT studies and careers?”, June 2009, CISCO.



User Group Gender Total

No Response Male Female

Accessibility Assessors 3 24 11 38

Developers 0 219 35 254

Elderly and Disabled

Users

0 39 28 67

Public

Bodies/Governmental

Agencies

1 11 6 18

Service Providers 0 18 13 31

Total 4 311 93 408

Table 7: Gender distribution per user group



3.7 User Group Analysis

For this survey, 5 main target groups were identified:

Developers (software developers and designers) that will use ACCESSIBLE

as a supportive tool for the development and testing of accessible software

applications;

Accessibility Assessors who are involved in assessing existing software

solutions, and the accessibility of its user interfaces;

Public Bodies/Governmental Agencies who are involved in policy making

and provide the basis for future policies;

Service Providers (public and private enterprises and organisations

responsible for the content and graphic layout of Web products) who set

(commercial) objectives and are key decision makers in web accessibility

development;

Elderly and Disabled Users who benefit from enhanced accessibility and are

teh actual end-users of all developed solutions.

These user groups were detailed in an internal report “Project user groups”,

addressing as such the milestone for Month 3 (November 2008), “Definition of

project User Groups (internal report will be prepared)”.

3.7.1 Developers Group

A total of 254 developers were surveyed (219 men and 35 women), between 21 and

66 years of age. The random sampling reflects a high percentage of 20-30 year olds,

with a marginal ratio of women.

,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

Perc

en

t

- 19 Years 20 - 29

Years

30 - 39

Years

40 - 49

Years

50 - 59

Years

60 Years

And Older

Age

Age Distribution - Developers Group

Figure 5: Age distribution - developers group

In order to determine the extent of their familiarity with the “accessibility” aspect,

introductory questions focused on their awareness of accessibility, as well as their



engagement in this area. Over 90% of the interviewed individuals were acquainted

with accessibility and its related concepts such as usability. As can be seen in Figure

6, in all countries where developers have been interviewed, their engagement in

accessibility related activities is high.

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

Perc

en

t

Czech

Republic

Germany Greece Italy Portugal United

Kingdom

Country

Accessibility Engagement per Country - Developers Group

Yes

No

No Answ er

Figure 6: Accessibility engagement per country

The interviewed directors of software divisions and developers overall associated

accessibility with website (almost 85%) and devices (almost 70%) accessibility. The

meaning of accessibility for students is more heterogeneous than for individuals

having an employment position. Students connect accessibility mainly to design for

all (almost 90%) and platform independence (almost 50%). Obviously this

discrepancy is linked to the professional tasks developers and directors undertake on a

daily basis, while students get faced with accessibility in a rather general manner.

More than half of the surveyed developers (63%) indicated that they are already

engaged in the area of accessibility and are interested in additional advanced training

and education on this topic. Developers do distinguish themselves from all other

participants groups through their high level of engagement in furthering their

accessibility knowledge.

As can be expected, developers stay mostly informed on the subject of accessibility

through online media (see Table 8).

Methods of keeping up to date Percentage

Online (weblogs, online communities (user forums, mailinglists)) 91%

Printed magazines (such as scientific articles) 11%

Table 8: Methods of keeping up to date - developers group



3.7.2 Accessibility Assessors Group

Accessibility Assessors refers to an occupational group which advocates the needs of

elderly and disabled individuals. Such could be an individual, e.g. a company

representative for the disabled, or an organization which supports the disabled. The

online questionnaire was completed by 37 individuals (24 men and 11 women),

between 23 and 54 years of age (see Figure 7).

,0

5,0

10,0

15,0

20,0

25,0

30,0

35,0

40,0

Perc

en

t

20 - 29 Years 30 - 39 Years 40 - 49 Years 50 - 59 Years

Age

Age Distribtution - Accessibility Assessors Group

Figure 7: Age distribution- accessibility assessors group

As the accessibility assessors group does not correspond to a specific occupational

group, the professional backgrounds of the individuals surveyed are distributed over a

broad spectrum, from peer counsellors6 to university professors. Most (81%) have up

to 12 years of work experience, and 9 of those surveyed have a disability (mobility

and visual impairment). 11 individuals (among which are the 9 people with

disabilities) are members of an organization for disabled individuals.

They all have in common that their understanding of accessibility and usability

extends over a broad range. More than half of those surveyed connected the

accessibility concept with website, building constructions, and design for all aspects.

6 Personal counselling and support services provided by disabled individuals for disabled individuals.



0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

Perc

en

t

Websites Buildings Design for All Platform

Independent

Accessibility

Traffic

Accessibility Associations

Distribution of Associations concerning Accessibility - Accessibility

Assessors Group

Yes

No Answ er

Figure 8: Distribution of associations concerning accessibility - accessibility assessors group

Accessibility assessors stay mostly informed on the subject of accessibility for online

media is preferably used to keep up-to-date on accessibility issues, such as website

accessibility or accessible software (see table below).




Table 9: Methods of keeping up to date - accessibility assessors group

Assessors are primarily highly motivated, and show ongoing interest and support for

the needs of disabled individuals. Their “controlling” approach towards i.e. inspecting

and testing the access to buildings and transportation, but also digital media makes

them also a very demanding user group. Many of these assessors are also avid

advocators in the local disability communities.

3.7.3 Public Bodies/Governmental Agencies Group

A total of 18 public servants and officials (aged 28 to 60, and 11 of them men) were

surveyed (see Figure 9).



,0

5,0

10,0

15,0

20,0

25,0

30,0

35,0

40,0

45,0

50,0

Perc

en

t

20 - 29 Years 30 - 39 Years 40 - 49 Years 50 - 59 Years 60 Years And

Older

Age

Age Distribution - Public Bodies/Governmental Agencies Group

Figure 9: Age distribution – public bodies/governmental agencies group

They work for public bodies and governmental agencies and corporations, such as

public utility companies. While this sample is rather small, due in part to the difficulty

in accessing the target group through the required official channels, it must be noted

that accessibility of the services provided by public bodies and governmental agencies

is usually subject to European and national regulation7. This means that obligations

exist to make services such as websites, downloadable documents or online forms

accessible to all members of the general public. The individuals surveyed were all

familiar with this aspect of accessibility, while over 75% also associated accessibility

also with making building constructions accessible.

As shown in Figure 10 and Figure 11, this group shows also a pronounced interest in

advanced training and education in the field of web and mobile accessibility.

7 Council Resolution of 25 March 2002 on the eEurope Action Plan 2002: accessibility of public

websites and their content (2002/C 86/02), and European Parliament resolution on the Commission

communication eEurope 2002: Accessibility of Public Web Sites and their Content (COM(2001) 529 -

C5-0074/2002 - 2002/2032(COS))



Interest in Learning More about Web Accessibility - Public

Bodies/Governmental Agencies Group

No Answer

Yes

Figure 10: Interest in learning more about web accessibility - public bodies/governmental agencies

group

These public servants were as such also very eager to stay informed on the subject of

accessibility. The way however they expect to do this is rather in a traditional and less

pro-active manner, namely through workshops (almost 50%) and internal information

(see table below). This is linked to the stringent way in which often local accessibility

standards are prescribed and must be applied (see Table 10).


Workshops 56%

Internal information (internal newsletters and meetings) 33%



Table 10: Methods of keeping up to date - accessibility assessors group

Interest in Learning More about Mobile Accessibility - Public


No Answer

Yes

Figure 11: Interest in learning more about mobile accessibility - public bodies/governmental agencies

group



3.7.4 Service Providers Group

A total of 41 individuals (of which 24 men) between 24 and 60 years of age (see

Figure 12) were surveyed. They were primarily employed in the field of accessible

website design and consulting, and mainly (over 90%) work in SMEs. 14 (34%) of the

individuals surveyed have a disability.

Because of the very nature of the employment environment of all surveyed

individuals, all were familiar with the aspect of accessibility in its various application

areas, but with main focus on accessible internet and desktop applications.

,0

5,0

10,0

15,0

20,0

25,0

30,0

35,0

40,0

45,0

Perc

en

t

20 - 29 Years 30 - 39 Years 40 - 49 Years 50 - 59 Years 60 And Older

Age

Age Distribution - Service Provider Group

Figure 12: Age distribution - service provider group

Just like the developers, the service provider group is eager to learn more on

accessibility, and does so in a pro-active manner, namely through workshops online

information (over 75%) and to a less extent via printed media and internal information

channels (see Table 11).



Internal information (internal newsletters and meetings) 22%


Table 11: Methods of keeping up to date – service provided group



3.7.5 Elderly and Disabled Users Group

A total of 67 individuals (older people and people with disabilities) were surveyed (39

men and 28 women) between 19 and 75 years of age (see Figure 13).

Of this group, over 75% indicated they had a disability (see Figure 14).

,0

5,0

10,0

15,0

20,0

25,0

Perc

en

t

- 19 Years 20 - 29

Years

30 - 39

Years

40 - 49

Years

50 - 59

Years

60 - 69

Years

70 Years

And Older

Age

Age Distribution - Elderly and Disabled People Group

Figure 13: Age distribution - elderly and disabled people group

Disability Distribution-Elderly and Disabled Users Group

No Answer

No

Yes

Figure 14: Disability distribution - elderly and disabled people group

As is shown in below graphic, disability occurred in almost all age categories, apart

from the 70+ years group. All individuals 30 years of age indicated that they are

disabled as did all individuals surveyed in the 40 - 49 age category. 91,7% of those



individuals surveyed in the 30 -39 age bracket indicated that they are disabled as did

84,6% in the 50 - 59 age bracket and 60% in the 60 – 69 age bracket.

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%P

erc

en

t

- 19

Years

20 - 29

Years

30 - 39

Years

40 - 49

Years

50 - 59

Years

60 - 69

Years

70 Years

And

Older

Age

Disability Distribution by Age- Elderly and Disabled User Group

Impairment Yes

Impairment No

No Answ er

Figure 15: Disability distribution by age - elderly and disabled people group

The surveyed elderly and disabled individuals were characterized by a high level of

interest in new technologies. Over 50% of the participants had one of following

devices: computer (PC and/or laptop), mobile phone, or a PDA/Handheld. However,

over 60% state that they have substantial accessibility problems and access difficulties

exist which impede full usage.



3.8 Qualitative and Quantitative Evaluation of the Survey Data

While previous sections provided an overall introduction to the various participating

user groups, this section will look closer into each user group, reporting on the various

findings regarding their perception of accessibility, their usage of accessibility

guidelines, the problems they face in doing so, etc. This section provides the basis for

extracting the specific user requirements in section 3.9, while section 4 extracts from

these user requirements the technical requirements.

3.8.1 Developers

254 developers participated in the survey. 25% were directors of a software division,

while 65% were developers, and the rest either assistants or students.

Around 30% of all those surveyed were acquainted with individuals who have a

disability, either in the private (80%) or professional (20%) sphere. Of these 30%,

48% indicated it did affect their daily work. These 48% also belonged to the group of

developers that were already involved in accessibility related projects. Overall

however, the survey also pointed out that developers have limited knowledge of what

the actual impact is of (combined) disabilities on accessibility, nor had they full

knowledge of functional limitations, and assistive devices that were available and

being used.

3.8.1.0 Accessibility

Over 90% of the interviewed individuals were acquainted with accessibility and its

related concepts such as usability. ICT, access to websites and end user devices were

mostly associated with the term “Accessibility”. The interviewed directors of software

divisions and developers overall associated accessibility with website (almost 85%)

and devices (almost 70%) accessibility. The meaning of accessibility for those

developers that were still students is more heterogeneous than for individuals having

an employment position. Students connect accessibility mainly to design for all

(almost 90%) and platform independence (almost 50%). Obviously this discrepancy is

linked to the professional tasks developers and directors undertake on a daily basis,

while students get faced with accessibility in a rather general manner.

With regards to further education (see Figure 16), 85% indicated a need for advanced

education in the area of accessibility.



,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

Perc

en

t

Web

Accessibility

Mobile

Accessibility

Devices Assistive

Devices

Accessbility

Standards

Legislation

Interests

Interests in Further Education - Developers Group

Yes

No

No Answ er

Figure 16: Interests in further education - developers group

58% of the interviewees deemed this necessary for web and mobile accessibility

(respectively 40% and 45%), (assistive) devices (32%) and accessibility standards

(10%). Under others, accessible user interface aspects were mentioned by over 50%

of the respondents. This seems to indicate that while accessible user interface

implementation are desired by both developers (over 45%) and directors (over 50%),

it is not embedded as such in the usual working load at present. The preferred type of

advanced training and education was by working in project groups (Learning by

Doing) (67%), by participating in dedicated workshops (53%) and online training

(34%) ranked thereafter.

This need for advanced education corresponds to the rather low awareness of national

and international guidelines and standards regarding accessibility as shown in Table

12.

Guidelines, standards Familiarity of students Familiarity of directors,

developers

WAI-ARIA Rich Applications 15% 65%

Web Content Accessibility

Guidelines 1.0 (WCAG 1.0)

65% 87%

Web Content Accessibility

Guidelines 2.0 (WCAG 2.0)

10% 45%

Section 508 4% 39%

Authoring Tool Accessibility

Guidelines (ATAG)

0% 7%

Table 12: Familiarity with standards and guidelines – developers group



There are many standards and guidelines available, both national guidelines and

international standards. However, this availability of multiple standards and

guidelines seems also to have resulted in a low familiarity, especially among surveyed

students. The directors and developers are more aware about the standards and

guidelines, obviously because of their professional usage. National accessibility

guidelines were mostly unknown to any of the respondents.

It must be highlighted here that for those that are being aware of standards, does not

mean they actually know the standards and can implement this. This was rather

bluntly put by one interviewee who stated:

“ ... do have a shelf of books on WCAG 1.0 and 2.0 issues, but hardly any of

us uses it as we lack the time. What we all seek for is an embedded validator in

our day to day developing tools such as Microsoft Visual Studio, Visual Basic

.NET, Bluefish, Eclipse and Anjuta ...”

Nevertheless, there is an overall desire (55%) to be able to implement and incorporate

WCAG 2.0.

Some developers indicated that their knowledge of standards about mobile, Web

services and SDL were in fact rather poor.

3.8.1.1 Job and Professional Knowledge

A majority of the developers (53%) work in SME companies having up to 100

employees. Some of the respondents indicated that this allows for a rather flexible

decision making hierarchy with regards to whether implement or not accessibility

features and to what extent. However, as was found earlier, few education currently is

made available within those companies, nor do the developers have access to the

appropriate tools to do so.

Following programming / scripting languages were mainly used: Java (63%), C/C++

(80%), PHP (69%), ASP (57%), and C# (25%) and Perl (15%). This ranking does

follow similar rankings such as the TIOBE Programming Community Index8 and

Langpop.com9.

With over 60%, XML is the preferred structural mark-up language, compared to 30%

for UML.

Asked what kind of operating system they prefer to develop for, a majority indicated

Microsoft (47%), then Linux (35%), and Mac OS (5%). In the face to face interviews,

developers did indicate that developing for Linux was more done in their spare time at

home, while at work they often needed to follow the wishes of the customer.

Integrated Development Environment (IDE) such as Netbeans and Eclipse do support

accessibility, for example, in the form of code assistants. However, of the 45% that

did use IDEs, 42% of those surveyed did not know if the IDE application supported

accessibility. This can be explained by the fact that only 63% of those surveyed are

presently or had in the past participated in accessibility oriented projects.

8 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

9 http://langpop.com/



3.8.1.2 Accessible Specific

The 63% of those surveyed that presently or had in the past participated in

accessibility oriented projects, were asked how (with what tools) they prefer to

evaluate their implementations with regards to accessibility. The same was done for

assistive technologies (AT) usage to assess accessibility.

Tools to evaluate implementations Percentage

HTML assessment validator (e.g. WAVE, Hera) 45%

Color contrast tool (e.g. Colour Contrast Analyzer,

Accessibility Color Wheel)

15%

CSS validator tool (e.g. W3C CSS Validation

Service)

72%

Simulation tools (e.g. IBM aDesigner tool) 53%

AT to evaluate implementations Percentage

Screen reader 7%

Braille embossers 0%

Keyboard filters 3%

Screen magnifier 12%

Table 13: Usage of accessibility evaluation and AT tools – developers group

All developers (so also those that never worked on accessibility related projects) were

asked which tools/methodologies they would be interested in. Below is a table that

provides the percentage of those developers that have and those that haven‟t worked

in accessibility related projects before.

Tools to evaluate

implementations

Percentage (no

past accessibility

projects

experience)

Percentage (past

accessibility

projects

experience)

Percentage (total)

Accessibility Assessment tools

(e.g. aChecker, Hera, TAW)

34% 57% 48%

Accessibility Simulation tools

(e.g. aDesigner, Visual

Impairment Simulator)

64% 73% 70%

Accessibility Authoring tools

(e.g. Adobe Dreamweaver,

Microsoft Visual Studio)

50% 82% 70%

Manuals for creating accessible

content

10% 35% 26%

Simulators of Assistive

Technology (e.g. Screenreader,

Zoom software, Simulators of

head-mice)

41% 92% 73%

International guidelines 32% 41% 38%

Results of research activities on

accessibility

12% 26% 21%



Tools to evaluate

implementations

Percentage (no

past accessibility

projects

experience)

Percentage (past

accessibility

projects

experience)

Percentage (total)

Invitations to events about

accessibility issues

32% 58% 48%

Database with persons who have

experience in the field of

accessibility (specialists/experts)

7% 17% 13%

Table 14: Desired usage of accessibility evaluation tools – developers group

The outcomes are striking. Both groups have a more or less same desire with regards

to certain tools. Most preferred accessibility evaluation tools are (higher than 50%):

Accessibility Simulation tools (e.g. aDesigner, Visual Impairment Simulator)

Accessibility Authoring tools (e.g. Adobe Dreamweaver, Microsoft Visual

Studio)

Simulators of Assistive Technology (e.g. Screenreader, Zoom software,

Simulators of head-mice)

To a less extent, but still significant (higher than 30%):

Accessibility Assessment tools (e.g. aChecker, Hera, TAW)

International guidelines

Invitations to events about accessibility issues

These findings, as well as the feedback received does clearly indicate that developers

want to have accessibility support at the very beginning, so before they actually have

developed their software of website pages. This was explained as following by a

developer who had not worked yet on accessibility projects:

“In the following months we will be forced to ensure all our current developed

and maintained websites and some desktop tools for the public sector are

accessible. It will be a nightmare ... we will need to individually adjust sites,

while if we had considered this at the very beginning, we would avoid such

overhead. Now we will depend on various assessment tools, while double-

checking with a local end-user group (of people with disabilities) … To avoid

such overheads at a late stage, it is needed to introduce accessibility within the

software design process and not only in the post-development process, while

we should be provided access to best practices examples...”

Asked how accessibility simulation/validation tools should be provided, over 40%

indicated these tools should be available online or be downloadable (see Figure 17).



,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

Perc

en

t

Download Online DVD

Availability

Availability of an Accessibility Assessment Tool - Developers Group

Yes

No

No Answ er

Figure 17: Availability of an accessibility assessment tool – developers group

3.8.1.3 Summary

The developers are with a proportion of 62% the largest user group in the survey, and

also expressed in most detail what their concerns were with regards to accessibility.

The main findings for them are the following:

Accessibility is an aspect that developers are familiar with, and it is mostly

associated with web and end user device accessibility. A minority was directly

in touch with people with disabilities, and also reported that this did affect

their daily work. Overall however, developers need more knowledge about

(combined) disabilities and functional limitations, assistive devices.

A majority indicated a need for advanced education in the area of accessibility,

especially then for web and mobile accessibility, accessible user interface

aspects and (assistive) devices. The preferred type of advanced training and

education was by working in project groups, by participating in dedicated

workshops and online training. Also, the availability of best practices

examples was desired.

There is awareness about accessibility standards and guidelines, however this

is more in a passive format. There was indication they wanted embedded

validators in the development tools. Some developers indicated that their

knowledge of standards about mobile, Web services and SDL are rather poor.

The following programming/scripting languages were mainly used: Java,

C/C++, PHP and ASP, with XML being the preferred structural mark-up

language.

The operating system they prefer to develop for is mainly Microsoft and then

Linux.



Integrated Development Environment (IDE) are used by almost half, however

few are aware of any embedded accessibility features.

Regarding the preference for accessibility evaluation tools, accessibility

simulation and authoring tools were much preferred, together with simulators

of assistive technology. Still significantly wanted were the accessibility

assessment tools.

There was a clear preference to provide accessibility simulation/validation

tools online or as download.

There is a desire to be able to implement and incorporate WCAG 2.0.

It is really important to introduce accessibility within the software design

process, and not only in the development process.

3.8.2 Accessibility Assessors

The online questionnaire was completed by 37 individuals (24 men and 11 women),

between 23 and 54 years of age.


The concepts “Usability” and “Accessibility” were known to almost all those

surveyed (as was already reported on in Figure 8). More than half of those surveyed

connected the accessibility concept with website, building constructions, and design

for all aspects. This knowledge is not surprising keeping into account that most of

these individuals are daily active in the advocacy area towards full accessibility in

every aspect of life.

Those surveyed indicated a rather high awareness level of various accessibility

standards and guidelines.

Guidelines, standards Familiarity

WAI-ARIA Rich Applications 46%

Web Content Accessibility Guidelines 1.0 (WCAG 1.0) 81%


Section 508 3%

Authoring Tool Accessibility Guidelines (ATAG) 3%

Table 15: Familiarity with standards and guidelines – accessibility assessors group

These guidelines were mainly connected to the assessment of web accessibility (81%)

and desktop software (41%). To a less extent this was related to consumer electronics

(27%) and overall documentation (14%).

During face-to-face interviews, those assessors mostly involved in user interface

accessibility aspects indicated that especially WCAG 1.0 forms the basis when they

start assessing user interfaces. Such guidelines were primarily used in assessing intra-

networks and public websites, while they also more intensively used AT to test the

accessibility of online services. Mostly priority 2 levels have to be met, albeit that

some surveyed individuals indicated that priority 3 should be the absolute minimum if

full accessibility was to be ensured. While 81% used WCAG 1.0, only half of them

will switch to WCAG 2.0. This is mostly due to the national guidelines that mostly

are based on a subset of WCAG 1.0.



In terms of being kept updated on accessibility issues, following results were gathered

(only results of the 30 assessors involved in the accessibility of web, desktop and

consumer applications are shown):

Channels to be kept up-to-date Percentage

Print media 33%

Online research 90%

Continuing education 57%

Internal information, for example internal newsletter, meetings

etc.

40%

Conferences/workshops/seminars 30%

Service Provider, Software companies 3%

Not at all 0%

Table 16: Keeping up-to-date on accessibility issues – accessibility assessors group

There is obviously a preference for online access to information, while more than half

were interested in continued education on the accessibility topic.


The 30 individuals who indicated they were involved in the accessibility assessment

of web, desktop and consumer applications, were also asked how (with what tools)

they prefer to evaluate implementations with regards to accessibility. The same was

done for assistive technologies (AT) usage to assess accessibility as is shown in Table

17.





57%


Service)

73%



Screen reader 23%


Keyboard filters 7%


Table 17: Usage of accessibility evaluation and AT tools – accessibility assessors

It must be noted here that the 9 persons that had a disability were also the ones using

the AT to evaluate implementations. These were screen readers (7), alternative

keyboard (1), trackball (1), Braille printer (7) and a magnifier (7). The others mainly

relied on tools to evaluate the implementations they assess, mainly relying on

validators and simulators.



The 30 individuals who indicated they were involved in the accessibility assessment

of web, desktop and consumer applications, were equally asked which

tools/methodologies they would be interested in (see Table 18).

Tools to evaluate implementations Percentage (individuals who indicated they were

involved in the accessibility assessment of web,

desktop and consumer applications)

Accessibility Assessment tools (e.g. aChecker,

Hera, TAW)

43%

Accessibility Simulation tools (e.g. aDesigner,

Visual Impairment Simulator)

77%

Accessibility Authoring tools (e.g. Adobe

Dreamweaver, Microsoft Visual Studio)

13%

Manuals for creating accessible content 57%

Simulators of Assistive Technology (e.g.

Screenreader, Zoom software, Simulators of

head-mice)

90%

International guidelines 10%

Results of research activities on accessibility 23%

Invitations to events about accessibility issues 63%

Database with persons who have experience in

the field of accessibility (specialists/experts)

37%

Table 18: Desired usage of accessibility evaluation tools – accessibility assessors group

The outcomes are pointing out here that there is a strong preference for following

tools (higher than 50%):


Manuals for creating accessible content



Invitations to events about accessibility issues

The above results do need some further clarification. Accessibility assessors are not so

much people with a technical background, thus also the less interest in authoring

tools. However, their high interest in simulation tools fits clearly with their role of

assessing available interfaces. Equality, and since they are advocates of design for all,

their interest in attending events and “spreading the word” is quite obvious.

To a less extent, but still significant (higher than 30%), following evaluation tools

were also selected:


Database with persons who have experience in the field of accessibility

(specialists/experts)

The database of people who have experience in the field of accessibility, but then on a

national level, is a much sought after tool by many advocacy organisations. One

interviewee commented:

“They are out there, having all the necessary knowledge ... but we do not get

hold of them or find them ...”



Most assessors (83%) were aware that increasingly public bodies need to have

accessibility certifications (following mainly national guidelines, so in fact subsets in

most cases of W3C WAI-AAA and W3C CSS), while 53% of them had already

followed an assessment that resulted in such a certificate being awarded.

3.8.2.2 Summary

The accessibility assessors user group can be described as a group of advocators that

intervene in all areas of society in order to advance equal living conditions for all

disabled individuals. Their working positions as well as their engagement in

organizations for disabled individuals offer interfaces which in many instances affect

handicapped individuals. The main findings that were collected from the survey are

the following:

They have a rather high awareness level of various accessibility standards and

guidelines, especially WCAG 1.0 since they often use a subset of it in the

national guidelines.

They are mainly active in assessment of accessibility of web and desktop

applications.

There is a preference for online access to information to be kept up-to-date on

accessibility issues.

Validators and simulation tools are mainly used to evaluate implementations,

while there is strong interest in using accessibility simulation tools, and

simulators of AT. Equally, manuals for creating accessible content and

invitations to events about accessibility issues are of interest. The latter

obviously as this is directly related with their role of accessibility advocators.

To a less extent, also accessibility assessment tools and a database with

persons who have experience in the field of accessibility would be used.

Increasingly public bodies need to have accessibility certifications (based on

or subsets of W3C WAI-AAA and W3C CSS guidelines).

3.8.3 Public Bodies

A total of 18 individuals completed the questionnaire. They work for public bodies

and governmental agencies and corporations, such as public utility companies. Half of

the surveyed indicated that they supervise programming tasks within public agencies.

The other half is mainly positioned on a managerial level.


A majority of the surveyed individuals (94%) is familiar with and also understands the

accessibility and usability concept (see Figure 18), while 89% dealt with accessibility

before.



,0 10,0 20,0 30,0 40,0 50,0 60,0 70,0 80,0 90,0 100,0

Percent

Usability

Accessibility

Term

s

Knowledge of the Terms "Usability" and "Accessibility"- Public


No Answ er

Yes

Figure 18: Knowledge of the terms “usability” and “accessibility” – public bodies/governmental

agencies group

It must be noted here that increasingly public bodies face accessibility issues, whether

in employment, access to public buildings or the access to eGovernment services.

This is often regulated nationally, based on EC directives10

.

Asked what the reasons are why these individuals had to deal with accessibility, all

pointed out that it has been a requirement from their employer, while directly linked

to that, all pointed out that it is also demanded by public policies and/or

recommendations (see Table 19).

Reasons of dealing with accessibility Percentage (of the 89% that dealt with

accessibility before)

It was a project requirement (e.g. User needs) 75% It was a requirement of the employer 100% Due to a work-related advanced training 44% Due to private interest 19% Due to public policies or recommendations (e.g.

incorporate accessibility in all public Web sites)

100%

Other 0% Table 19: Reasons of dealing with accessibility – public bodies/governmental agencies group

10

E.g. Communication of the Commission of 30 July 1996 on “equality of opportunity for people with

disabilities: A New European Community Disability Strategy”; Commission Communication «

eEurope 2002: Accessibility of Public Web Sites and their content » (25 September 2001); Council

Resolution on "eAccessibility" – improving the access of people with disabilities to the Knowledge

Based Society (January 2003); Directive 2002/22/EC of the European Parliament and the Council of 7

March 2002 on universal service and user's rights relating to electronic communications networks and

services (Universal Service Directive). OJ L 108, 24.4.2002, p. 51



Although 94% was really aware of what accessibility and usability stand for, 100% of

those surveyed did relate accessibility to the access of websites, 83% to the

accessibility of buildings and just over 60% to that of public transport (see Figure 19).

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

Perc

en

t

Websites Buildings Accessible

for All

Platform

Independent

Accessible

Traffic

Meaning

Meaning of Accessibility - Public Bodies/Governmental Agencies Group

Yes

No Answ er

Figure 19: Meaning of accessibility - public bodies/governmental agencies group

The majority of those surveyed also keep themselves informed regarding accessibility

via online resources, books and internal information (often provided via internal

workshops to which external experts are invited to provide the needed competences)

and are much less interested in actual training and education.



,0

20,0

40,0

60,0

80,0

100,0

Perc

en

t

Print Online Education Information Workshops

Method to keep up to date

To Keep Up to Date - Public Bodies/Governmental Agencies Group

Yes

No

No Answ er

Figure 20: Methods to keep up to date – public bodies/governmental agencies group

Asked what areas of accessibility they would like to improve (see Figure 21),

following topic scored high: web accessibility. To a less extent there was interest in

mobile accessibility, and accessibility standards.

,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

Perc

en

t

Web

Accessibility

Mobile

Accessibility

Devices Assistive

Devices

Accessibility

Standards

Interests

Interests in Further Education - Public Bodies/Governmental Agencies

Group

Yes

No Answ er

Figure 21: Interests in further education – public bodies/governmental agencies group



Asked how accessibility issues could be best disseminated (see Figure 22), most of

the interviewed public servants identified the traditional printed media and online

format as main dissemination channels. Internal information through newsletters and

internal meetings, as well as attendance to conferences were also cited. In most cases

where through personal interviews additional information was asked, these same

public servants were not able to identify what kind of events would be of interest in

fact.

,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

Perc

en

t

Print

Onl

ine

Rese

arch

Educa

tion

Inte

rnal

Info

rmat

ion

Conf

eren

ces

Serv

ice

Pro

vider

Channels of Dissemination

Channels of Dissemination of Accessibility Results - Public


Yes

No Answ er

Figure 22: Channels of dissemination of accessibility results - public bodies/governmental agencies

group


All surveyed public servants had been involved one way or the other in the creation of

an accessible website for their organization and had faced a multitude of problems.

Below table provides an overview.

Difficulty faced Percentage

Unavailability of internal expertise 72% Unavailability of external expertise 50% Structure of the content 28% Create dynamical elements, for example route

planner

11%

Adopting old contents to the new website 61% Definition of accessibility 17% Problems to define the target group 22% Time target of realisation 94% Legislation 28% Looking for service providers who are competent 100%



Difficulty faced Percentage

in accessibility

Costs of realisation 78% Creation of accessible downloads 50% Maintenance of accessibility 89% Table 20: Difficulties faced in crating accessible website – public bodies/governmental agencies group

The main issues that were faced are:

Unavailability of internal expertise

Adopting old contents to the new website

Time target of realisation

Looking for service providers who are competent in accessibility

Costs of realisation

Maintenance of accessibility

Asked what their expectations are of an accessible website, it becomes obvious that

public servants surveyed are aware of the need and advantages of accessibility (see

Figure 23), albeit that in reality so far they face a multitude of problems in actually

implementing this.

,0

20,0

40,0

60,0

80,0

100,0

Perc

en

t

Wider

Audience

Search Engines

Optimatisation

Usability of the

Website

More

Functional

Higher Access

Rate

Expectations

Expectations of an Accessible Website - Technical Expectations - Public


I Don´t Know

Yes

No

No Answ er

Figure 23: Expectations of an accessible website – Technical expectations – public

bodies/governmental agencies group

Asked how they do confirm the accessibility of their developed websites, following

results were gathered (see Table 21).

Accessibility confirmed through ... Percentage

External service 28%

Internal review 56%



Accessibility confirmed through ... Percentage

Feedback of citizens/customers 11%

Use of accessibility evaluation tools (e.g. WAVE,

TAW, Hera)

67%

Training of the editors/developers 56%

Training of the administrator 50%

Not at all 0%

Table 21: Accessibility assessment – public bodies/governmental agencies group

It is obvious from this data that the use of evaluation tools is the main support in

assessing and ensuring accessibility of the developed websites. Striking however is

also that external support was needed to ensure this accessibility. This is now being

addressed by public services by them organising training internally (as reported by

half of the surveyed individuals).


89% of the surveyed individuals indicated that guidelines were incorporated, but only

28% could actually name the guidelines/standards (such as WCAG 1.0, WCAG 2.0,

ATAG). The 89% of the individuals that were aware that guidelines were

implemented linked this all to web accessibility in the context of eGovernment.

However, the degree of e.g. WCAG priority levels was unknown to most (only 25%

of this 89% knew that the priority level 2 was applied). Same regarded WCAG 1.0 or

WCAG 2.0. The same 25% replied here that they were not switching to WCAG 2.0

yet. However, 100% indicated that the public bodies/agencies they work for do expect

some kind of official accessibility certification of the services that they offer or

develop, albeit that in most countries a national label is not in place yet. If labels are

applied, this is in most cases awarded by external assessors (organisations that were

set up to test the accessibility of public websites), awarding either the national labels

(28%), or referring to W3C CSS (61%) and W3C WAI-AAA (61%) labels. The

Table 22 shows an overview of web accessibility legislations and labels on a national

level.

Countries Law on Web

accessibility

Public

Web

sites

Indirect

WCAG

reference

"National"

label

Sanctions

Germany Yes Yes Yes - Yes

Greece - N.A. - - -

Italy Yes Yes Yes Yes Yes

Portugal Yes Yes Yes - -

United

Kingdom

Yes Yes Yes - Yes

Table 22: Accessibility assessment – public bodies/governmental agencies group11

A related question was how they can be supported in enforcing accessibility within

their organisation. All surveyed did respond. Following was the outcome:

Support in enforcing accessibility Percentage

Local contact persons/policy makers 78%

11

As extracted from http://www.support-eam.org/Supporteam/Documentary/accessibility_policies.asp



Support in enforcing accessibility Percentage

Clear specification of an accessible design from

the very beginning

50%

Clear specification of programming 50%

Clear laws 78%

Guidelines 33%

Advanced Training concerning accessibility 17%

Table 23: Support in enforcing accessibility – public bodies/governmental agencies group

It is obvious from this that policy making is high in the agenda of public servants,

connected with the issuing of specific accessibility legislation. However, the replies

where specifications on accessible design and programming were selected as being

good in enforcing accessibility came from those individuals with a technical

background as will be pointed out later on in this section.

Asked how they evaluate their software implementations about accessibility,

following responses were collected:

Accessibility evaluated through ... Percentage

With a well-known accessibility assessment tool,

for example WAVE, Hera, TAW

67%

With the participation of potential elderly and/or

users with disabilities

28%

Questioning accessibility experts 78%

Using Assistive Technology, for example Screen

reader

17%

Other, please specify: 0%

We currently do not test our development about

accessibility

0%

No answer 0%

Table 24: Accessibility evaluation software implementations – public bodies/governmental agencies

group

This highlights again that public bodies/agencies often have to use external

accessibility experts, while they also heavily depend on assessment tools. The usage

of real end-users is low, and so is the usage of real AT.

Looking closer at the tools being used, only 50% gave an answer (the same ones that

also selected in the previous Table 23 the options of clear specification of an

accessible design from the very beginning, and clear specification of programming).

This indicated that the surveyed individuals were mostly involved on a higher level

than the actual implementation level. Nevertheless, the answers received were similar

to those of other user groups.





89%






Screen reader 22%


Keyboard filters 33%


Table 25: Usage of accessibility evaluation and AT tools – public bodies/governmental agencies group

Simulation tools are here as well a preferred tool for evaluating the accessibility of

implementations.

The same individuals that answered above questions, also indicated which

tools/methodologies they would be interested in (see table below) to evaluate their

implementations.


involved in the accessibility assessment)


Hera, TAW)

67%



100%



78%




head-mice)

100%






78%

Table 26: Desired usage of accessibility evaluation tools – public bodies/governmental agencies group

The outcomes are pointing out here that there is a strong preference for following

tools (higher than 50%):



Accessibility Authoring tools (e.g. Adobe Dreamweaver, Microsoft Visual

Studio)



Equally, the surveyed individuals were interested in accessibility related events and

databases on accessibility experts. This can be directly linked to the fact that public

offices/agencies make extensive use of external expertise as was demonstrated before

in earlier findings in this section.



3.8.3.3 Summary

This user group is a rather heterogenic one, in the sense that half of the surveyed

individuals had a managerial position, while the other half was really involved in

software developments for eGovernment services. This was also reflected in the

responses, whereby those with a software background were able to complete all

answers, and the managerial ones only half of them. Nevertheless, some interesting

findings were made:

Accessibility is mainly originating from legislation that forces these public

bodies to address accessibility throughout all services provided, and so also in

all their eGovernment activities (mainly online that is).

Online access to information is here as well the main channel to access

accessibility information. This was the same for accessibility dissemination,

albeit however that most respondents were still keen on traditional printed

media. This has been an exception among all surveyed groups, but might be

based in a rather “traditional culture” that still survives in public

bodies/agencies.

Web accessibility is a main area that they seek to improve.

The unavailability of internal expertise was identified as being a main barrier

regarding accessibility of the delivered services. Internal trainings were taking

place, but in most cases external expertise was still needed for assessments.

This also explains why the surveyed individuals were interested in

accessibility related events and databases on accessibility experts to evaluate

implementations.

Evaluation, assessment and simulation tools were the main support in

assessing and ensuring accessibility of the developed websites, with hardly

any involvement of end-users nor of AT.

Simulators of AT were wanted by all those involved in software development.

Specific guidelines such as WCAG 1.0 were implemented, but few could

really provide details on this.

All indicated that the public bodies/agencies they work for do expect some

kind of official accessibility certification of the services that they offer or

develop, albeit that in most countries a national label is not in place yet. If

labels are applied, this is in most cases awarded by external assessors

(organisations that were set up to test the accessibility of public websites),

awarding either the national labels, or referring to W3C CSS and W3C WAI-

AAA labels.

3.8.4 Service Providers

In total 41 individuals (of which 24 men) between 24 and 60 years of age participated

in this part of the survey. 20 worked as webmaster, 13 as web designer and 8 in the

PR (public relations) divisions of private companies (92% worked in SMEs of 51-100

employees). 14 (34%) of the individuals surveyed have a disability and worked as

web designer and 1 person also in PR.

84% of those surveyed indicated they were acquainted with individuals having

disabilities. 77% have a disabled individual in their circle of friends and/or work

environment or are themselves disabled.



Being in Touch with People with Disability - Service Provider Group

No Answ er

No

Yes

Figure 24: Being in touch with people with disability – service provider group


95% of all surveyed were familiar with the concepts “usability” and “accessibility”,

and a majority (87%) of these people also linked it with accessible websites and

devices. 85% had dealt with accessibility for the past 2 years and asked for what

reason that was, following answers were given:

Reason of dealing with accessibility Percentage

It was a project requirement (e.g. User needs) 85% It was a requirement of my employer 73% Due to a work-related advanced training 49% Due to private interest 34% Due to public policies or recommendations (e.g.

incorporate accessibility in all public Web sites)

59%

Table 27: Reason of dealing with accessibility – service providers group

Obviously, accessibility has become an increasing requirement in services provided

by service providers. The fact that 80% of the surveyed individuals has been working

in a web environment (either as webmaster or designer) also highlights the increasing

importance of fully accessible internet applications. Similarly, the interests of the

surveyed individuals also show a clear interest in further knowledge about web and

mobile accessibility (see table below). Also knowing more about assistive

technologies and devices scores relatively high (all individuals with a disability

selected this).

Learn more about accessibility of ... Percentage

Web accessibility 88% Mobile accessibility 66% Assistive devices (e.g. Screen reader) 56% Assistive technologies (e.g. Braille alphabet) 41% Accessibility standards and methodologies (e.g.

WCAG)

29%



Learn more about accessibility of ... Percentage

Legislation regarding accessibility 7% Table 28: Learn more about accessibility – service providers group

How they prefer to know more about accessibility is by doing the actual work (88%),

namely via training while working in a project which deals with accessibility.

Just like the developers, this surveyed group indicated a high awareness level of

various accessibility standards and guidelines (also linked to the fact that 76% of the

surveyed individuals mentioned that their company implemented internal guidelines

for accessibility – mostly based on WCAG 1.0).

Guidelines, standards Familiarity

WAI-ARIA Rich Applications 37%



Section 508 7%

Authoring Tool Accessibility Guidelines (ATAG) 5%

Table 29: Familiarity with standards and guidelines – service providers

Those that did indicate the WCAG 1.0 guidelines also confirmed that these guidelines

were applied in their respective development processes within their company. The

standards were mainly used for internet applications to reach priority 2 levels of

accessibility (97% of those that indicated using those standards) and desktop

applications (44% of those that indicated using those standards). 32% of those that

indicated WCAG1.0 also stated they would switch to WCAG 2.0 as soon as possible.


Within the working environment, the surveyed individuals mainly kept updated

through online research (83%), and only 39% did so via printed media.

90% of the surveyed individuals stated that customers of their company did care about

accessibility. This is again linked to legislation that has been put in place in different

countries and that address accessibility of public websites (this is a large customer for

the software business Europe-wide. All webmasters and designers (80%) did indicate

that their customers desire accessibility certification. However mostly this is still

limited to being W3C CSS and W3C WAI-AAA compliant (all cases among

webmasters and designers), and less regarding national certification labels regarding

the accessibility of services.

32% did use IDEs, and only 23% of those did not know if the IDE application

supported accessibility. This can be explained by the fact that 85% of those surveyed

are presently or had in the past participated in accessibility oriented projects.


Asked how they currently evaluate the accessibility of their developments, assessment

tools scored high, followed by the use of AT and the participation of potential users

with disabilities (these 2 last ones came entirely from all the individuals that had a

disability).



Ways to evaluate accessibility developments Percentage

With a well known accessibility assessment tool,

for example WAVE, Hera, TAW

66%

With the participation of potential elderly and/or

users with disabilities

34%

Questioning accessibility experts 7%

Using Assistive Technology, for example Screen

reader

32%

We currently do not test our development about

accessibility

0%

Table 30: Ways to evaluate accessibility developments – service providers group

The usage of assistive technologies (AT) to assess accessibility yielded again similar

results to that of the developers.





27%


Service)

76%



Screen reader 34%


Keyboard filters 17%


Table 31: Usage of accessibility evaluation and AT tools – service providers group

Asked which tools / methodologies they would be interested in, the outcome revealed

a large interest in assessment and simulation tools, something which is quite similar to

the results of the developer group.




Hera, TAW)

85%



78%



66%




head-mice)

85%










7%

Table 32: Desired usage of accessibility evaluation tools – service providers group

The preferred manner for access to the simulation/validation tools would be via

download or online (both 93%).

3.8.4.3 Summary

Service providers have been facing a changing market. Since the early 2000s,

accessibility guidelines have become more and more specialised, while an increasing

demand (mainly from public institutions) has forced these providers to ensure they

embed accessibility within the services they provide. From the survey carried out, it

looks like the individuals surveyed are fully aware of this. While they have already

access to various accessibility tools and methodologies, they are one of the most eager

groups survey for further advancement in this area. Following user requirement were

extracted:

Accessibility has become an increasing requirement in services provided by

service providers.

Surveyed individuals displayed a clear interest in further knowledge about

web and mobile accessibility, and prefer to do so through real work in this

area.

They have a high awareness level of various accessibility standards and

guidelines, especially WCAG 1.0, with an interest to go to WCAG 2.0.

Being kept up-to-date is preferably via online resources. This is also the

channel through they prefer to have access to new tools.

All webmasters and designers indicated that their customers desire

accessibility certification. However mostly this is still limited to being W3C

CSS and W3C WAI-AAA compliant, and less regarding national certification

labels regarding the accessibility of services.

They currently evaluate the accessibility of their developments mainly with

assessment and simulation tools, followed by the use of AT and the

participation of potential users with disabilities (theses 2 last ones came

entirely from all the individuals that had a disability).

They desired further usage of assessment and simulation tools, both for

accessibility and for AT).

3.8.5 Elderly and Disabled Users

A total of 67 individuals were surveyed (39 men and 28 women) between 19 and 75

years old. 81% responded that they had a disability (hearing (26%), sight (43%) and

mobility impairments (24%) were most commonly listed). 34 individuals (51%) are

members of organisations for people with disabilities, while 22% are members of self-

help groups. 41% is employed (the rate of employment among the hearing and visual



impaired –respectively 41% and 32%- is higher than the mobility impaired which is

just 27%)12

.

3.8.5.1 Handling and usage of ICT

Those surveyed in this group use ICT often, without differentiating between private or

workplace usage. 75% of this user group use a PC or laptop and do so mostly on a

daily basis (50% of those that use a PC/laptop), 84% uses a mobile phone (89% of

those that use a mobile do so on a daily basis), followed by the TV (also 89%).

The reasons why these devices are used are quite differentiated as is shown in Figure

25.

Figure 25: Device usage – elderly and disabled user group

In terms of AT that was used for all these, following were mentioned, mostly by the

visual impaired people: special "screen enlargement" ("more than 16 x), Jaws, Magic

and Dragon, speech recognition software, speech to text input, zoom/large text

facilities, adapted keyboard, on-screen keyboard, magnifier, audio translator.

Asked whether they attended special courses or training seminars, only training for

computer usage scored high.

Devices Percentage

Computer 60%

Mobile phone 21%

PDA/Handheld 0% Netbook 0% (GPS) Navigation 0%

Table 33: Devices – elderly and disabled user group

Problems are being faced by these users in computer and mobile devices mainly (see

Figure 26). While usability issues arise with almost half of the users in all of the

12

Approximately 65% of EU‟s non-disabled people are employed.



devices, physical fatigue issues also arise, such as muscle and neck pains, headaches

and eye strains.

,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

Perc

en

t

Computer Mobile PDA Netbook TV Navigation

ICT

Problems in Using ICT- Eldery and Disabled People Group

Not at All

Not Alw ays

Mostly

Yes

No Answ er

Figure 26: Problems in using ICT – elderly and disabled user group

Usability issues are mostly related to inaccessible interfaces. With regards to website

accessibility, following suggestions were made to enhance website accessibility:

Web sites enhancement for the improvement of

their accessibility

Percentage (of those using the internet)

Increase the compatibility between assistive

technology and Web pages

73%

Improve the contrast of the colours 44%

Use of more comprehensive navigation

mechanisms

49%

Zoomable fonts 29%

Buttons and text size should be bigger 31%

Use of alternative media for audio-based

information

36%

Table 34: Web sites enhancement for the improvement of their accessibility – elderly and disabled user

group

These results are not really surprising, and are also largely linked to the various

disability groups represented in the survey group. These users do largely rely on their

friends to assist them in case they face issues as is shown in Figure 27.



,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0P

erc

en

t

Friends Forum Service Provider

Help

Solving ICT Problems - Elderly and Disabled People Group

Yes

No Answ er

Figure 27: Solving ICT problems – elderly and disabled user group

3.8.5.2 Advanced Training and Education

50 out the 67 (75%) surveyed individuals uses at present a computer. Of these 50, 40

did use a computer course, mainly regarding word processing and overall usage of

internet (browser, e-mail). However, these courses are often not at the desired speed

and depth wished for by the attendees. One individual stated that:

“... together in a room equipped with PCs without the AT we usually have at

home, and with people with a wide variety of disabilities ... going that fast, I

was unable to follow. I quitted after 4 lessons.”

3.8.5.3 Summary

The surveyed group of individuals was very heterogenic due to the various

(combined) disabilities represented. It is however clear that the user interface of web

and increasingly also mobile applications is creating a barrier for these people.

Following were the main requirements that were extracted:

A majority uses the computer/laptop or mobile on an almost daily basis.

A wide variety of AT is used in order to access interfaces on both computer

and mobiles.

Training is often followed for computer, but proves to fall short of

expectations, Users therefore often rely on friends to help them out.

A main improvement would be to increase the compatibility between assistive

technology and web pages.



3.9 Extracting the User Needs / Requirements

Having extracted the user requirements from the survey carried out, this section will

extract generic functional requirements from the collected user requirements. To be

able to do so, all user requirements have been consolidated and grouped as can be

seen in below table, while for each grouped requirement, a number of generic

functional requirements have been deduced.

As starting point, we can already conclude from the feedback received from all

targeted user groups, that overall there is a strong interest in implementing

accessibility throughout all services provided, whether for mobile or desktop, and also

in the areas of web applications. This was confirmed in all user groups. Looking

however why this is not fully done yet, there is obviously a lack of tools to support the

development, both in developing accessible applications and interfaces, as well as

assessing them. Especially assessments are poor in many cases due to non-usage of

AT and the lack of assessments through simulations. Tools currently used do not meet

the new standards like WCAG2.0, nor do they consider the development of accessible

interfaces or are they able to make simulations of user interfaces under different user

environments (different impairments and devices).

Table 35 provides an overview of requirements that have been identified during the

survey, and that have been grouped according to accessibility areas, need for

education, need for assessment, need for tools to assess and simulate, provision of a

development area, the ways the tools will be made available, how accessibility

information will be made available, what the importance is of certification and end-

user related aspects.

Requirements

User requirement Generic Functional requirements (as defined in section 4)

Accessibility areas

Focus on web and end user

device accessibility, however

lacking standards about

mobile, Web services and

SDL.

G-REQ1-2: The system shall provide users with detailed accessibility

instructions and guidelines for the implementation of accessible Web, Mobile

applications, Web services and/or description languages.

G-REQ1-8: The system shall take into account some of most widely known

mobile content standards, such as MWBP 1.0, etc. and also modify the existing

ones or add new ones.

G-REQ1-13: Where appropriate, each user preferences shall combine different

kind of disabilities, assistive technologies and accessibility standards.

G-REQ1-6: The system shall take into account all the most widely known Web

accessibility standards, such as WCAG 1.0, WCAG 2.0, Section 508, etc and

also modify the existing ones or add new ones.

G-REQ1-7: The system shall support potential users to select one or more of the

stored accessibility standards or guidelines, such as WCAG 1.0, WCAG 2.0,

Section 508.

G-REQ1-9: The system shall support different potential users (developers,

designers, IT managers, etc.) to test its developments against any set of selected

accessibility criteria and/or rules specified by users.

G-REQ2-1: The Web assessment simulation module shall test the accessibility

of applications according to the guidelines of widely accepted accessibility

standards (e.g., WCAG1, WCAG2, Section 508, etc) where appropriate.

G-REQ3-8: The ontology shall include widely used web content accessibility

guidelines (such as WCAG 1.0, WCAG 2.0, etc.).

G-REQ2-21: The description languages assessment tool should be able to

evaluate accessibility features for designs/systems based on the SDL-2000



Requirements


standard.

G-REQ2-28: The description languages assessment module shall include a

software sub-system capable to parse SDL designs based on the SDL-2000

standard.

Education

Need for advanced (online)

education in the area of

accessibility, especially then

for web and mobile

accessibility, accessible user

interface aspects and

(assistive) devices




Developers need knowledge

about disabilities and

functional limitations,

assistive devices, and the

relevant accessibility

standards and guidelines.

Equally, development and

assessment should be

undertaken using common

and general guidelines

instead of national guidelines,

pushed forward by different

countries and organisations.

G-REQ2-2: All assessment simulation modules shall connect with the ontology

and run all the SWRL rules defined in the ontologies.

G-REQ2-3: All assessment simulation modules shall be able to get the instances

of all the classes defined in the ontologies and present them in an appropriate

GUI.

G-REQ3-1: The ontology will support the OWL Web Ontology Language

G-REQ3-2: The ontology shall support the SWRL (a Semantic Web Rule

Language) rules, which form of an implication between an antecedent (body)

and consequent (head).

G-REQ3-3: The ontology shall support SPARQL queries that consist of triplets,

in order to narrow the information space of accessibility assessment according

to specified semantics of usage scenarios.

G-REQ3-4: In order to preserve the integrity and the maintenance of the

ontology, the ACCESSIBLE ontology based knowledge resource shall include

generic and domain-specific ontologies.

G-REQ3-5: The ACCESSIBLE ontology shall contain a generic version which

describes the general structure of accessibility attributes such as guidelines,

users, devices, and applications.

G-REQ3-6: The domain ontologies shall include different characteristics and

instances of accessibility standards, disabilities, functional limitations, devices

and application domains.

G-REQ3-7: All the domain ontologies shall comply with the generic ontology.



G-REQ3-9: The ontology shall include the most well known disabilities that

people face and for which accessibility guidelines provide clues on how they

should be supported in software applications.

G-REQ3-10: The ontology shall include a variety of assistive devices, which are

used from people with disabilities.

G-REQ3-11: The ontology shall incorporate different types of applications

(such as web services, HTML) that can be verified for their accessibility status.

G-REQ3-12: For the implementation of the ontologies, the Protégé ontology

editor will be used as well as the SWRL supporting plug-in.

G-REQ3-13: Adequate semantic description shall be provided from all the

characteristics that are included in the generic as well as in the domain

ontologies.

G-REQ3-14: The execution of queries and rules shall be supported through the

integration of an open source inference engine that shall support the usage of

SPARQL as well as SWRL.

Manuals are needed with

specific examples for the

creation of accessible content,

while there is also interest in

invitations to events about

accessibility issues, and

knowledge about available

G-REQ4.1-8: Users must have the option to access related links of various

accessibility issues and have the option to get informed about upcoming events

relevant to the ACCESSIBLE.



Requirements


assistive devices.

Assessment fields

Assessment of accessibility

of web, mobile and desktop

applications

G-REQ2-9: The SDL application assessment tool shall support the accessibility

assessment of SDL systems.

G-REQ2-10: The mobile assessment module shall support the accessibility

assessment of the mobile Web.

G-REQ2-11: The mobile assessment module shall verify how interaction input

is performed in the application, and how it influences accessibility issues.

G-REQ2-12: The Web Services assessment tool should be able to evaluate

accessibility features of the most common types of Web Services worldwide.

G-REQ2-13: The Web Services assessment tool should enable the integration of

the modified ASK -IT alignment tool

G-REQ2-14: The SDL assessment tool should enable the integration of the

SAFIRE platform for the parsing of SDL components.

G-REQ2-15: The Web assessment tool should enable the integration of the SET

tool for the visualisation of the assessment results

G-REQ2-16: The Web Services assessment tool will be able to evaluate

accessibility features of Web Services that follow the W3C‟s SOAP-based

standardization.

G-REQ2-17: The Web Services assessment module will be able to evaluate

accessibility features of Web Services, using the SOAP-based WSDL files

defining them.

G-REQ2-18: The Web Services assessment module should be able to read the

types of WSDL files (WSDL parser) that are used by the majority of working

SOAP-based Web Services



standard.

G-REQ2-22: The description languages assessment module should be able to

read and parse the types of SDL files that are based on SDL-2000 using an SDL

parser.

G-REQ2-23: The Web assessment module shall work in two different modes

for HTML applications: single web page assessment and entire web site

assessment

G-REQ2-24: If the overall web application mode is being chosen, there shall be

an option defining the maximum number of web pages that will be examined.

G-REQ2-25: The mobile assessment module shall accept a compiled

application (e.g. JAR file) for verifying the accessibility of native mobile

applications.

G-REQ2-26: The assessment module shall work in two different modes for

Mobile applications: Mobile Web page automated assessment, and Mobile Web

site automated assessment

Tools

Embedded validators in the

development tools, with

accessibility simulation and

authoring tools together with

simulators of assistive

technology and accessibility

assessment tools. This should

address different disabilities,

as well as combinations of

disabilities. Accessibility

should as such be introduced

within the software design

process (not only in the

development process).

G-REQ1-1: The system shall support developers and designers to assess the

accessibility of their developed applications via the ACCESSIBLE assessment

module.

G-REQ1-4: The system shall enable an easy reconfiguration of accessibility

assessment processes

G-REQ1-5: The system shall provide appropriate tools to developers and

designers to simulate their developed applications with visual impairments via

the developer-designer aid module.







G-REQ1-10: The ACCESSIBLE system shall support the implementation of



Requirements


appropriate rules based on the ACCESSIBLE knowledge resource and on user‟s

preferences.

G-REQ1-11: The ACCESSIBLE system shall support personalised accessibility

assessment functionalities that must cope with user‟s disabilities and

individual‟s preferences.

G-REQ1-12: The system shall support developing/assessing for a variety of

disabilities and functional limitations (based on the ICF categorization). At least

visual, auditory, and hearing disabilities should be taken into account.

G-REQ1-13: Where appropriate, each user preferences shall combine different

kind of disabilities, assistive technologies and accessibility standards.

G-REQ1-14: Where appropriate, the developers or the system users shall

receive appropriate reports concerning the results of their accessibility tests

based on the EARL language.

G-REQ2-4: The assessment simulation module shall give user the opportunity

to define the tests that will be executed according to specific selections made in

some pre-defined categories (user, device, disability, functional limitation,

application, etc) as these categories and their relationships defined in the

ontology.

G-REQ2-7: In the ACCESSIBLE assessment modules, the co-operation of the

module with the ontology will be performed using Groovy scripts.

G-REQ2-8: In the ACCESSIBLE assessment modules, the SPARQL queries

that will be executed will be defined in separate text files with .sparql extension.





G-REQ2-11: The mobile assessment module shall verify how interaction input

is performed in the application, and how it influences accessibility issues.



G-REQ2-13: The Web Services assessment tool should enable the integration of

the modified ASK -IT alignment tool

G-REQ2-14: The SDL assessment tool should enable the integration of the

SAFIRE platform for the parsing of SDL components.

G-REQ2-15: The Web assessment tool should enable the integration of the SET

tool for the visualisation of the assessment results

G-REQ2-19: The user shall be able to select manually one by one all the tests

that will be executed.

G-REQ2-20: The assessment simulation modules after the assessment

completion shall output the results in EARL format



standard.

G-REQ2-22: The description languages assessment module should be able to

read and parse the types of SDL files that are based on SDL-2000 using an SDL

parser.

G-REQ2-23: The Web assessment module shall work in two different modes

for HTML applications: single web page assessment, and entire web site

assessment

G-REQ2-24: If the overall web application mode is being chosen, there shall be

an option defining the maximum number of web pages that will be examined.

G-REQ2-25: The mobile assessment module shall accept a compiled

application (e.g. JAR file) for verifying the accessibility of native mobile

applications.

G-REQ2-26: The assessment module shall work in two different modes for

Mobile applications: Mobile Web page automated assessment, and Mobile Web

site automated assessment

G-REQ2-27: The description languages assessment module shall accept as input



Requirements


files with relevant file extensions (e.g. “*.pr”, “*.fsm”) for verifying the

accessibility of SDL systems/designs.

G-REQ2-28: The description languages assessment module shall include a

software sub-system capable to parse SDL designs based on the SDL-2000

standard.

G-REQ4.2-1: The User Interface of the stand alone tools (Web assessment,

Mobile assessment, Web services and DL) should be both powerful and

intuitive to use in order to facilitate both novice and experienced users.

G-REQ4.2-2: The user interface should provide appropriate organisation of

evaluation sessions in order to be able to facilitate both the evaluation of single

documents and collections of documents such as web sites residing on the local

computer, collection of web services etc.

G-REQ4.2-3: Users should have the option to save the specific details of each

of their evaluation sessions.

G-REQ4.2-4: Users and especially developers should be provided with

functionality that meets the one provided by other popular developer oriented

tools.

G-REQ4.2-5: The user interface shall provide the option to preview the source

code of the evaluated applications.

G-REQ4.2-6: The user interface shall provide the option to preview the

evaluated documents using the most appropriate tools available according to the

document format.

G-REQ4.2-7: The user interface should provide users the ability to select among

a number of settings in order to define the targets of each evaluation putting on

the hands of the tool the matching of these setting to specific guidelines and

tests.

G-REQ4.2-8: The user interface should provide users the ability to manually

select among a number of guidelines the ones to be used for performing the

evaluation.

G-REQ4.2-9: The User Interface shall provide high efficiency, reliability, and

resource utilisation of the ACCESSIBLE tools.

G-REQ4.2-10: Users should have the option to operate the stand alone tool

without the need of a connection to the internet.

G-REQ4.2-11: Users should have the option to access several different views of

the evaluation results.

G-REQ5-1: The module shall help the developer/designer to ensure his

application is accessible and usable to impaired users.

G-REQ5-2: The module will provide the means to simulate different low vision

impairments, such as loss of central or peripheral vision.

G-REQ5-3: The module will provide the means to simulate the most common

low vision impairments, such as cataract or glaucoma.

G-REQ5-4: The module will provide the means to simulate the most common

color-blindness impairments, such as protanomaly or deuteranomaly.

G-REQ5-5: The module shall be delivered in two versions. One of them shall be

developed as a plug-in that can be included into the Netbeans IDE and the other

as a standalone application.

G-REQ5-6: The module will provide the means to simulate different upper limp

impairments, such as Parkinson disease.

Development areas

Especially WCAG 1.0 is used

since they often use a subset

of it in the national guidelines






Section 508.






Requirements







Desire to be able to

implement and incorporate

WCAG 2.0






Section 508.









Programming/scripting

languages were mainly used:

Java, C/C++, PHP and ASP

G-REQ2-5: The web application assessment tool shall support the accessibility

assessment of HTML Web applications.


assessment of (HTML) Web applications generated from different server-side

environments, languages or technologies (PHP, ASP, JSP, etc.)

XML preferred structural

mark-up language




Integrated Development

Environment (IDE) are used,

but few are aware of any

embedded accessibility

features.


developed as a plug-in that can be included into the Netbeans IDE and the other

as a standalone application.

Availability tools

Preference to provide

accessibility

simulation/validation tools

online or as download

G-REQ4.1-3: Users shall have the option to download the standalone tools

developed in the context of ACCESSIBLE (Net Beans IDE plug-ins, the

accessible assessment and simulation module etc).

G-REQ4.1-4: The User Interface shall provide information about the goals of

ACCESSIBLE project.

G-REQ4.1-5: The User Interface shall provide clear instruction before and

during interaction.


resource utilisation of the ACCESSIBLE tools and services.

Availability accessibility information

Preference for accessible

online access to information

to be kept up-to-date on

accessibility issues

G-REQ1-3: Where appropriate, the system shall allow the definition of

accessibility terms and constraints using ontology based description languages

and different domain ontologies.

G-REQ4.1-1: The User Interface of ACCESSIBLE portal shall be user friendly

that means that the uses must locate the required information on the screen

easily. Also the portal will be accessible to everyone.

G-REQ4.1-2: The Web based Interface shall provide to users the ability to

assess web sites, web applications and mobile applications via their URL.

G-REQ4.1-7: The User Interface shall provide all the useful information to web

developers (such as standards and guidelines) in order to create accessible

applications.

G-REQ4.1-9: Where appropriate the User Interface shall be designed in

accordance to the project‟s logo and colours and contrast shall comply with the

usability guidelines.

G-REQ4.1-10: Users should have the option to subscribe to the portal providing



Requirements


their personal information and therefore get access to the facilities offered to

subscribed users.

G-REQ4.1-11: Registered users should have access to a number of chat rooms

with different thematology and have the option to participate to online real-time

discussions taking place into the existing chat rooms.

G-REQ4.1-12: Registered users should have the option to access resources and

training material related to the development and evaluation of accessible

applications in various contexts.

G-REQ4.1-13: Users should have the option to perform keyword based search

for resources.

G-REQ4.1-14: Registered users should have the option to personalise the way

that knowledge is displayed through the existence of facilities such as

“knowledge profiles”.

G-REQ4.1-15: Administrators should have the option to update or enrich the

collection of knowledge offered by the portal.


collection of training material offered by the portal.

Unavailability of internal

expertise




Involvement external

expertise




Databases on accessibility

experts




Internal trainings G-REQ4.1-8: Users must have the option to access related links of various



Accessibility related events G-REQ4.1-8: Users must have the option to access related links of various



Certification

Have accessibility

certifications (based on or

subsets of W3C WAI-AAA

and W3C CSS guidelines)



Section 508.

G-REQ1-14: Where appropriate, the developers or the system users shall

receive appropriate reports concerning the results of their accessibility tests

based on the EARL language.

G-REQ2-20: The assessment simulation modules after the assessment

completion shall output the results in EARL format

G-REQ6-1: The EARL-based reporting tool shall be used in order to present the

results of the Accessibility Evaluation in a standardized and easy-to-understand

way.

G-REQ6-2: The EARL-based reporting tool will incorporate terms and

constraints from the W3C Evaluation and Report Language.

G-REQ6-3: The EARL-based reporting tool shall contain a group of labels in

order to identify the person who or the tool that carried out the test, as well as

when the test was carried out, or information about the platform and

configuration in which the test was executed.

G-REQ6-4:The EARL-based reporting tool shall also provide information about

the subject that is being evaluated and could be a piece of a software code, a

document, Web content (such as Web pages, videos, applets, etc.) or software

(such as accessibility checkers, validators, user agents, etc.).

G-REQ6-5: The EARL-based reporting tool shall provide information about the

test criteria against which a subject is being evaluated.


outcome of a test conducted on a subject.



Requirements


G-REQ6-7: The test result can contain information such as the success or failure

of the test, a confidence indicator for the obtained results, the reason for failing,

or other attributes.

G-REQ6-8: The test result shall include both machine-readable values as well

as human-readable description of the results.

G-REQ6-9: Any extensions to the EARL vocabulary must ensure the integrity

and validity of the core EARL vocabulary

G-REQ6-10: The tool shall provide built-in extensions of its core vocabulary at

least to the domain of Web accessibility evaluation.

End-user related

Computer/laptop or mobile

are used on an almost daily

basis




Table 35: Dedicated generic functional requirements, extracted from user requirements



4 ACCESSIBLE System Requirements This chapter lists all the different types of requirements that the ACCESSIBLE

systems must fulfil. The result will be a classified list of very requirement that the

system must satisfy.

For that purpose the following have been taking into account:

State of the art Analysis within T2.2” Literature review and market survey”:

The deliverable D2.1”State of the Art Survey in Accessibility Research and

Market Survey” is essential in order to become deeply familiar with the

existing accessibility standards, tools and methods.

ACCESSIBLE system architecture specification (D3.3a).

Requirements for Software Accessibility Assessment through the results of

D2.1 and based on requirements and work that is being carried out in response

to the European Commission‟s Mandate M376, as well as well known

accessibility standards such as ISO 9241-171: Ergonomics of human-system

interaction - Part 171: Guidance on software accessibility, etc.

User needs extraction performed within T2.1” User Needs” through the

evaluation results of completed questionnaires and appropriate interviews with

end users (the evaluation of the results will be included in the final version of

this deliverable).

Eliciting Information: it is fundamental in this phase to undertake planned

interviews with the different target users that take part in the project to be able

to analyze and evaluate all the gathered information, opinions and expectations

that they have about the system, and capture them in writing in form of

requirements.

Taking the innovative fundamentals of the Description of Work as a starting

point.

Partners and external experts experience, which have been gathered in project

meetings. Thus, group discussions help on summarising the ideas held by

individual members. New ideas, design options, requirements and architectural

issues, layouts, etc., have been discussed, and a collective view is established

from individual views.

4.1 Requirements Taxonomy

This deliverable provides the needed material, namely grouped and analyzed

requirements, which have been classified explicitly and formally into categories and

have been univocally identified, avoiding inconsistencies and duplication of concepts.

The ACCESSIBLE requirements are classified following the below criteria:

Functional requirements, specifying functions that the system components

must be able to perform.

Non-Functional Requirements including:



o Performance requirements, indicating numerical values for measurable

variables used to assess applications.

o Operational and usability requirements, describing how the system will

run and how it will enhance usability issues.

o Reliability requirements, denoting the acceptable mean time between

software failures averaged over a significant time period.

o Maintainability requirements, indicating how easy should the repairing

of software flaws be, or how easy new features can be introduced into

the system.

o Interoperability requirements, which are multi-fold, addressing the

need for a modular, open source system architecture that will enable

seamless service provision over different platforms and networks.

4.2 Requirements Prioritization

The ACCESSIBLE System Requirements that are described in the following sections

describe what the ACCESSIBLE System should or should not do. They describe also

the constraints that all the modules, which belong to the ACCESSIBLE System,

express. Thus for the purpose of requirements prioritization, within the entire

document we distinguish the following classes of requirements:

Essential requirements which include critical points that must be accomplished

for the implementation of the ACCESSIBLE system components.

Desirable requirements that would enhance the ACCESSIBLE components,

but that are not essential for the project

Optional requirements that are facultative for the project.

These system requirements will derive from the analysis of a variety of issues and will

describe the means that will aid in order to obtain the needs that derive from the use

cases. Secondly, the system itself poses a number of limitations and requirements that

need to be fulfilled.

The ACCESSIBLE System Requirements are organized as it follows:

General functional and non-functional requirements for all ACCESSIBLE

components.

Specific functional and non functional requirements (where applicable) for:

The Assessment simulation module

The Ontological knowledge resource

The User Interface

The Developer/designer–aid module

The EARL-based reporting module

4.3 ACCESSIBLE Architectural scheme

The ACCESSIBLE architecture specifically addresses concerns about accessibility

assessment and it comprises independent modules that can interact with each other

(see Figure 28).



Figure 28: ACCESSIBLE architecture

The Assessment Simulation module will support the overall analysis and

verification in terms of accessibility for Web applications, Web services mobile

applications and description languages (UML, SDL, etc.). The module, which

takes input from the ACCESSIBLE knowledge resource, will be composed of

independent accessibility assessment tools in order to support the overall

accessibility assessment process. This module includes:

- A Web applications assessment tool for the accessibility verification of

Web applications

- A Web services assessment tool for the accessibility verification of Web

services

- A mobile applications Assessment Module for the accessibility verification

of mobile web applications

- A description languages assessment tool for the accessibility verification

of description languages

In terms of appearance, the ACCESSIBLE user interface can be thought of as a

hyper-portal where developers can use the Web based services of the

ACCESSIBLE components to download the standalone modules and finally to

extract useful information for accessibility guidelines, standards, etc. That said

access will take place using a common Internet browser. Where appropriate, Web

based versions of the ACCESSIBLE tools will be supported in addition to



standalone applications and/or plug-ins for appropriate Integrated Development

environments (IDE) such as Netbeans.

The open source developer & designer’s aid module which can support users to

facilitate the design and development of accessible software applications.

ACCESSIBLE target user groups (developers, designers, etc.) will be supported

with specific tool(s) for the desing and development of accessible software

applications. These tool(s) will be based on already existing open-source software

architectures and technologies from SUN, such as the NetBeans IDE, JAAPI, etc.

To overcome the gap between developer‟s knowledge on accessibility issues and

the development of accessible and tailored software applications, the

ACCESSIBLE knowledge resource (multilayer ontological framework as

depicted in the Figure 29) will be implemented. This framework will provide a set

of domain ontologies to describe users with disabilities, accessibility guidelines

and well known standards, assistive devices as well as how these concepts can be

integrated to form the semantic accessibility assessment of software applications

through appropriate SWRL (Semantic Web Rule Language) and SPARQL rules

and queries.

Figure 29: ACCESSIBLE multilayer ontological framework

The Evaluation and Reporting Language (EARL)-based reporting tool in

order to export accessibility evaluation results in a form helpful to potential

receivers of test results, include designers, developers and business stakeholders.

The EARL which has been proposed by W3C evaluation and Repair Tools

Working Group (ERT WG) is a language to express test results such as bug



reports and conformance claims, and enables any person, entity, or organization to

state test results for anything tested against any set of criteria.

4.4 General requirements of ACCESSIBLE system

This section considers general requirements covering the general behaviour of the

ACCESSIBLE system (thus not derived from technological constraints), but describe

problems and functionalities that the system has to deal with.

This section briefly summarises the general requirements of the ACCESSIBLE

system as a result of the first review of Project aims as described in the Technical

Annex of the Project and a comparison with the scientific vision provided at the

beginning of WP2.

A critical analysis of the most important issues is reported in the form of questions:

the following chapters include – both at general and specific levels – the answers

provided so far to the questions reported below, considering that some of them will be

clearly solved only during either at the development phase or after first tests and

evaluations.

Text in italics is quoted from the Technical Annex:

The system addresses the need for better reliable and harmonised

methodological approaches and tools for accessibility assessment of

applications and services;

o Compliance with current accessibility standards is necessary to manage

“future” accessibility assessment ICT applications and clear “better”

added-values must be defined;

a set of rules will be developed in order to describe the different accessibility

checks of different application domains assists users in including accessibility

constraints

o What degree of “assistance” should be envisaged? What kinds of rules

can be defined and applied? What type of knowledge is needed?

the system includes a multilayer ontology knowledge to provide a set of

standards, definitions for tool capabilities, accessibility guidelines assigned to

specific preferences and disabilities of disabled users, accessibility standards

or laws;

o How is it possible to evaluate correctly the impact of the customisation

of the multilayer ontology knowledge? Should semantics be limited

only to the description of accessibility guidelines, or should they be

extended to cover assistive devices description and other accessibility-

related contextual information?

o How “huge” is the volume of information actually for the pilot

applications? What kind of “filters” can be applied to allow users to

interact with the system without being overwhelmed by technical and

computational issues?

The EARL based Reporting module will export results in a form helpful to

potential receivers of test results, including designers, developers and

business stakeholders



o What kind of knowledge should be presented to users? What actions

could be taken by the users on the basis of the results analysis?

The integration of combinations of many possible disabilities, rather than on

an individual basis.

o How do we design for a person with both a hearing and sight loss, or a

blind person with only one hand? What kind of disabilities will be

supported within ACCESSIBLE? Do you need to include functional

limitations?

To research and develop a developer/designer-aid framework in order to

involve appropriate accessibility standards and methodologies within software

development processes

o Which accessibility parameters and contextual information (e.g. kind

of disabilities, type of applications, etc.) should be monitored? What

type of information should be provided to users by the developer-

designer aid module? Do we need to implement a tool that can be

integrated as plug-in to IDE environments for developers (e.g.

NetBeans) or it should be efficient to develop a standalone tool?

To better understand why some software products are accessible while others

are not

o Why the implemented standards around accessibility are somewhat

confusing and incomplete for developers and designers? What kind of

knowledge is needed for the implementation of accessible

applications?

It will be integrated with appropriate tools that will be modified and further

improved (ASK-IT alignment tool, SET, SAFIRE, Sun’s a11y Netbeans

accessibility tool, etc.).

o How can these tools be reasonably integrated within ACCESSIBLE?

Which are the requirements of these tools? What types of mechanisms

should be envisaged to provide users with efficient and usable features

for the accessibility assessment of applications?

It is important to consider the possibility of providing developers with a tool

for the accessibility assessment of different types of applications (Web,

Mobile, Web services, Description Languages);

o What about the accessibility of other applications than the Web? How

to apply this approach to different application domains? What types of

“usage” and “assessment” can be envisaged for different users of

disabilities?

Stating that the ACCESSIBLE project should present the accessibility tools,

methodologies and services in a manner readily available not just to IT experts but

also to a wide group of generic potential users, it is possible to point out some basic,

general requirements whose relevance should guide the whole design and

development of accessible code, solutions and, in particular, user interfaces (UIs).

The envisaged ACCESSIBLE components should be:

User-centric;



easy to use;

easy to manage;

easy to configure;

performance-oriented

Once more, the above mentioned requirements clearly highlight the different classes

of possible ACCESSIBLE users, i.e. application developers, end users with

disabilities, accessibility assessors, service providers and public bodies. The “easy-to”

requirements apply to all classes whereas some others (the last two in the list) are

evidently related only to the technical context.

4.4.1 Generic functional requirements

G-REQ1-1: The system shall support developers and designers to assess the

accessibility of their developed applications via the ACCESSIBLE assessment

module.

G-REQ1-2: The system shall provide users with detailed accessibility instructions

and guidelines for the implementation of accessible Web, Mobile applications, Web

services and/or description languages.

G-REQ1-3: Where appropriate, the system shall allow the definition of accessibility

terms and constraints using ontology based description languages and different

domain ontologies.

G-REQ1-4: The system shall enable an easy reconfiguration of accessibility

assessment processes

G-REQ1-5: The system shall provide appropriate tools to developers and designers to

simulate their developed applications with visual impairments via the developer-

designer aid module.


accessibility standards, such as WCAG 1.0, WCAG 2.0, Section 508, etc and also

modify the existing ones or add new ones.


stored accessibility standards or guidelines, such as WCAG 1.0, WCAG 2.0, Section

508.

G-REQ1-8: The system shall take into account some of most widely known mobile

content standards, such as MWBP 1.0, etc. and also modify the existing ones or add

new ones.

G-REQ1-9: The system shall support different potential users (developers, designers,

IT managers, etc.) to test its developments against any set of selected accessibility

criteria and/or rules specified by users.

G-REQ1-10: The ACCESSIBLE system shall support the implementation of

appropriate rules based on the ACCESSIBLE knowledge resource and on user‟s

preferences.



G-REQ1-11: The ACCESSIBLE system shall support personalised accessibility

assessment functionalities that must cope with user‟s disabilities and individual‟s

preferences.

G-REQ1-12: The system shall support developing/assessing for a variety of

disabilities and functional limitations (based on the ICF categorization). At least

visual, auditory, and hearing disabilities should be taken into account.

G-REQ1-13: Where appropriate, each user preferences shall combine different kind

of disabilities, assistive technologies and accessibility standards.

G-REQ1-14: Where appropriate, the developers or the system users shall receive

appropriate reports concerning the results of their accessibility tests based on the

EARL language.

4.4.2 Performance requirements

P-REQ1-1: Average system response time shall be in proportion with the complexity

of the objects that are being tested.

P-REQ1-2: ACCESSIBLE assessment modules shall support hundreds of simple

queries per minute, where simple queries are defined as access to centrally ontology-

stored data using typical, predefined rules.

4.4.3 Operational requirements

O-REQ1-1: Where appropriate ACCESSIBLE system components shall be able to

generate automated help wizards and error messages in case of system malfunctions

and/or users‟ mistakes.

O-REQ1-2: Colours and contrasts shall be in accordance to general usability and

accessibility guidelines.

O-REQ1-3: A help menu shall exist, that will facilitate the user understand the

operation of the system, and guide him along the process.

O-REQ1-4: All system components shall be easy to navigate to people with different

knowledge and capabilities (developers, designers, testers, etc.)

4.4.4 Reliability requirements

Reliability of the ACCESSIBLE platform has been considered a major issue by the

consortium. The IEEE defines reliability as “the ability of a system or component to

perform its required functions under stated conditions for a specified period of time”.

To most project and software development users, reliability is equated to correctness,

that is, they look to testing and the number of “bugs” found and fixed. While finding

and fixing bugs discovered in testing is necessary to assure reliability, a better way is

to develop a robust, high quality product through all of the stages of the software

lifecycle. The terms errors, faults and failures are often used interchangeable, but do

have different meanings. In software, an error is usually a programmer action or

omission that results in a fault. A fault is a software defect that causes a failure, and a

failure is the unacceptable departure of a program operation from program

requirements. When measuring reliability, we are usually measuring only defects

found and defects fixed. If the objective is to fully measure reliability we need to

address prevention as well as investigate the development starting in the requirements

phase – what the programs are developed to.



R-REQ1-1: Most of ACCESSIBLE modules shall provide diagnostics messages in

case of unsuccessful or uncertain operations.

4.4.5 Maintainability & Interoperability requirements

M-REQ1-1: All software modules (Assessment modules, aid module, ontologies)

developed in the project will be released under an open source licence.

M-REQ1-2: The ontology schema will provide some extensibility to ACCESSIBLE

components in order to address both the heterogeneity of the data and the fact that

new forms of data may appear after the duration of the project

M-REQ1-3: All system components will be implemented in modular, open source

system architecture

M-REQ1-4: ACCESSIBLE framework shall be based on a layered solution with a

high level of encapsulation of components to assure the maintainability of the

infrastructure with future upgrades.

M-REQ1-5: All software assessment modules developed in the project will be offered

through Web services from the ACCESSIBLE portal.

4.5 ACCESSIBLE Assessment Simulation Module Requirements


G-REQ2-1: The Web assessment simulation module shall test the accessibility of

applications according to the guidelines of widely accepted accessibility standards

(e.g., WCAG1, WCAG2, Section 508, etc) where appropriate.

G-REQ2-2: All assessment simulation modules shall connect with the ontology and

run all the SWRL rules defined in the ontologies.

G-REQ2-3: All assessment simulation modules shall be able to get the instances of

all the classes defined in the ontologies and present them in an appropriate GUI.

G-REQ2-4: The assessment simulation module shall give user the opportunity to

define the tests that will be executed according to specific selections made in some

pre-defined categories (user, device, disability, functional limitation, application, etc)

as these categories and their relationships defined in the ontology.


assessment of HTML Web applications.


assessment of (HTML) Web applications generated from different server-side

environments, languages or technologies (PHP, ASP, JSP, etc.)

G-REQ2-7: In the Web assessment module, the co-operation of the module with the

ontology will be performed using Groovy scripts.

G-REQ2-8: In the ACCESSIBLE assessment modules, the SPARQL queries that

will be executed will be defined in separate text files with .sparql extension.







G-REQ2-11: The mobile assessment module shall verify how interaction input is

performed in the application, and how it influences accessibility issues.



G-REQ2-13: The Web Services assessment tool should enable the integration of the

modified ASK -IT alignment tool

G-REQ2-14: The SDL assessment tool should enable the integration of the SAFIRE

platform for the parsing of SDL components.

G-REQ2-15: The Web assessment tool should enable the integration of the SET tool

for the visualisation of the assessment results

G-REQ2-16: The Web Services assessment tool will be able to evaluate accessibility

features of Web Services that follow the W3C‟s SOAP-based standardization.

G-REQ2-17: The Web Services assessment module will be able to evaluate

accessibility features of Web Services, using the SOAP-based WSDL files defining

them.

G-REQ2-18: The Web Services assessment module should be able to read the types

of WSDL files (WSDL parser) that are used by the majority of working SOAP-based

Web Services.

G-REQ2-19: The user shall be able to select manually one by one all the tests that

will be executed.

G-REQ2-20: The assessment simulation modules after the assessment completion

shall output the results in EARL format

G-REQ2-21: The description languages assessment tool should be able to evaluate

accessibility features for designs/systems based on the SDL-2000 standard.

G-REQ2-22: The description languages assessment module should be able to read

and parse the types of SDL files that are based on SDL-2000 using an SDL parser.

G-REQ2-23: The Web assessment module shall work in two different modes for

HTML applications:

-single web page assessment

-entire web site assessment

G-REQ2-24: If the overall web application mode is being chosen, there shall be an

option defining the maximum number of web pages that will be examined.

G-REQ2-25: The mobile assessment module shall accept a compiled application (e.g.

JAR file) for verifying the accessibility of native mobile applications.

G-REQ2-26: The assessment module shall work in two different modes for Mobile

applications:

- Mobile Web page automated assessment

- Mobile Web site automated assessment



G-REQ2-27: The description languages assessment module shall accept as input files

with relevant file extensions (e.g. “*.pr”, “*.fsm”) for verifying the accessibility of

SDL systems/designs.

G-REQ2-28: The description languages assessment module shall include a software

sub-system capable to parse SDL designs based on the SDL-2000 standard.


P-REQ2-1: The web application assessment tool shall be able to handle web sites

with at least 50 single pages) at a reasonable time for the user and depending on time

constraints of the located server which hosts the web sites.

P-REQ2-2: The description languages assessment module shall be able to parse files

containing complex SDL designs (consisting of many blocks, processes, states, inputs,

outputs, timers etc.) at a reasonable time for the user and less than 3 minutes time.

P-REQ2-3: The Web services assessment module shall be able to parse files

containing complex web services at a reasonable time for the user and less than 3

minutes time.

P-REQ2-4: If a Web based version will be developed for the Web assessment, it is

planned to support hundreds of simultaneous users.


O-REQ2-1: The tools should be taking care of visual aspects and be highly

interactive, in order to pursue users comfort ability.

O-REQ2-2: The tools shall be configurable and provide enough documentation, so

that a non-expert can learn how to use it.

O-REQ2-3: Where appropriate each non-recoverable error situation will be logged in

a log file with a detailed description of the error condition.


R-REQ2-1: The ACCESSIBLE assessment module shall provide diagnostics and

error messages in case of unsuccessful or uncertain operations.

R-REQ2-2: Where appropriate the assessment tools will be robust and shall recover

from connectivity failures with other modules


M-REQ2-1: The assessment module shall be able to provide sufficient and adequate

information regarding the evaluation results, in order for them to be able to be

presented to users through the EARL-based reporting tool.

M-REQ2-2: The development of the assessment module should be based on the

integration of existing tools such as the ASK-IT alignment tool or other open source

tools provided by ACCESSIBLE beneficiaries.

M-REQ2-3: All assessment simulation modules shall implement the interfaces to the

ontology and EARL tool subsystems.

M-REQ2-4: The description languages assessment module shall accept as input files

(e.g. “*.pr”, “*.fsm”) that include SDL systems/designs based on SDL-2000 standard.



M-REQ2-5: From the software perspective, all the code will be developed under an

open source approach. It should be the best licensing choice fitting the project. From

the reuse perspective, all developed applications and libraries should be open source.

4.6 ACCESSIBLE ontological Knowledge Resource Requirements

This part will address the requirements the ontology poses. Mainly, these

requirements are essential to Web developers who wish to interact with the ontology

and access it or even modify it.


G-REQ3-1: The ontology will support the OWL Web Ontology Language

G-REQ3-2: The ontology shall support the SWRL (a Semantic Web Rule Language)

rules, which form of an implication between an antecedent (body) and consequent

(head).

G-REQ3-3: The ontology shall support SPARQL queries that consist of triplets, in

order to narrow the information space of accessibility assessment according to

specified semantics of usage scenarios.

G-REQ3-4: In order to preserve the integrity and the maintenance of the ontology,

the ACCESSIBLE ontology based knowledge resource shall include generic and

domain-specific ontologies.

G-REQ3-5: The ACCESSIBLE ontology shall contain a generic version which

describes the general structure of accessibility attributes such as guidelines, users,

devices, and applications.

G-REQ3-6: The domain ontologies shall include different characteristics and

instances of accessibility standards, disabilities, functional limitations, devices and

application domains.

G-REQ3-7: All the domain ontologies shall comply with the generic ontology.



G-REQ3-9: The ontology shall include the most well known disabilities that people

face and for which accessibility guidelines provide clues on how they should be

supported in software applications.

G-REQ3-10: The ontology shall include a variety of assistive devices, which are used

from people with disabilities.

G-REQ3-11: The ontology shall incorporate different types of applications (such as

web services, HTML) that can be verified for their accessibility status.

G-REQ3-12: For the implementation of the ontologies, the Protégé ontology editor

will be used as well as the SWRL supporting plug-in.

G-REQ3-13: Adequate semantic description shall be provided from all the

characteristics that are included in the generic as well as in the domain ontologies.

G-REQ3-14: The execution of queries and rules shall be supported through the

integration of an open source inference engine that shall support the usage of

SPARQL as well as SWRL.




P-REQ3-1: Response times in communication of the ACCESSIBLE knowledge

resource with the assessment system shall be in line with those specified in the

communication protocol selected.

P-REQ3-2: In the same way, the inference engine in the complex rules and queries

execution shall also take into account the performance.


O-REQ3-1: The user shall be able to navigate through the ACCESSIBLE loaded

ontology.

O-REQ3-2: The user shall be able to search though the ontology in classes, properties

and instances.

O-REQ3-3: When displaying ontologies to the user via GUI, elements must be

ordered according to the part of the ontology being displayed.

O-REQ3-4: Developers or other users that have access to the ontology shall be

familiar with the basic ideas of OWL language.

O-REQ3-5: Developers or other users that wish to add new terms (such as a new

accessibility guideline) to the ontology shall use the independent domain ontologies

and comply with the generic ontology attributes.


R-REQ3-1: The ontology-based resource shall provide answers just for the

knowledge embedded in ontologies (both general and domain-specific). All

knowledge not represented will be regarded as unknown, not as false (i.e. open-world

assumption).


M-REQ3-1: Developers shall be able to specify new SWRL rules and/or SPARQL

queries through a special purpose GUI.

M-REQ3-2: All ontologies should be developed in a way that knowledge can be

interchanged between different Operating Systems and different knowledge

management systems. For this, the ontological resource will be developed with

standardised and open technologies and languages, including RDF, OWL, SWRL, and

SPARQL.

M-REQ3-3: The knowledge inference engine must be interoperable and cope with

open technologies. For this, it will be developed using open source knowledge

software components developed in portable languages (e.g. Java).

M-REQ3-4: In this same way, the ACCESSBILE knowledge resource and the

developed inference engine as well as the rules editor shall be enough documented in

order to be understandable for users external to the development.

4.7 ACCESSIBLE User Interface Requirements

A list of specific requirements for the interface of all users of the ACCESSIBLE tools

is presented. Where appropriate, Web based versions of the ACCESSIBLE tools will

be supported in addition to standalone applications and/or plug-ins for appropriate



Integrated Development environments (IDE) such as Netbeans. It is more than clear

that some of the users of the ACCESSIBLE components could belong to a special

group of people that are extremely familiar to the design and development of

Information Technology products. However, the user interface requirements need

special attention in order to support not only expert users but also simple users that

would like to use ACCESSIBLE tools and services and/or become familiar with

accessibility constraints and terms. In terms of appearance, ACCESSIBLE Web User

Interface can be thought of as a hyper-portal (by using a common Internet browser

)where developers can use the Web based services of the ACCESSIBLE components,

as well as to download the standalone modules and finally to extract useful

information for accessibility guidelines, standards, etc.

4.7.1 User Interface Portal

4.7.1.1 Generic functional Requirements

G-REQ4.1-1: The User Interface of ACCESSIBLE portal shall be user friendly that

means that the uses must locate the required information on the screen easily. Also the

portal will be accessible to everyone.

G-REQ4.1-2: The Web based Interface shall provide to users the ability to assess web

sites, web applications and mobile applications via their URL.

G-REQ4.1-3: Users shall have the option to download the standalone tools developed

in the context of ACCESSIBLE (Net Beans IDE plug-ins, the accessible assessment

and simulation module etc).

G-REQ4.1-4: The User Interface shall provide information about the goals of

ACCESSIBLE project.

G-REQ4.1-5: The User Interface shall provide clear instruction before and during

interaction.


resource utilisation of the ACCESSIBLE tools and services.

G-REQ4.1-7: The User Interface shall provide all the useful information to web

developers (such as standards and guidelines) in order to create accessible

applications.




G-REQ4.1-9: Where appropriate the User Interface shall be designed in accordance

to the project‟s logo and colours and contrast shall comply with the usability

guidelines.

G-REQ4.1-10: Users should have the option to subscribe to the portal providing their

personal information and therefore get access to the facilities offered to subscribed

users.

G-REQ4.1-11: Registered users should have access to a number of chat rooms with

different thematology and have the option to participate to online real-time

discussions taking place into the existing chat rooms.



G-REQ4.1-12: Registered users should have the option to access resources and

training material related to the development and evaluation of accessible applications

in various contexts.

G-REQ4.1-13: Users should have the option to perform keyword based search for

resources.

G-REQ4.1-14: Registered users should have the option to personalise the way that

knowledge is displayed through the existence of facilities such as “knowledge

profiles”.


collection of knowledge offered by the portal.


collection of training material offered by the portal.

4.7.1.2 Performance requirements

P-REQ4.1-1: The ACCESSIBLE platform should work fine also when the users are

connected with a low bandwidth network. It is important that the system promptly

communicates changes to accessibility tools, guidelines, methodologies, etc.

Therefore the main aspect is to have limited time response from the system even if the

connection speed is slow and even if the number of the user connected is large.

4.7.1.3 Operational requirements

O-REQ4.1-1: When electronic forms are designed to be completed on-line, the form

shall allow people using supporting technology to access the information, field

elements, and functionality required for completion and submission of the form,

including all directions and cues.

O-REQ4.1-2: A method shall be provided that permits users to skip repetitive

navigation links.

O-REQ4.1-3: When a timed response is required, the user shall be alerted and given

sufficient time to indicate more time is required.

O-REQ4.1-4: The access to the system must be realized in a one step procedure.

O-REQ4.1-5: The platform must provide all the information to the end-user in a

small number of steps.

4.7.1.4 Reliability requirements

R-REQ4.1-1: The User Interface when combined with the appropriate hardware

architecture and infrastructure, multi-tier architectures can provide the means for

faultless and continuous operation.

4.7.1.5 Maintainability & Interoperability requirements

M-REQ4.1-1: Multi-layer architecture of the User Interface will make feasible the

generation of software that is scalable and maintainable allowing the separation of

application logic from the User Interface and application data.

M-REQ4.1-2: Multiple layers support the development of alternative top layers for

different computer platforms.



4.7.2 Stand alone tools user interface

4.7.2.0 Generic functional Requirements

G-REQ4.2-1: The User Interface of the stand alone tools (Web assessment, Mobile

assessment, Web services and DL) should be both powerful and intuitive to use in

order to facilitate both novice and experienced users.

G-REQ4.2-2: The user interface should provide appropriate organisation of

evaluation sessions in order to be able to facilitate both the evaluation of single

documents and collections of documents such as web sites residing on the local

computer, collection of web services etc.

G-REQ4.2-3: Users should have the option to save the specific details of each of their

evaluation sessions.

G-REQ4.2-4: Users and especially developers should be provided with functionality

that meets the one provided by other popular developer oriented tools.

G-REQ4.2-5: The user interface shall provide the option to preview the source code

of the evaluated applications.

G-REQ4.2-6: The user interface shall provide the option to preview the evaluated

documents using the most appropriate tools available according to the document

format.

G-REQ4.2-7: The user interface should provide users the ability to select among a

number of settings in order to define the targets of each evaluation putting on the

hands of the tool the matching of these setting to specific guidelines and tests.

G-REQ4.2-8: The user interface should provide users the ability to manually select

among a number of guidelines the ones to be used for performing the evaluation.


resource utilisation of the ACCESSIBLE tools.

G-REQ4.2-10: Users should have the option to operate the stand alone tool without

the need of a connection to the internet.

G-REQ4.2-11: Users should have the option to access several different views of the

evaluation results.

4.7.2.1Performance requirements

P-REQ4.2-1: The ACCESSIBLE platform should be able to work fine also for low

end computers. Therefore the main aspect is to have limited time response from the

system.

P-REQ4.2-2: For time consuming operations the user should be provided with input

regarding the progress of this operation and the amount of time needed to completion

P-REQ4.2-3: For repetitive execution of similar operations no recalculation of data

should occur.

P-REQ4.2-4: User should always have the option to quit an ongoing operation.



4.7.2.2 Operational requirements

O-REQ4.2-1: When a timed response is required, the user shall be alerted and given

sufficient time to indicate more time is required.

O-REQ4.2-2: All the tasks performed by the system should require the minimum

possible number of steps.

O-REQ4.2-3: When feasible alternative ways for performing an operation should be

provided.

O-REQ4.2-4: User should have the maximum flexibility on customising his work

space according to his requirements.

O-REQ4.2-5: User should have the maximum flexibility on viewing the documents

contained in his work space.

4.7.2.3 Reliability requirements

R-REQ4.2-1: The user interface should be stable and forgiving to user error.

R-REQ4.2-2: The user interface should be tolerant to errors.

R-REQ4.2-3: When a time consuming operation is carried out the interface should

still remain active.

4.7.2.4 Maintainability & Interoperability requirements

M-REQ4.2-1: The user interface should be able to establish seamless communication

and collaboration with the ACCESSIBLE core evaluation components.

M-REQ4.2-2: The user interface of the stand alone tool should be loosely coupled

with the ACCESSIBLE core architecture allowing the possibility of change in the

lower architectural layers.

4.8 ACCESSIBLE Developer/designer–aid module Requirements

G-REQ5-1: The module shall help the developer/designer to ensure his application is

accessible and usable to impaired users.

G-REQ5-2: The module will provide the means to simulate different low vision

impairments, such as loss of central or peripheral vision.

G-REQ5-3: The module will provide the means to simulate the most common low

vision impairments, such as cataract or glaucoma.

G-REQ5-4: The module will provide the means to simulate the most common color-

blindness impairments, such as protanomaly or deuteranomaly.


developed as a plug-in that can be included into the Netbeans IDE and the other as a

standalone application.

G-REQ5-6: The module will provide the means to simulate different upper limp

impairments, such as Parkinson disease.




P-REQ5-1: The module should be able to simulate the desired impairment within a

matter of seconds.


O-REQ5-1: The plugin version of the module should aid the developer/designer

during the development phase to handle at least Swing GUI applications.

O-REQ5-2: The module should give the user the ability to select any of the supported

impairments.

O-REQ5-3: The user should be able to control any factors, such as color, size or

severity level, that affect the selected impairment.

O-REQ5-4: The module should be able to simulate one impairment at a time.

O-REQ5-5: The module should be able to simulate a combination of two or more

user selected impairments.

O-REQ5-6: The module should be able to handle static and dynamically changing

GUIs and simulate any impairment interactively.


M-REQ5-1: It should be easy to add a new impairment or update an existing one to

the module.

M-REQ5-2: The module shall be able to run in any JavaSE enabled system (with

JavaSE 6.0 or above).

M-REQ5-3: The module shall be able to run in any operating system that supports

JavaSE, including Windows, Macintosh, OpenSolaris, or Linux.

M-REQ5-4: The module should be taking care of visual aspects and be highly

interactive, in order to pursue users comfort ability. In addition the tool shall be

configurable and provide enough documentation.

4.9 ACCESSIBLE EARL-based reporting tool Requirements

4.9.1 Generic Functional requirements

G-REQ6-1: The EARL-based reporting tool shall be used in order to present the

results of the Accessibility Evaluation in a standardized and easy-to-understand way.

G-REQ6-2: The EARL-based reporting tool will incorporate terms and constraints

from the W3C Evaluation and Report Language.

G-REQ6-3: The EARL-based reporting tool shall contain a group of labels in order to

identify the person who or the tool that carried out the test, as well as when the test

was carried out, or information about the platform and configuration in which the test

was executed.

G-REQ6-4:The EARL-based reporting tool shall also provide information about the

subject that is being evaluated and could be a piece of a software code, a document,

Web content (such as Web pages, videos, applets, etc.) or software (such as

accessibility checkers, validators, user agents, etc.).



G-REQ6-5: The EARL-based reporting tool shall provide information about the test

criteria against which a subject is being evaluated.


outcome of a test conducted on a subject.

G-REQ6-7: The test result can contain information such as the success or failure of

the test, a confidence indicator for the obtained results, the reason for failing, or other

attributes.

G-REQ6-8: The test result shall include both machine-readable values as well as

human-readable description of the results.

G-REQ6-9: Any extensions to the EARL vocabulary must ensure the integrity and

validity of the core EARL vocabulary

G-REQ6-10: The tool shall provide built-in extensions of its core vocabulary at least

to the domain of Web accessibility evaluation.


P-REQ6-1: Generated reports shall be user oriented. For example reports for Web

developers may contain more detailed results in order to repair bugs while reports

generated for project managers may contain aggregated results with less detail on the

specific issues

4.10 Ranking of system requirements

Requirements Reference Essential Desirable Optional

General requirements of ACCESSIBLE system

Generic Functional Requirements

G-REQ1-1

G-REQ1-2

G-REQ1-3

G-REQ1-4

G-REQ1-5

G-REQ1-6

G-REQ1-7

G-REQ1-8

G-REQ1-9

G-REQ1-10

G-REQ1-11

G-REQ1-12

G-REQ1-13

G-REQ1-14




Performance

P-REQ1-1

P-REQ1-2

Operational

O-REQ1-1

O-REQ1-2

O-REQ1-3

O-REQ1-4

Reliability

R-REQ1-1

Maintainability & Interoperability

M-REQ1-1

M-REQ1-2

M-REQ1-3

M-REQ1-4

ACCESSIBLE Assessment Simulation Module Requirements


G-REQ2-1

G-REQ2-2

G-REQ2-3

G-REQ2-4

G-REQ2-5

G-REQ2-6

G-REQ2-7

G-REQ2-8

G-REQ2-9

G-REQ2-10

G-REQ2-11

G-REQ2-12

G-REQ2-13

G-REQ2-14

G-REQ2-15




G-REQ2-16

G-REQ2-17

G-REQ2-18

G-REQ2-19

G-REQ2-20

G-REQ2-21

G-REQ2-22

G-REQ2-23

G-REQ2-24

G-REQ2-25

G-REQ2-26

G-REQ2-27

G-REQ2-28

Performance

P-REQ2-1

P-REQ2-2

P-REQ2-3

P-REQ2-4

Operational

O-REQ2-1

O-REQ2-2

O-REQ2-3

Reliability

R-REQ2-1

R-REQ2-2


M-REQ2-1

M-REQ2-2




M-REQ2-3

M-REQ2-4

M-REQ2-5

ACCESSIBLE ontological Knowledge Resource Requirements


G-REQ3-1

G-REQ3-2

G-REQ3-3

G-REQ3-4

G-REQ3-5

G-REQ3-6

G-REQ3-7

G-REQ3-8

G-REQ3-9

G-REQ3-10

G-REQ3-11

G-REQ3-12

G-REQ3-13

G-REQ3-14

Performance

P-REQ3-1

P-REQ3-2

Operational

O-REQ3-1




O-REQ3-2

O-REQ3-3

O-REQ3-4

O-REQ3-5

Reliability

R-REQ3-1


M-REQ3-1

M-REQ3-2

M-REQ3-3

M-REQ3-4

ACCESSIBLE User Interface Requirements - User Interface Portal


G-REQ4.1-1

G-REQ4,1-2

G-REQ4.1-3

G-REQ4.1-4

G-REQ4.1-5

G-REQ4.1-6

G-REQ4.1-7

G-REQ4.1-8

G-REQ4.1-9

G-REQ4.1-10

G-REQ4.1-11




G-REQ4.1-12

G-REQ4.1-13

G-REQ4.1-14

G-REQ4.1-15

G-REQ4.1-16

Performance Requirements

P-REQ4.1-1

Operational Requirements

O-REQ4.1-1

O-REQ4.1-2

O-REQ4.1-3

O-REQ4.1-4

O-REQ4.1-5

Reliability Requirements

R-REQ4.1-1


M-REQ4.1-1

M-REQ4.1-2

ACCESSIBLE User Interface Requirements – Standalone User Interface


G-REQ4.2-1

G-REQ4.2-2

G-REQ4.2-3

G-REQ4.2-4

G-REQ4.2-5




G-REQ4.2-6

G-REQ4.2-7

G-REQ4.2-8

G-REQ4.2-9

G-REQ4.2-10

G-REQ4.2-11

Performance Requirements

P-REQ4.2-1

P-REQ4.2-2

PG-REQ4.2-3

P-REQ4.2-4

Operational Requirements

O-REQ4.2-1

O-REQ4.2-2

O-REQ4.2-3

O-REQ4.2-4

O-REQ4.2-5

Reliability Requirements

R-REQ4.2-1

R-REQ4.2-2

R-REQ4.2-3


M-REQ4.2-1

M-REQ4.2-2

ACCESSIBLE Developer/designer–aid module Requirements





G-REQ5-1

G-REQ5-2

G-REQ5-3

G-REQ5-4

G-REQ5-5

Performance

P-REQ5-1

Operational

O-REQ5-1

O-REQ5-2

O-REQ5-3

O-REQ5-4

O-REQ5-5

O-REQ5-6


M-REQ5-1

M-REQ5-2

M-REQ5-3

M-REQ5-4

ACCESSIBLE EARL-based reporting tool Requirements


G-REQ6-1

G-REQ6-2




G-REQ6-3

G-REQ6-4

G-REQ6-5

G-REQ6-6

G-REQ6-7

G-REQ6-8

G-REQ6-9

G-REQ6-10

G-REQ6-11

Performance

P-REQ6-1

P-REQ6-2

Table 36: Ranking of ACCESSIBLE system requirements


(Final Draft) -103- SUN

5 Conclusions

This deliverable presents both the methodology for the user needs and the

requirements definition for the ACCESSIBLE system components. The initial User

needs and system Requirements specification from the Deliverable D2.2.a have been

reviewed and carefully tuned on the basis of the analysis of the results collected by

project beneficiaries in tight collaboration with project stakeholders (developers, end

users, service providers, accessibility assertors and public bodies) whose feedback has

been evidently improved and analysed though this deliverable.

The information included in this deliverable should allow the developers to start (in an

efficient way) the implementation of the ACCESSIBLE framework by providing

valuable hints on:

how to keep developed solutions compliant with the initial objectives of the

project;

how to ease the integration and deployment of the first prototype and to speed

up the test and validation phase.

In this deliverable, a scientific vision of the project defines the “technological offer”

that the system is able to provide to end users and delineates the overall guidelines for

user requirement specification. The requirements definition means an important stage

of the project since it sets the grounds and is useful for the architecture design and the

components development stages.

From this scientific vision emerges a picture of the typical services, tools and

methodologies that can be supported by ACCESSIBLE and the typical problems it

should face.



Annex 1: Methodology for User Needs Questionnaires

Creation and Evaluation

The questionnaires

Before initiating the questionnaire survey, partners agreed on following aspects:

- The target groups of the evaluation: developers, accessibility assessors, elderly

and people with disabilities, public bodies, and service providers

- The size of the sample: about 50 interviews per questionnaire

- The issues to be addressed: these range from specific education background to

what assistive technologies are normally used, etc.

- Type of questions and answers: Multiple choice questions, open questions.

- Duration of data collection: Initially end of June 2009 was set as deadline, but

partners agreed that after this deadline there will be a continuation of the data

collection. The additional data will be analysed at a later stage also in the

project.

Based on the above, WP2 partners defined 5 specific questionnaires, 1 for each target

group, and had these also translated in different languages: German, Greek,

Portuguese, Italian, Bulgarian and English.

The questionnaires were then provided online via the project website

(http://www.accessible-project.eu/index.php/questionnaire.html), and could

additionally be downloaded and printed in each language as a pdf-document. As such,

each project partner was able to download and print the questionnaires for face-to-

face-interviews in case the internet forms were not used.

Survey format

As we are dealing with heterogeneous target groups it is important to choose the

appropriate survey format.

A mere online survey, without an interviewer, is to be recommended if members of a

special population are surveyed who are familiar with such online methods of data

gathering. At the same time, interviewer mistakes (subjective entries) are being

avoided. However, online surveys should only be implemented if it can be expected

that interviewers can only as such reach members of the sample who otherwise cannot

be reached. It can, for example, be expected that the target groups “Service Provider”,

“Accessibility Assessors” and “Public Bodies” have only limited possibility to

participate in an online survey.

http://www.accessible-project.eu/index.php/questionnaire.html



Personal face-to-face interviews are recommended if one can assume that the

presence of an interviewer motivates the target group to participate in the survey.

Personal interviews provide room for asking questions and for clarifying ambiguities

and uncertainness. At the same time, the interviewee feels that their participation is

essential for the result of the research.

It was agreed for interviews with developer and service providers to take place online,

and to some extent also with public bodies and accessibility assessors. Interviews with

elderly and people with disabilities should be mainly face-to-face. For data analysis

purposes however, all collected data will be entered online afterwards by the

interviewers.

Survey propagation

These questionnaires have been propagated via various other channels, such as for

example the Disability Now portal in Greece, thus reaching a vast group of end-users

with disabilities, but also via the e-Inclusion Newsletter (12/06/2009), and the

European ePractice Newsletter (N. 282 - 9 June 2009).

Equally, the project also organised a mailing to all relevant stakeholders as identified

in D8.1a “Dissemination plans and materials”, and which are described in the Target

Groups.

Some examples of the online propagation are presented in following screenshots:

Figure 30: Questionnaire overview, available online via http://www.accessible-

project.eu/index.php/questionnaire.html





Figure 31: Article on Disabled.gr to attract participants - http://www.disabled.gr/lib/?p=20322

Figure 32: Article in e-Inclusion Newsletter - 12/06/2009



Figure 33: Article in European ePractice Newsletter N. 282 - 9 June 2009



Construction of the Questionnaires

Content of the Questionnaires

To ensure a higher willingness of the interviewees to participate, the questions were

arranged according to a “rising action”:

- the general questions came first, and then the particular

- the familiar issues were addressed first and then the unfamiliar

- the difficult issues came after the familiar (read: simple) issues

- any individual issues were addressed at the end

This meant concretely that 4 question groups had to be created:

- Functional questions which were asked at the very beginning and that had to

decrease any potential prejudices by the interviewee.

- Factual questions that constituted the main part of the questionnaire.

- Control questions that verified the interviewee‟s answers for consistency

- Personal questions to collect socio-demographic data.

The questionnaires were for every target group created according to an agreed set of

question categories. Questions about the same issue were the same for all target

groups, however they were not necessary on the same place in the questionnaires.

This ensured an optimal comparability and reproducibility.

Following the above mentioned approach, following data had to be collected:

- Questionnaire for Elderly and Disabled users

o ICT usage: These questions aim at understanding the usage of various

hardware devices (laptops, desktop PCs, etc.) privately, or in a

business environment, and how intensively this was. Also, the actual

usage was assessed (internet, gaming, etc.), and whether any AT

(Assistive Technology) was being used with it.

o ICT training and support: Considering the fact that training and

support is often a tricky issue for end-users, questions were also

inserted that aimed at understanding the level of training and support

end-users had (not) followed or received.

o Internet: The Internet usage was assessed through a series of questions

that aimed at understanding the usage patterns, and the problems

people faced when using it.

o Demographic data: The questionnaire was completed with the

collection of some personal data such as age, gender, professional



status, impairment type, and any memberships in representative

organisations.

- Questionnaire for Developers

o Accessibility: These questions aim at understanding the meaning of

accessibility and usability. Questions about work experience (dealing

with accessibility etc.), vocational training about accessibility as well

as familiarity with guidelines and standards permit an overview about

the dispersal of accessibility.

o Job and Professional Knowledge: With this sample of questions, the

framework requirements of the interviewee´s job are specified, as well

as in which way appropriate accessibility standards and methodologies

are involved within software development processes. A collection of

questions about the company, the interviewee´s working position as

well as his development work is presented to the interviewee. This is

completed with questions about the involvement of accessibility

standards and methodologies and their intensity within software

development processes.

o Accessible specific: A developer most likely knows about his lack of

knowledge about e.g. accessibility standards and accessible software

developments. Therefore, he is asked about his wishes about a

developer-aid framework.

o Personal experience: At the end, software development is influenced

by the personal experience of the developer with impaired people. It

might therefore be of interest if the interviewee knows people who

need assistive technologies for ICT usage as well as which kind of AT

they use. Here the developer can describe in free text how he thinks

that his knowledge concerning accessibility for software

implementations affects his work.

o Demographic data: The questionnaire also collects some personal

data such as age, gender, professional status, impairment type, and job

qualification.

- Questionnaire for Accessibility Assessors

o Accessibility: As a target group which advocates the needs of people

with impairments and assess the accessibility of services offered or

developed, they are asked about their understanding of the meaning of

accessibility and usability, including their familiarity within

international guidelines and standards. Also the application areas (tests

of web accessibility, desktop software and customer electronics or for

documentation) are identified. Accessibility Assessors keep themselves



up to date on accessibility issues and therefore questions were also

inserted that addressed how they keep themselves up to date and

whether they are members of any accessibility community. Finally,

they are asked whether they use an accessibility assessment

environment or tool (for example with a HTML assessment validator

like WAVE, or through an assistive technology such as a screenreader)

in their developments and implementations.

o Accessible-Specific: Accessibility Assessors are asked about how they

expect to be supported by an accessibility assessment tool, as well as

what their customers‟ expectation are about getting an official

accessibility certificate (e.g. W3C WAI-AAA).

o Demographic data: Finally, some personal data such as age, gender,

professional status, impairment type, and any memberships of

representative organisations are collected. This also includes his

education and job experience.

- Questionnaire for Public Bodies

o Accessibility: They are asked about accessibility terminology, as well

as generic accessibility experiences and interests (for example how

long is the interviewee dealing with accessibility issues, how does he

keep himself up to date with accessibility issues, as well as the possible

interest in vocational training about accessibility). Also the process of

policy making is addressed (e.g. the way of disseminating accessibility

issues via print media, conferences, etc.).

o Project work: The public bodies can describe here their experience

with realising accessibility projects, the implementation of accessible

websites as well as the usage of testing scenarios during software

implementations (which tools or assistive technologies are used). Also

the customers‟ expectations for an official certification are looked at.

o Accessible-Specific: These questions address how policy making in

the field of accessibility can be supported by an accessibility

assessment tool, as well as can support the enforcing accessibility

issues in companies and public institutions.

o Demographic data: The questionnaire is completed with a collection

of personal data such as age, gender, professional status, impairment

type, memberships of representative organisations and job

qualification.

- Questionnaire for Service Providers



o Accessibility: The questions provide aim at gathering feedback about

the meaning of accessibility, and vocational training with regards to

accessibility issues.

o Job and Professional knowledge: The questions address how the

organisation works with regards to teamwork, the support of

accessibility issues, the working with international and internal

accessibility guidelines and standards as well as the realisation of

accessibility projects. This also includes a clarification on the

evaluation of the accessibility status of a development, the usage of

validation tools and assistive technologies, as well as the ethical issue

regarding the benefits of accessible applications. Finally, the

customer‟s expectations of an official certification is addressed.

o Accessible-Specific: Because a service provider might lack knowledge

about accessibility standards and accessible software developments,

these questions address the wishes for a framework which will offer

support in accessibility.

o Personal Experience: The interviewee is asked here whether he

knows people who need assistive technologies for ICT usage as well as

which kind of assistive technology they use. The service provider can

describe in free text how his knowledge concerning accessibility for

software implementations affects his work.

o Personal Data: The questionnaire is completed with gathering of some

personal data such as age, gender, professional status, impairment type,

memberships of representative organisations and the job qualification.

In principle during the construction of the questionnaires we had to be aware that

validity and reliability in all partner countries are guaranteed. For this reason, we had

to be careful in not assuming that e.g.:

- In all participating countries the same accessibility law/standards exist.

- In all partner countries the same conditions exist regarding accessibility

knowledge procurement.

- Accessibility has the same or a comparable socio-political significance or

importance attached to it.

It must be pointed out,

- that each questionnaire has a manageable number of questions, thus ensuring

that each can be completed in 15 – 25 minutes for the online version and a

foreseen 45 – 60 minutes for the face-to-face interviews.

- that no redundant data is collected.



- that the questions are as much as possible presented in an attractive manner,

allowing the user to give the reply he desires, without pinpointing a limited set

of answers.

- that the interviewee has the opportunity to give individual additional

information via open questions.

Questionnaires per target group

The questionnaires per target group were organised as following:

Questionnaire Developer

The questionnaire contains 48 questions and is divided in the following parts:

a) Accessibility– 9 questions

b) Job and Professional knowledge– 22 questions

c) Accessible-specific – 2 questions

d) Personal experience – 7 questions

e) Personal data – 8 questions

Questionnaire Public Bodies


a) Accessibility – 18 questions

b) Project work – 10 questions


d) Personal data – 6 questions

Questionnaire Service Provider



b) Job and Professional knowledge – 22 questions


d) Personal experience – 7 questions

e) Personal data – 6 questions

Questionnaire Accessibility Assessors



b) Accessible-specific – 4 questions

c) Personal data – 13 questions



Questionnaire Elderly and People with Disabilities


a) Use of technique – 4 questions

b) Handling of the technique – 10 questions

c) Advanced Training and Education – 2 questions

d) Personal data – 7 questions

Questions sample

In order to meet classification specifications (completeness, exclusivity, unambiguity)

the questions were presented in a matrix format, while also using lists with

dichotomous and multiple response options. Also half-open questions and questions

with an open field in addition to close-ended questions were used where it was

believed that the answer categories were incomplete or where national circumstances

had to be considered. “Don´t Know” answers were included for all questions in order

to minimize potential uncertainties by the interviewee, as well as to reduce the amount

of missing values during statistical evaluation.

Open-ended questions were used to allow the interview to provide personal or

additional details.

Nominal-scaled questions and ordinal-scaled questions were used to survey personal

opinions and requirements.

Figure 34: Example of ordinal scaled question from the Questionnaire for Elderly and Disabled users

Figure 34 shows an ordinal scaled question. The answers (often, sometimes, rarely,

never) are transformed into scale values for analysis. The interviewee has the option



to add additional items in an open question portion. As such, unknown and/or

additional items, which are of importance to the interviewee, can be added.

By using these types of questions, hierarchies (ranks) can be established which reflect

a”Preferential Structure“ in the users‟ behaviour:

1. Most difficult to handle: Mobile phones, navigation systems

2. Difficult to handle: PDA/Handheld

3. Sometimes difficult to handle: Netbook and computer

4. Not difficult to handle: TV

Figure 35: Example of a Matrix Question

Questions have also been arranged in a table or matrix format. This makes sense if

multiple aspects are important for a topic or if categories of answers are often

repeated. Using such approach, it becomes easier to answer the questions. Figure 35

as well as Figure 36 show that the interviewee is presented with a well-arranged set of

questions which are easier to answer than a long list of iterative questions and

answers.

Matrix Questions often are used to ask for opinions and estimations. The first example

asks about the incidence of technical problems. The interviewee has to value these

technical problems whereby just one answer per item is possible. The second example

demonstrates how multiple answers questions are often used if more answers per item

are possible. Equally, this approach makes it easier for the interviewee to respond to

the questions.



Figure 36: Example of a Multiple Answers Question

Target Groups

5 target groups are surveyed via the ACCESSIBLE questionnaires:

- Developers as the target group which develop application and normally come

upon problems concerning accessibility during the developing process

- Service Providers as a target group which provides (accessible) (web)

services to end-users.

- Public Bodies as a target group which demand increasingly accessible

services to be developed.

- Accessibility Assessors as a target group which advocates the needs of people

with impairments and assess the accessibility of services offered or developed.

- Elderly and people with disabilities as a target group that demand accessible

products and services.



Figure 37: Relationship between the target groups

The target groups were identified in more detail in D8.1a “Dissemination plans and

materials”, namely:

End-user groups

Elderly

Individuals

(umbrella) Organisations

People with

disabilities

Individuals

(umbrella) Organisations

Teachers

Tutors

Formal

Informal

Trainers

Formal

Informal

Family members

Table 37: ACCESSIBLE end-user group

ICT providers



ICT providers

Industrial players (AT) designers

(AT) developers


SMEs (AT) designers

(AT) developers


Individuals OS developers

Web application developers

Desktop developers

Mobile application developers

AT experts

Mainstream software experts

Accessibility assessors

Table 38: ACCESSIBLE ICT providers

Service providers

Private Mobile service providers

Web service providers

Training institutions

Support services

Public Training institutions

Support services

Table 39: ACCESSIBLE service providers

Resellers

Resellers AT resellers

Software resellers

Table 40: ACCESSIBLE resellers

Research centers

AT research

Table 41: ACCESSIBLE research centres


AT research National authorities

Local authorities

Ministry of labour and education

National social security




Disability agencies

Public procurement agencies

Policy makers

Universities

Centres of VET13

Table 42: ACCESSIBLE public bodies/government

Relationship between the Target Groups

Because of the often close relationship between the aforementioned target groups, the

questionnaire was constructed as such that related elements were assembled in a

similar manner. For example, the applications which are used by end users are often

also the same applications used by the developers. Table 43 shows how a relation

between target groups, developers and users could look like. The basic assumption is

that developers develop applications for end users.

Developer Users

A

Which application and sub-application? Which applications are used?

Market Existing tools Market Existing

accessibility

B

For which user groups? Which user groups need more help?

Market Existence Market Existence

Table 43: Related target groups

A:

Developers are asked which applications and sub-applications they develop,

namely for which market and whether they use existing testing tools to test the

applications.

Users must be asked which applications they use and where they purchase

them, as well as what accessibility level they currently have.

Thereupon a comparison is to be made on whether the products offered by

developers find the anticipated user market, whether such are expected and

accepted by the users and whether such are accessible. A further comparison is

to be made on whether the users‟ expectations concerning for example the

development of accessibility were taken into consideration by the developers.

Finally, it must be analysed whether there are cross-national differences and

similarities regarding the aforementioned issues.

13

Vocational Education and Training



Further research (see B) must now clarify for which target group developers develop

and which user groups need more help.

B:

Developers must be asked for which user groups they develop, and more

specifically for which market they develop and for what user groups.

Users must be asked to identify which user group requires more assistance

with the applications, and whether there is an existing market for such

assistance, and what assistive technology already exists.

Thereupon a comparison is to be made on whether the different user groups

are able to handle new developments or whether they need special assistance.

A further comparison is to be made on whether it is possible to consider in

advance the different needs of the different user groups.



Data Analysis – Data Management

To discover related data, statistical methods will be applied to calculate the grade of

correlation. The resulting values will allow conclusions to be made about the strength

of the correlation and thus the strength of the dependency. Correlations will be done

on a national as well as a cross-national level.

Approach in headwords:

- Frequency of all questions and items in general

o Developer:

Accessibility

Job and Professional knowledge

Accessible-specific

Personal experience

Personal data

o Elderly and Disabled People:

Use of technique

Handling of the technique

Advanced Training and Education

Personal data

o Accessibility Assessors

Accessibility

Accessible-specific

Personal data

o Public Bodies

Accessibility

Project Work

Accessible-specific

Personal data

o Service Provider

Accessibility

Job and Professional Knowledge

Accessible specific

Personal experience

Personal data

- Evaluation of the midpoints mode, median, arithmetic midpoint and

quantile.



These are location parameters and display the distribution inside a sample as

well as standard deviations. Thus, the distribution of knowledge for example

about accessibility between the different countries and user groups can be

calculated. In due consideration of personal data (age, gender) first hints of

possible distribution pattern should be identifiable. By means of these

parameters it for example the average age of the elderly and disabled ICT-user

of the sample as well as their main problems of ICT-using can be pinpointed.

- Regression Analysis and analysis of correlation: Regression analysis is a

statistical method that identifies the relationship between two or more

quantitative variables: a dependent variable, for example the knowledge about

accessibility, and an independent or explanatory variable, for example the

working in projects with accessibility requirements. This method is used to

find the relationship between variables and to understand the statistical

dependence of one variable on other variables. It can show what proportion of

variance between variables is due to the dependent variable, and what

proportion is due to the independent variables.

A table of assumed correlations per user group is included in Error!

Reference source not found. and will be the basis for the regression analysis.

- Cluster Analysis

Cluster analysis is a method for grouping objects of a similar kind into

categories. Its objective is to sort cases into groups, or clusters, so that the

degree of association is strong between members of the same cluster and weak

between members of different clusters. Cluster analysis can be used to

discover structures in data without providing an interpretation.

The purpose is to join together cases into successively larger clusters, using

some measure of similarity or distance.



Annex 2: ACCESSIBLE Questionnaires (in English

Language)

Questionnaire for Accessibility Assessors



Questionnaire for Developers



Questionnaire for Elderly and Disabled

users



Questionnaire for Public Bodies



Questionnaire for Service Providers

D 2.2a – User needs and System Requirements Specification

Documents

Transcript of D 2.2a – User needs and System Requirements Specification