3a5 accessible eu project use cases

Accessibility Assessment Simulation Environment for New Applications Design and Development

1st International Conference of ÆGIS: Access for All in the desktop, web and mobile field: an

end-user and developer perspective

October 2010, Seville

ACCESSIBLE EU PROJECT

USE CASES

Dr. Evangelos Bekiaris

CERTH/HIT

Introduction

Aim The main goal of ACCESSIBLE is to utilise the fundamental properties

and to improve the accessibility of software development products.

Objectives Assessment Simulation module

support the analysis and verification accessibility procedure of Web

applications and services, mobile applications as well as description

languages.

Harmonized Accessibility Methodological framework

a novel assessment methodology for a broad set of application

environments (web applications, web services, standard description

languages (e.g. SDL), mobile applications that correlates the accessibility

components.

Designer-aid module

assist the users during the design and development of the products

1st International Conference of ÆGIS, October 2010, Seville 2

Introduction


ACCESSIBLE User Interface

EARL Reporting Tool

Developer &

designer

aid Module

Ontology

based

Knowledge

Resource and

Inference

engine

Assessment

Simulation Module

Use Cases Methodology


ACCESSIBLE personas

(new ones and also

personas based upon

ÆGIS)

User needs definitionT2.1 “User needs”-D2.2 “User needs and system

requirements specifications”

User need and requirements

understanding

Understand the problem and the way

we can meet the users expectations.

ACCESSIBLE UCT2.4 “Use Cases and applications scenarios”-

D2.4 “Use Cases”

ACCESSIBLE application Scenarios

D2.3 “Pilot application specifications”

User needs and requirements (1/2)

Developer oriented

Main focus on web and end user devices accessibility.

Need for advanced (online) education in the area of accessibility,

especially for web and mobile accessibility and accessible user

interface aspects and (assistive) devices.

Rather low awareness about accessibility standards and guidelines,

especially WCAG2.0.

Interested in being able to assess the accessibility of web, mobile and

desktop applications, using software applications.

Interest in having validators embedded in the development tools.

Desire to be able to implement WCAG 2.0.

Preference in having access to accessibility simulation/validation

tools, than online or downloadable.

All (public) service providers and private companies are faced with

increasing needs for accessibility certifications .


User needs and requirements (2/2)

End-user related

Face a variety of accessibility issues with interfaces of mobiles,

desktop and website applications.

They are interested in using accessibility tools, but they are often

disappointed and discouraged.

These findings were similar across all disability groups.


Personas

Adaptation of the Personas modelling that has been initially

developed in the ÆGIS project.

The Personas developed in ACCESSIBLE are partially based

on the ÆGIS personas, while additional personas were

developed as well to address the wider scope of disabilities

considered.

correlations between the impairment categories and sub-categories of

ACCESSIBLE and the ÆGIS personas

Personas constitute the most efficient possible design and

context of use capturing tool.

In addition, we also updated 2 ÆGIS developer personas to

reflect needs and requirements as identified by the

ACCESSIBLE survey.


Use Cases overview (1/2)

Category 0: Generic Use Cases

Category 1: Web applications

Category 2: Mobile applications

Category 3: Web services

Category 4: Description languages

Category 5: Visualisation (designer aid module)


Use Cases overview (2/2)


Use Cases details (1/2)

Use Case Title.

A short title that indicates the scope of the specific UC.

Brief Description.

This includes the description of the main use case, which is the target of the user.

Application area.

To which application area of ACCESSIBLE the UC refers.

Relevant WP.

In which ACCESSIBLE WP the UC is being developed.

Scenario.

The title of the various scenarios for which the UC is consisted.

Primary actor.

This is the actor who initiates the use case and triggers the system.

Secondary actor.

This is the actor that does not participate directly in the UC but is being affected

indirectly.

Priority level.

The ‘essential’ and ‘secondary’ UCs are the ones that have to be tested in the pilots of

WP1.5, while the ‘supportive’ ones will be tested only if the specific UC is not

covered/tested through another UC.1st International Conference of ÆGIS, October 2010, Seville 10

Use Cases details (1/2)

System Input (trigger).

This is the first action/request that is provided by one actor.

System Output.

It is the feedback and the reaction of the system to the Input (trigger).

Resources required to perform:

Some UC may need specific resources like specific licence, software, NETBEANS,

involved user equipment, etc. in order to be implemented properly and to be functional.

Interaction step(s).

Possible sequences of interactions to achieve the UC goal as series sequential steps of

the system and the user.

Connected UCs.

This refers to any extension or connectivity of the current UC to other UCs.

Relevant ACCESSIBLE personas.

Background info.

Information that explain the reason why this UC has been included.

Reference

Comments


Use Case example


Use Case No 1.1

Use Case Title In depth Web application accessibility assessment.

Brief description

(user goal

satisfied)

This use case category answers the users’ needs in the in-depth accessibility

assessment of Web applications. This goal succeeds if the user has effectively

performed the accessibility assessment of its preferable Web application through the

selection of different categories of disabilities and impairments, relevant personas

and other accessibility constraints.

Scenario The user wants to evaluate the accessibility status of a preferable web application

(web site).

Interaction

steps

Scenario 1.1.1: Selection of the preferable web applications that the system user

wants to evaluate

Step 1a: The user defines the URL/local file path of the web application (web

page/web site) that wants to evaluate.

Step 1b: The user inserts to the system the html source code that wants to assess.

Step 2: The user defines the maximum number of web pages or a whole web site

that wants to perform the accessibility assessment.

Evaluation and next steps

Pilot Plan Phases


Conclusions

15 Use Cases covering all areas of study in a balance way

all essential

5 generic use cases for the administrative functionalities and

requirements of the system.

2 use cases about the web applications.

1 for in depth assessment of accessibility.

1 for public and private procurements and purchasers as well as all the

other users that don’t need, or don’t want, to view such detailed

technically information.

4 use cases about the mobile applications.

2 use cases about the web services.

1 use case about the Description Languages.

1 use case about the Visualisation tool.


151st International Conference of ÆGIS, October 2010, Seville

3a5 accessible eu project use cases

Education

Transcript of 3a5 accessible eu project use cases