The ACCESS Framework aims to improve accessibility support by making it more accessible itself. It uses plug-ins to identify usability issues and automatically make corrections to address them. Users provide feedback to reinforce helpful changes. Evaluation found the framework improved performance on mouse tasks and users understood and accepted its approach after using it. Future work focuses on additional input methods, cross-platform support, and community involvement.

1. Accessibility Support with the
ACCESS Framework
Michael Heron
Vicki Hanson
Ian Ricketts

2. Introduction
• Accessibility support on the desktop has
improved considerably over the years.
– Most modern operating systems come with a wide
range of accessibility tools in place.
– And in many cases, these tools are quite good.
• However, there is still a problem with the way in
which these accessibility tools are made available
to users.
– Accessibility itself is not very accessible.

3. Key Problems
• There are three problems in particular with the way we
provide accessibility support and configuration options.
– Particularly when working with novice users.
• Novice users often:
– Do not know what can be changed.
• Or what support is available.
– Do not know how to change the things they know how to
change.
– Lack the confidence to make the changes they know how to
make.
• Even the terms ‘ease of access’ and ‘accessibility’
themselves had low levels of traction in our studies.
– They were not well understood by older users.

4. The ACCESS Framework
• The ACCESS Framework has been developed
to address these problems.
• It takes a proactive role in assessing when
configuration options should be changed.
– And then makes those changes when appropriate.
• When a change is made, the user is presented
with a plain English description of the change.
– And a description of the likely impact of the
change on their computer.

5. ACCESS Corrections
• The Framework itself offers an open source
architecture into which accessibility support can
be provided as plug-ins.
– Each plug-in is aimed at identifying a particular kind of
usability issue.
– Each plug-in is responsible for making a change in the
underlying system to address the identified issue.
• All plug-in interaction with the operating system
and the user is handled via the framework.

6. Technical Benefits
• ACCESS Framework plug-ins are designed to be very simple.
– Most of the ‘difficult’ work of building accessibility is provided in
the framework.
– It lowers the barrier to participation in building accessibility
software.
– Removes much of the ‘chore’ in building otherwise
straightforward applications.
• The ACCESS Framework offers a way of deploying cross
platform support.
– Cross Platform implementations exist for Ubuntu and OS X, but
these have not been experimentally trialled.
• Ensures plug-ins ‘play nicely’ together.

7. The ACCESS Framework
• User feedback on changes is collapsed down
to a single ‘I like this’ or ‘I don’t like this’
interaction.
– Clicking ‘I like this’ signals to the framework that
you’d like changes like this to be done more often.
– Clicking ‘I like his’ signals that you don’t want
changes like this to be done in future.
– ‘Silent consent’ is assumed when the framework is
not reinforced for a period of time.

8. ACCESS Tick
• The ACCESS Framework maintains a weighted roulette wheel of plug-
ins.
– User feedback influences how heavily plug-ins are weighted.
• At the end of a tick, the Framework polls each plug-in to see whether
they feel a correction can be made.
– The roulette wheel is then spun and the selected plug-in is permitted to
make a correction.

9. Reinforcement
Equally Weighted
Plug-ins in Roulette
Wheel
Plug-ins After a Single
positive correction on
Plug-in 2
Plug-ins after many
corrections

10. Evaluation
• Evaluation of the framework was performed
during a pair of 38 participant user studies.
– Each study lasted an hour
• The first study was aimed at assessing the
ability of a single plug-in to provide useful
corrections.
• The second was aimed at assessing whether
or not a suite of plug-ins would provide a
helpful environment.

11. Evaluation
• For the study, the computers used by the
participants was set up to be as user unfriendly
as was realistically possible.
– Resolution was set as high as possible.
– Desktop graphic was set to a noisy graphic from the
standard set.
– Mouse speed was set as high as possible.
– Pointer Precision was set off.
– Double clicks were set to be as quick as possible.
• The intention was to create an environment
where correction was required.

12. Plug-In Suite
• Five conceptually simple plug-ins were
deployed during the study.
– Dynamic double click adjustment
– Missed clicks detector
– Double-back detector
– Pointer size adjuster
– Mouse trails adjuster
• The first was assessed first by itself and then
as part of the suite.

13. Evaluation
• Users were asked to perform a series of mouse
interaction tasks.
– Double clicking a static target (both studies)
– Double clicking a moving target (both studies)
– Clicking a button indicated on an ‘answer sheet’
– Clicking a moving button as indicated on an ‘answer sheet’
– Tracking a moving target with the mouse.
• Tasks were before with and without the Framework
active.
– And participants were asked to fill in a short questionnaire
after each task rating ease of task and responsiveness of
equipment.

14. Results
• Several tasks showed statistically significant
improvements in both objective and self-
reported measures.
• Net improvement in performance.
• Attitudes towards the software were assessed in
a questionnaire at the end of the sessions.
• The metaphor of reinforcement was seen as
understandable and appropriate.
• Users felt that it was software they would choose
to install on their own computers.

15. Results
• Participants felt that the framework made useful
changes, and that they understood the impact of the
changes that were being made on their behalf.
• Participants felt that they didn’t like the ‘idea’ of changes
being made on their behalf.
• They were however supportive of the technique after
they had experienced it.
• Participants on the whole permitted the framework to
silently assume consent.
• Over half the time.
• 35% of reinforcements were positive
– In over 85% of cases then, the change was committed to the system.

16. Future Work
• Future work on the framework will centre on
three main areas:
– Incorporation of additional user input streams.
• Kinect, Wiimote, Eye-gaze tracking
– Expansion of cross platform functionality.
• Ensuring consistency of the provided API
– Extension of expressiveness.
• Ideally through the building of an open source community
around the tool.
– In Situ evaluation
• Tool only tested so far in laboratory experiments.