Abstract versus Concrete Terms to Express User Needs

From wiki.gpii
Jump to: navigation, search

Expressing user needs and preferences can be done on different levels. Some users may know which concrete settings they require. For instance, blind users usually know that they need text-to-speech and/or Braille to use computer technologies. Additionally, we found they know pretty well which concrete settings should be applied to operate computer technologies more comfortable and effective respectively, e.g. speech rate, voice, punctuation verbosity shall be exemplarily mentioned for such concrete preferences. In contrast, other users may not know which concrete settings need to be applied to suit their needs and preferences. We found they often express their preferences on a more abstract level, e.g. everything should simpler or larger; I want the mouse to be easier to use, etc.

The main difference between concrete and abstract preferences terms is that concrete preferences can be translated directly to application settings. On the contrary, abstract preferences require more intelligent approaches to infer concrete application settings which can be applied on a user device improving the accessibility for the user. That challenges matchmaking approaches but also preferences editors allowing the user to find concrete accessibility options suiting their needs and preferences.

Motivation for having abstract preference terms additionally to concrete terms can be summarized as follows:

  • Users cannot express concrete preferences as they do not know much about available assistive technologies and accessibility options.
  • Using intelligent approach and tools, e.g. first discovery tool, needs and preferences wizards, “try different” concept, as well as matchmaking approaches, can support getting stepwise from abstract to concrete preferences.

Examples for Abstract Common Terms

Proposed Abstract Terms for Pointer Control

pointerContolEnhancement [true/false]

  • Abstract common term indicating a user, e.g. with tremor, requires support to use the mouse. However, no further requirements can be concretized by them.
{
    "pointer control preference set": {
        "preferences": {
            "http://registry.gpii.net/common/pointerContolEnhancement ": [
                {
                    "value": true
                }
            ]
        },
        // priority rating for requested configurations
        "usage": "required"
    }
}
  • A variety of accessibility options which might help the user could be suggested/inferred stepwise to find a concrete solution:
  1. Speed of the pointer (slowing down)
  2. Enhance the appearance of the mouse pointer, e.g. cursor size
  3. Enlarge everything making the buttons and other targets easier to focus the mouse pointer upon, e.g. through screen resolution.
  4. Use alternative software that takes more intelligent approaches such as predicting the intended path of the mouse pointer, e.g. SteadyMouse.
  5. Use a supplementary switch to operate as a left or right click.
  6. Use the keyboard to accomplish mouse movements and clicking.

pointerControlEnhancement [visibility, movement, click]

  • Still a abstract term but allows more implication if the user requires support in terms of the visibility of a cursor, movement of the pointer or clicking a button.
  • Visibility - user has difficulties to keep track of the cursor:
{
    "pointer control preference set": {
        "preferences": {
            "http://registry.gpii.net/common/pointerContolEnhancement ": [
                {
                    "value": ["visibility"]
                }
            ]
        },
        // priority rating for requested configurations
        "usage": "required"
    }
}
    • Accessibility options which could be suggested/inferred stepwise to find a concrete solution:
      1. cursorSize
      2. cursorColour
      3. cursorScheme (not in ISO 24751)
      4. cursorSchemeURL (not in ISO 24751)
      5. cursorTrails
      6. cursorLocationByKey (not in ISO 24751)
  • Movement - user has difficulties to hold the mouse steady
{
    "pointer control preference set": {
        "preferences": {
            "http://registry.gpii.net/common/pointerContolEnhancement ": [
                {
                    "value": ["movement"]
                }
            ]
        },
        // priority rating for requested configurations
        "usage": "required"
    }
}
    • Accessibility options which could be suggested/inferred stepwise to find a concrete solution:
      1. cursorSpeed
      2. cursorSize
      3. screenResolution
      4. try application, e.g SteadyMouse
      5. pointerControl = ["keyboard"] // use the keyboard to accomplish mouse movements and clicking
  • Click - use the mouse or other pointing devices without the need to click a button
{
    "pointer control preference set": {
        "preferences": {
            "http://registry.gpii.net/common/pointerContolEnhancement ": [
                {
                    "value": ["click"]
                }
            ]
        },
        // priority rating for requested configurations
        "usage": "required"
    }
}
    • Accessibility options which could be suggested/inferred stepwise to find a concrete solution:
      1. pointerControl = [mouse] // see discussion about concrete terms for pointer control
      2. dwellSelect = true
      3. dwellTime = ?? // amount of time to wait before the virtual click
  • Click and movement:
{
    "pointer control preference set": {
        "preferences": {
            "http://registry.gpii.net/common/pointerContolEnhancement ": [
                {
                    "value": ["movement", "click"]
                }
            ]
        },
        // priority rating for requested configurations
        "usage": "required"
    }
}