This document proposes a design space and repository for sharing adaptation rules to make applications more accessible. It aims to reduce the gap between developer workload and accessible design by providing a common set of concepts and reusable rules. The design space considers different user disabilities, adaptation granularity levels, and abstraction levels. The repository stores adaptation rules using an event-condition-action model and metadata for classification. Examples show rules that add subtitles for deaf users or table of contents navigation for blind users. The goal is to support model-based UI design systems in generating accessible applications by integrating these shared adaptation rules.

1. An Environment for Designing and
Sharing Adaptation Rules for
Accessible Applications
Raúl Miñón, Fabio Paternò, Myriam
Arrue

2. Problem Statement

3. Motivation
• Model-Based UI design is a promising
approach to deal with this problems since…
– It allows generating different FUIs adequate for
the specific needs of each user.
– The independence of the programming language
and the platform abstracts their specific different
issues.
– The required standards and accessibility
guidelines can be included in the generation
process.

4. Main Goal & Contributions
• To reduce the gap between:
– knowledge & workload of the developers
– the accessible applications issues
• To provide the community a design space
composed of key concepts related to adaptations
for people with special needs.
• To create a repository for collecting different
adaptation rules for people with special needs.
• To provide access to the repository to allow
MBUI systems the integration of the adaptation
rules.

5. Design Space

6. Target Users
• Different capabilities require different adaptations 
necessity of a model of disabilities
– Sight: low vision, blindness, colour blindness,
photosensitivity and eyestrain.
– Hearing: deafness and mild-deafness.
– Physical: limited-movement, key-board only users,
Parkinson and paraplegia.
– Cognitive: decline in maintaining attention, learning
disabilities, language disabilities and reduced memory
capacity.
• The adaptation rules can be related to a general
category or to a specific disability.

7. Granularity Level
• Adaptations can have an impact at different
granularity levels of the UI:
– Application, Presentation, Group of Elements and
Single Element.
– External  adaptations that go further the
current application.
• Useful to identify the most suitable order of
execution for the adaptation rules.

8. Adapted UI & Adaptive UI
• Adapted UI adapted at design time and are
instantiated at run-time.
– Focused on tailoring the most adequate UI for the
specific capabilities of the user.
– When users with disabilities interact with the UI, it is
totally adapted to their needs.
– Valid when the context of the user is static
• When the context is dynamic, sometimes the UI
needs to be adaptive to change according to it.

9. Abstraction Level
• According Cameleon Framework:
– Task and Domain, Abstract UI, Concrete UI and
Final UI.
• If there is a specific requirement derived from
an adaptation rule, the designer can perform
the necessary changes in the first phases of
the design process.
– less effort in making modifications.

10. Design of the Adaptation Repository
• The repository stores the adaptation rules
modelled with some meta-information to
select and classify them adequately:
– Rule ID, Source, Adapted UI or Adaptive UI,
Disability, Granularity Level, Assistive Technology
and Abstraction Level.
• The Adaptation Rules follow an Event-
Condition-Action approach based on the
Advanced Adaptation Logic Description
Language (Serenoa Project).

11. An Example of Adaptation Rule
• Rule 1 (deaf target group):
– Event: the noise of the environment changes to a
value higher than 25 decibels.
– Condition: the user has a mild-deafness disability.
– Action: every video has to be changed to a video
with subtitles.

12. Other Example of Adaptation Rule
• Rule 2 (blind target group):
– Event: the user accesses an application with many
interaction elements.
– Condition: the user is blind
– Action: a table of content is created to easily
access each interaction element.

13. Other Example of Adaptation Rule
• Rule 6 (paraplegia target group):
– Event: the user begins to move.
– Condition: the user has paraplegia AND the UI is
not rendered with the vocal modality.
– Action: the user interface is changed to the vocal
modality.

14. Architecture

15. Conclusion
• The concepts proposed in the design space
must be considered when designing an
adaptation rule for a person with special
needs.
• The adaptation repository eases the task of
designing accessible applications.
• MBUI systems can abstract accessibility issues
interacting with the repository.

16. Future Work
• Adaptation rules to support combination of
different disabilities.
• Further mechanisms in order to solve possible
conflicts among the rules.

17. Thank You!!!
Any question?