Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications

1st International Workshop on
Web Usability and Accessibility (IWWUA 2007)
December 3-7, 2007
Nancy, France
Inclusive Usability Techniques in
Requirements Analysis of
Accessible Web Applications
Lourdes Moreno, Paloma Martínez, and Belén Ruiz
Labda Group, Computer science department
Universidad Carlos III de Madrid

Lourdes Moreno (UC3M) IWWUA 2007, Nancy Francia
Introduction
• Continued growth in the use of Internet (access
to the WWW)
• Diversity (technological and functional)
=> Special attention to accessibility
(for user with or without disabilities )
• To avoid the exclusion of groups of users
accessing Web
• To provide full accessibility to the Web contents

Related work
• Standard: Web Accessibility Initiative (WAI): Web Content Accessibility
Guideline WCAG 1.0
• Consideration of accessibility in proposals of integrating usability in the
development process, but incomplete
• Works which adapting the WCAG 1.0 guidelines: Evaluation
Accessibility, monitorization, metrics of accessibility, etc.
• Methodological approach with accessibility( in RNF)
• User Centered Design (UCD)
but accessibility criteria are not covered in the whole life cycle, nor fully
integrated and there is enough to support for the designer
This work is the focus of a thesis research, Accessibility for Web Applications
(AWA). Its objective is to offer a methodological support to integrate
accessibility from an Web engineering perspective in the whole life cycle of
a web application

Following the approach:
Accessibility requirements capture
• Accessibility is a requirement and must follow a
WCAG standard
but, Is it enough to capture accessibility requirements?
Important aspects of the web user interaction could go
unnoticed
=> It’s necessary to integrate usability and accessibility in
software processes following a UCD using usability
techniques.
but, what kind of user is it aimed at?
⇒ Framework of Inclusive Design =>
"all" users in mind, users with disabilities too

Case study. Spanish Centre of
Captioning and Audio Description (CESyA)
Development CESyA website:
• Requirement: the web has to be accessible according to the
WCAG 1.0 accessibility standard
• Some experiments have been carried to enable the
evaluation of the consequences that would imply applying or
not inclusion in the analysis phase
• In this work, two web development processes have been
carried out under the same domain, but with different ways
to act in the capture of requirements.
– “Inclusive Case” , in the framework of Inclusive Design
– “Non Inclusive Case”, Not inclusive approach

 Analysts and web designers with similar
characteristics
 The same technological profile with a basic
core (WCAG1.0+XHTML+CSS with procedures for
the dynamic contents)
 Users participation en analysis phase:
 Users without disabilities participation in “Non
Inclusive case”
 Users with and without disabilities participation in
“Inclusive Case”
Experiment Characteristics

ISO 13407: Human-centred design process
1
2
3
Capture of requirements
Different ways to act: with or without inclusion
Evaluation of hipotesis
he inclusive case needs
fewer changes in the
redesign of the interface
Evaluation of prototypes
Consequences that would
imply applying or not
inclusion in the analysis
phase
Approach: WCAG + UCD
using usability techniques
Inclusion as
an added
value?
1
2
3
phase
Approach: WCAG + UCD
using usability techniques
Inclusion as
an added
value?
1
2
3
phase
1
2
3
Evaluation Hypothesis
The “Inclusive case”
requires fewer changes
in the redesign than “Non
Inclusive Case”
phase
Inclusion as
an added
value?
Experimentation

ISO 13407: Human-centered design process
1
2
3
1.- Capture of requirements
User Modeling

USABILITY TECHNIQUES:
Investigation, observations, interviews
=> features, common attributes
User profiles
Person focus
Scenarios with characters
Card Sorting
Prototype and brainstorming
AUDIENCE MODELING
Almost every
audience has been
modeled
1.- Capture of requirements:
User Modeling

Usability techniques:
User profiles
The aim is to satisfy the own necessities of each group of
users
• Based on common attributes among the users (information
necessities, preferences of the users, technological formation, age,
etc. ) and in the “Inclusive Case” following:
– To having in mind the barriers of accessibility of all the users
– Access characteristics (special browsers, assistive technology,
…)
• Problem: The extension and heterogeneous coverage, which
could make the total categorization of the audience not be
possible or too expensive.
=> It is convenient to make use of the focus of Person

The artefact of "User Profiles" in CESyA case study

Person focus
• People will represent behavior patterns, objectives and
necessities of groups of people
– Fictional user, but the patterns have characteristics based on the
investigation over the real audience
– The patters will never represent the totality of the groups of the real
users, but do represent them in their majority.
– In the “Inclusive Case” following inclusive design enables the
designer to have in mind potential users, knowing in all moments the
type of design that will be needed.
• The categorization of the audience is more feasible
• To make more realistic the descriptions of the use of the
Web, use scenarios and person focus
=> Scenarios with characters technique

