Q3: Assistance
Introduction
Question 3 from NIDILRR is "Should all of the preference creation tools in this application setting be designed for use by the end user independently, or should initial preference-setting tools to be designed to be used with staff support?"
We have expanded "staff support" to include helpers of all types. These are people who have some connection to the user, and who are available to help the user move through the tool.
We have also expanded an assumption in the question relevant to tool design. In addition to making it easy for someone to assist a user in completing a user-oriented tool, we may want to design tools specifically aimed at assistants of one kind or another. One of these would be a 'pre-tool': a quick assessment of the user performed by an assistant, the sole goal of which is to focus the user-driven tool session better, and reduce its length, by removing clearly superfluous sections or items; and making the tool session more usable by pre-tuning the interface to match the assistant's understanding of the user's essential needs and preferences.
Assistance and Autonomy
We need a clear statement about this.
- The goal is user autonomy, which will be defined differently in different situations. We adopt this goal not just for reasons of principle, but because it is the most practical approach to developing an immediate best fit interface, and long-term engagement in the continuing process of refinement. Tools, including how they are documented, should contribute to the development of user meta-cognition and autonomy.
- There is a natural tension between the impressions or assumptions of the assistant, and the knowledge and intuitions of the end user. To the extent possible, tools should address this tension effectively themselves, creating an experience in which both end user and assistant can contribute to the result while exploring the nature of the relationship.
- A professional (e.g., therapist) assisting with the tool may be acting on behalf of an institution (e.g., school district). This may pose a double dose of autonomy-jeopardy: the professional may be assumed to know better than the end user about the end user's own needs and preferences, and the professional may be working in part on behalf of the institution's goals, which may not fully coincide with the end user's goals. Tools should embed a recognition of this tension even as their design seeks to integrate both professional norms (e.g., testing protocols) and institutional goals.
Types of Assistance
Here's a table showing a breakdown of different types of assistance, with examples, in the 4 application settings. "Professional" here means someone with a specific role and training pertinent to the domain of use, with at least a minimum professional understanding of accessibility in the context of use.
| Informal | Formal, by a professional | Formal, by a non-professional | |
|---|---|---|---|
Voting | family, friend | [a notable absence] | poll worker, voter registration worker |
| OER | family, friend | teacher, clinician, ed-tech coordinator | classroom aide |
| Assessment | family | teacher, clinician, ed-tech coordinator | 'proctor'? |
| Senior | family, friend, peer | digital literacy instructor, librarian | library or senior center aide |
Notes:
- Not all assistance need be real-time.
- Not all assistance need be face-to-face. Assistance on Demand (AoD) should be available to FD users, but the actual mechanics of that is out of scope here.
- Users may be presented with different assistance options. For example, they might have a non-professional available for immediate face-to-face, a professional available for face-to-face on a scheduled basis, a professional available immediately for remote video assistance, etc.