Capability, Acceptability and Aspiration for: collecting accessibility data with prototypes Brendan Cassidy, Gilbert Cockton, Chris Bloor and School of Computing and Technology Sir Tom Cowie Campus University of Sunderland, Sunderland, SR6 0DD brendan.cassidy-1@sunderland.ac.uk gilbert.cockton@sunderland.ac.uk chris.bloor@sunderland.ac.uk Lynne Coventry NCR Financial Solutions Division Discovery Centre 3 Fulton Road, Dundee lynne.coventry@scotland.ncr.com This paper argues for a focus on user capabilities, acceptability and aspirations for accessible public system design. It presents a prototyping approach as a means of gathering the necessary accessibility data by using an Automated Teller Machine (ATM) test rig. Initial results of a pilot study using the test rig are also provided as an example of how this approach can be used to provide the capability, acceptability and aspiration data that is needed if we are to better predict accessibility problems, and thus reduce the need for iterative user testing, which presents many challenges for accessibility research. Accessibility, Capabilities, User Aspirations, Prototyping, ATMs, Accessible Interaction Modelling, Device Demands, Tab/Select 1. INTRODUCTION Creating accessible systems to suit all user groups is very challenging. This, along with constantly evolving accessibility legislation [e.g., 1], has put increasing pressures on designers when producing accessible systems. Current approaches to accessibility, such as feature guidelines, have limitations [2] and address what user groups can’t do and offer design options in response to this. They do not actually look at what user’s can do, nor what is an acceptable level of accessibility for them according to their own aspirations. A system may not be fully accessible to a particular user group, but they could see even a small design consideration towards their needs as worthwhile. User testing is useful in so far as it lets us uncover unforeseen accessibility problems and implement remedial design changes before a product is released to manufacturing. However for this to be effective, iterative testing must ensure that no design changes inadvertently disadvantage some other user groups. This can be expensive, and finding willing representative users from a diverse set of user groups to participate may also cause problems. How we define impairments is also an issue. Attitudes towards disabilities and their classification have changed in the last decade. In 2001 the World Health Authority replaced their previous classification frameworks with the publication of their International Classification of Functioning, Disability and Health (ICF) [3]. Attitudes have changed from purely a medical viewpoint regarding disability to a more social perspective. The ICF sees disability as “not an attribute of an individual but rather a complex collection of conditions, many of which are created by the environment”. With this in mind, how we actually define our user groups and representative users becomes less clear than when working purely from medical diagnoses. There is a clear need to look at other approaches to accessible design. One such approach in development is Accessibility Interaction Modelling (AIM) [2], which looks to predict accessibility problems in order to reduce the need for iterative user testing. The modelling approach is based on State Transition Diagrams (STDs) where each ”user-apparent” system state is represented by a node. Interaction moves users from node to node. AIM treats accessibility as a property of interaction, not as a property of either the user or the system. AIM associates a set of device demands with each interaction step (transition) between nodes. Device demands include pushing the right key, or moving the mouse to a target. User capabilities are required to be able to meet these demands, e.g., the ability to locate, reach to and press a key. Similarly, for mouse demands, the user must be able to locate, reach to, grip and move the mouse to the desired location. AIM combines STDs, annotated with device demands, and user profiles, which would ideally express capability, acceptability and aspirations relative to specific device demands. A major challenge for AIM is developing user profiles that can express this range of accessibility data in a form that can be readily compared to device demands. The overriding challenge however is being able to gather this data for specific device contexts for a wide range of impairments. 2. THE NEED TO COLLECT CAPABILITY DATA USING PROTOTYPING To assess the accessibility consequences of device demands, we need a set of capability demographics for a wide range of impairments. User profiles of representative users can then be constructed and used to analyse device demands. Where a user’s capabilities can not meet a system’s device demands, an accessibility problem for the group represented by the user profile would be uncovered. For this to work, we need accurate and appropriate data on user capabilities. This data needs to be in the correct form for the type of system we are designing.