Scenarios with characters
• Scenarios technique describes situations of Web usage
conceptualizing the Human-Machine Interaction with
fictitious users (on the basis of person focus technique.
• In the “Inclusive Case”, the scenarios show people with a
variety of disabilities which use different technologies
and strategies of adaptation to be able to access the
Web
• Almost every audience has been modeled, by studying
various User profiles in only one scenario

The artefact of Scenarios in “Inclusive Case”

The artefact of Scenarios in “Inclusive Case”
CHARACTERISTICS:
Demography : Young, 19 years old
Work responsibility/tasks: Student
Use frequency: weekly (frequency)
Hardware, Assistive technologies : a screen magnifier and sometimes combination of
screen reader and Braille line
Environment: home
Software: Linux Debian, Opera
Experience: Low, little handling with of the environment and of the page
Disability: deafness blindness
Reason of use: Pedagogic.
CHARACTERISTICS:
Demography : Young, 19 years old
Work responsibility/tasks: Student
Use frequency: weekly (frequency)
Hardware, Assistive technologies : a screen magnifier and sometimes combination of
screen reader and Braille line
Environment: home
Software: Linux Debian, Opera
Experience: Low, little handling with of the environment and of the page
Disability: deafness blindness
Reason of use: Pedagogic.

Card Sorting
• The card sorting technique is based on the observation of
how real users perform the task of clustering a
predetermined number of labeled cards with different
thematic categories of the web site.
• Helps the information architect make decisions that concern
the organization of the information in relation to user´ s
needs.
• Provides valuable information to capture requirements.
• Only real users participate.
• Starting from the users´ behavior, the objective is to
understand the mental model of the user.
• It provides qualitative and quantitative information applying a
clustering analysis and the multidimensional scaling
analysis (MDS).

Card Sorting Experiment
Inclusive Case Non inclusive Case
In the "Inclusive Case“:
• Diversity amongst some groups has been found
• Elements with problems without belonging to any visual group
=> To design of post phases knowing that the elements of the architecture
could have problems which would require attention and reinforcing its design

Prototype
In Analysis phase, for the
requirements capture, the
prototype technique has
been used (low cost)
It has been used to give
support in the taking of
decisions in reunions and
brainstorming with the
client, user  important
design aspects can be
improved with a low cost.Digital web model of
CESyA prototype

2.- Evaluation of prototypes
Accessibility evaluation
1
2
3
phase

2.- Evaluation of prototypes:
Significant observations:
• There are many factors that have been detected in the
“Inclusive Case” in relation to the “Non Inclusive Case”:
(1) Different types of HW and SW access can produce
accessibility barriers, especially in the indirect access
to the web by users who need assistive technologies
(2) Different levels of browsing in the in different groups
of users, etc.
(3) Concerning the information architecture, different
mental models where information is clustered.

2.- Evaluation of prototypes:
1) Accessibility evaluation: automatic and manual validation
carried out by experts.
=> The two prototypes implemented according WCAG 1.0
2) Users test were made in both cases, including people
with or without disabilities and diverse conditions of
usage to evaluate usability aspects and accessibility in
both prototypes.

1
2
3
1
2
3
Hypothesis Evaluation
The “Inclusive case”
requires fewer changes
in the redesign than “Non
Inclusive Case”
3.- Evaluation of hypothesis
Evaluating changes in the redesign

Changes in “Non Inclusive Case”
The more important changes detected disabled users' reviews are in
the "Non Inclusive Case" and have not been required to include in
the “Inclusive Case" because knowledge extracted from phase
analysis and applied in the development of the web site are:
• Description link: Non-adequate attribute title. The links have to be
more descriptive. (screen reader users)
• Icon and decorative image: Non-adequate attribute alt. The
decorative images are labeled in XHTML with the alt = " text equivalent "
attribute, instead of the decorative image with the alt =”“ and icon is
included in CSS with a correct marking in the XHTML, (screen reader
users)
• Invisible shortcut: Inexistent, the users have suggested them as an
improvement. (screen reader users)
• Visibility edges interface: Presence of navigation menus in the
corners but the users do not see them. (screen magnifier users)

• Lines which frame the information (screen magnifier users)
• Types of text Font: The font type used is Verdana. The users
would prefer bolder fonts as Arial. (screen magnifier users)
• Language accessibility: Some problems have been found in the
comprehension of the texts, about using a simple and clear
language but based on how to visually structure it to make easier
the comprehension: without dense paragraphs, large blank spaces
between them, using lists, etc.
• Structural marking: Disabled users have asked for a better
structural marking, better definition of the header elements
• Multimedia elements: Users have asked for control options for the
user, of information, format types, time, weight, etc. Some users
could not access this resource
• Direct access in resizing/font-scaling and high-contrast mode.
Although compatible access is provided to user following WCAG,
users suggested direct access too, not all of them knew use
browser options.

The hypothesis is true:
The “Inclusive Case” need fewer changes in
the redesign than “Non Inclusive Case”
Consequently, in the “Inclusive Case” has
produced a reduction of costs in the
development, avoiding new requirements
to have in mind in the development
process

Some conclusions
 User Centered Design (UCD) using usability techniques
 WCAG: The benefits providing by the guidelines are
fundamental for designers.
– To detect accessibility barriers
– Evaluation of accessibility of a user interface prototype in
an advanced phase of Design-Evaluation
but, following WCAG guidelines in Analysis phase offers enough
support to the designer?
=> For professionals without previous experience in the
development of accessible web applications, the guides make
knowledge obtained in the “Inclusive Case” an added value.
• The UCD framework with usability techniques help to come
closer to the user, but the benefits of the inclusion in the
analysis phase are distinguishable.

Final conclusion:
To integrate usability and
accessibility in software
processes following a User
Centered Design (UCD) using
usability techniques with
inclusion

1st International Workshop on
Web Usability and Accessibility (IWWUA 2007)
December 3-7, 2007
Nancy, France
Thank you for your attention
Lourdes Moreno
lmoreno@inf.uc3m.es

Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Destaque

Destaque (9)

Semelhante a Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications

Semelhante a Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications (20)

Mais de Grupo HULAT

Mais de Grupo HULAT (20)

Último

Último (20)

Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications

Notas do Editor