Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Accessibility Support with the ACCESS Framework

The talk I gave at Digital Engagement 2011, in Newcastle.

  • Be the first to comment

  • Be the first to like this

Accessibility Support with the ACCESS Framework

  1. 1. Accessibility Support with the ACCESS Framework Michael Heron Vicki Hanson Ian Ricketts
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.