The IndieUI Working Group is no longer chartered to operate. The scope of its work are expected to be taken up in several other Working Groups:

  • Web Platform may develop device-abstracted events similar in scope to IndieUI: Events;
  • CSS may express some of the context properties from IndieUI: User Context as Media Queries;
  • ARIA may build a module of additional context properties from IndieUI: User Context.

Resources from the IndieUI remain available to support long-term institutional memory, but this information is of historical value only.

User Context/Requirements

From Independent User Interface
Jump to: navigation, search

WARNING - IN EDIT AT THIS TIME -andy

Contents

Requirements, Use Cases, Scenarios, Preferences

This material is organised around individual preferences and groups of similar preferences. Initially, for convenience in mapping between, this list follows the structure of a11ymetadata version 7

Plain Access Mode Alternatives

Access Mode is a property through which the intellectual content of a resource might be communicated. They correspond in the main to human sensory modes by which the information content might be consumed.

Values

auditory

tactile

textual

visual

Use in Preferences

Their use in preferences is of the form "this for that" meaning the user prefers or requires a resource with "this" modality to one with "that" - this might suggest either a replacement or an augmentation of "that" with "this" depending on the context. Not all combinations of "this" for "that" are useful.

textualForVisual
When

Not Version 1.0

Implementation

Not yet

auditoryForVisual
When

Not Version 1.0

Implementation

Not yet

textualForAuditory
When

Not Version 1.0

Implementation

Not yet

tactileForVisual
When

Not Version 1.0

Implementation

Not yet

tactileForAuditory
When

Not Version 1.0

Implementation

Not yet

tactileForTextual
When

Not Version 1.0

Implementation

Not yet

visualForAuditory
When

Not Version 1.0

Implementation

Not yet

Superimposed Access Mode Alternatives

In some cases one access mode is superImposed on another, such as text embedded in an image which in a11y is described as textOnVisual

Values

accessMode values might be

textOnVisual chartOnVisual chemOnVisual diagramOnVisual mathOnVisual musicOnVisual

Use in Preferences

textualForTextOnVisual

preference for a text alternative for text embedded in an image. Might map to ALT text or LONG DESC

When

Not Version 1.0

similarly for chartOnVisual, chemOnVisual, diagramOnVisual, mathOnVisual, musicOnVisual


Miscellaneous Access Mode Alternatives

Use in Preferences

colorIndependent

Do not deliver resources whose information content depends on color to this user


Notes
When

Version 1.0 ????

Implementation

??????

accessFeature Preferences

Content features of the resource, such as accessible media and alternatives.

Use in Preferences

Some of these can be used alone and some in relation to an accessMode which they replace or augment.

Legacy Stuff

UNDER CONSTRUCTION

The use cases in this section are based on | requirements and additional use cases from AccessForAll

AT Compatible

A person is using a screen reader, screen magnifier, accessibility test tool, or alternate input technology and would like to ask that content be designed to support those assistive technologies whenever possible. The person would like to do this without declaring the use of a specific assistive technology.

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

  • WCAG 2.0 - compliance with checkpoints 1.1.1, 1.3.1, 1.3.2, 2.4.4, 3.1.1, 3.1.2, 3.3.2, 4.1.1 and 4.1.2.The specific details of the AT are normally provided by a user agent or the operating system.
  • WAI-ARIA
  • HTML5 elements with strong native host language semantics

accessHazard:flashing

A user wishes to avoid receiving content with particular characteristics, specifically content that flashes

Notes

A user wishes to avoid receiving content that flashes at a rate that can cause seizures

accessHazard:flashing

A resource whose visual pattern flashes more than three times in any one second; this level of flashing can cause seizures in some users (WCAG2 Guideline 2.3.2):

   http://www.w3.org/TR/WCAG20/#seizure

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

accessHazard:motionSimulation

A user wishes to avoid receiving content with particular characteristics, specifically content that can cause motion sickness

Notes

Need a criteria for this - what are the physical limits

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 4: accessHazard:sound

A user wishes to avoid receiving content with particular characteristics, specifically content that has audio patterns that can cause seizures

Notes

A resource generating audio pattern that can cause the user to have seizures [ISO 29138] should not be delivered to the user.

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

auditoryForVisual

A user wishes to that visual content is augmented by or replaced with auditory content that conveys the essential meaning of the visual content

Notes

This can require different user-agent and device actions in different contexts. Where a video has accompanying audioDescription information the requirement may be to enable rendering that audioDescription in a player in the user agent. Where images have ALT tags the requirement may be to render those tags in auditory form (as in screenreader usage). Where a video has speech in a different language to that a user might understand and closed captions in a language that user can understand (determined by user language preferences) a specialised user agent might render the captions as audio over the top of speech in the video (dubbing).

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 6: textualForAuditory

A user wishes that auditory content is augmented by or replaced by textual content that conveys the essential meaning of the auditory content

Notes

This can require different user-agent and device actions in different contexts. Where a video has accompanying closed captions the requirement will be to switch those on in the user agent. Where an auditory media file (such as a podcast) has an accompanying transcript of the audio the requirement will be to deliver that instead of the audio, or in some cases, depending on other preferences to deliver that at the same time as the audio (for example in some cognitive conditions perception and understanding is improved with multiple sensory forms of the material)

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

textualForVisual

A user wishes that visual content is augmented by or replaced by textual content that conveys the essential meaning of the visual content

Notes

This can require different user-agent and device actions in different contexts depending on what textual forms are available. The most common is ALT tags for images

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 8:visualForAuditory

visualForAuditory

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 9:visualForTextual

visualForTextual

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 10:auditoryForText

auditoryForText

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

alternativeText

alternativeText

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 12:audioDescription

audioDescription

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

braille

braille

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

captions

captions

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 15:ChemML

ChemML

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

describedMath

describedMath

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

displayTransformability

displayTransformability

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

haptic

haptic

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 19:highContrast

highContrast

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

largePrint

largePrint

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

latex

latex

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

longDescription

longDescription

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

MathML

MathML

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

musicBraille

musicBraille

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

nemethBraille

nemethBraille

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

signLanguage

signLanguage

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

structuralNavigation

structuralNavigation

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Scenario 28:tactileGraphic

tactileGraphic

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

tactileObject

tactileObject

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

transcript

transcript

Notes

Specification Scope: Indie UI User Context

Priority

Priority: HIGH (?)

Consensus decision: link to minutes or email

Related Requirements

Requirements

Mechanism

A user agent creates and maintains a profile of the user's needs and preferences. This profile can be interrogated by Web content using a specified API, subject to constraints intended to preserve the user's privacy (see requirements below).

The needs and preferences can be represented as key/value pairs.

The user agent populates the profile by obtaining information from one or more sources. No restriction is placed on the sources that may be used, but depending on the implementation these may include:

  • The configuration of the user agent.
  • The configuration of the operating system.
  • Assistive technologies (via available API calls).
  • The location and physical environment of the hardware, via sensors, positioning technology and other mechanisms.
  • Need/preference profiles retrieved from the Web in any format that the user agent supports (GPII, for example).
  • Inferences drawn from any of the above.

[Editorial note: should there be a hierarchy of sources, e.g., the user's explicit preferences override information gathered from the environment, or should this be left completely unspecified? It is undecided whether needs/preferences not readily available from the first two items above (and possibly also the assistive technology item) should be excluded from the first version of the specification.]

The user agent updates the profile in response to changes in any of the information sources that it supports. An event is dispatched to notify Web content of such updates.

Access Control

There is a basic set of keys in the need/preference profile that may be queried by all Web content using the API. The remaining keys may not be queried unless the user grants permission to do so. The user agent provides in its user interface a mechanism whereby the user can grant or withhold permission. (This is a user agent conformance requirement.) Once granted or denied, the permission applies to the browsing context as defined in HTML 5.

Grants and denials of permission may be maintained in persistent storage by the user agent and retrieved in subsequent interactions.

[Editorial note: It is undecided at what level of granularity the permission is granted or denied, e.g., for individual keys, for defined categories of keys or for all keys.]

Extensions

The API allows values to be retrieved for keys not defined in the specification. Such implementation-defined keys are distinguished (for example, by a namespace mechanism) from keys defined in the specification.

[Editorial note: the extension mechanism is distinct from the question of whether the specification itself should define a core of common keys and one or more modules that not every implementation is required to support.]

Specifiable Components of a User's Profile

This section identifies contextual items (needs, preferences etc.), which have been proposed for inclusion in the specification.

[Editorial note: use cases need to be added to the subsections below.]

General

  • The user's current point-of-regard. [Note: this isn't really a need or preference but it is part of the "context".]
  • Whether the user's keyboard settings allow all interactive elements to receive focus.
  • Whether the display colors are currently inverted by the operating system or user agent.

Type Settings

  • The user's default font size.
  • The user's minimum font size limit.
  • The user's preferred letter spacing.
  • The user's preferred line height.

Display Settings

  • The user's required display contrast.
  • Whether the user's display requires grayscale or supports full color.
  • Whether a lightly colored foreground text on a dark background, or dark text on a light background, is preferred.

Media Alternative Settings

  • Whether captions/subtitles should be presented.
  • Which languages are preferred for captions/subtitles (giving an order of preference).
  • Whether captions/subtitles for the deaf and hard of hearing, or spoken-language subtitles only, should be provided.
  • Whether closed captions should be used. [Editorial note: this item may be redundant.]
  • Whether a text transcript of audio or video is preferred.
  • Whether audio or video media should be presented simultaneously with the transcript (implies that a transcript is required).
  • Whether a video of sign language (i.e., a sign language translation) is desired.
  • Which sign languages are preferred (in order of preference). * Whether an audio description of video is desired.
  • Whether visual resources should be replaced or augmented by textual alternatives (e.g., images by descriptions).
  • Whether visual resources should be replaced or augmented by long descriptions.
  • Whether replacement or augmentation is preferred, i.e., simultaneous presentation of the visual content and the description, or substitution of the description for the visual material.
  • Whether auditory resources should be replaced by visual alternatives (e.g., sounds by visual notifications).
  • Whether text, visual content, or both should be replaced by spoken content (e.g., recorded or synthetic speech delivered as audio).
  • Whether synthetic speech or human speech is preferred.
  • Whether speech should always commence at the beginning of a recording or from the point at which it was last interrupted.
  • Whether spoken alternatives should be substituted only for directive content [Editorial note: definition required.]
  • Whether tactile content should be augmented or replaced by textual alternatives, and whether augmentation or replacement is preferred.
  • Whether tactile content should be augmented or replaced by visual content, and whether to augment or replace.
  • Whether tactile content should be augmented or replaced by auditory content, and whether to augment or replace.
  • Whether auditory content should be replaced or augmented by tactile content, and whether to augment or replace.
  • Whether visual content should be augmented or replaced by tactile content, and whether to augment or replace.
  • Whether visual content that flashes more than three times per second should be suppressed.
  • Whether content that simulates motion should be suppressed.
  • Whether sounds that can cause seizures should be suppressed.

Presentational Modality Settings

  • Whether textual content should be augmented or replaced by visual content, and whether augmentation or replacement is preferred.
  • Whether textual content should be augmented or replaced by audio content, and whether to augment or replace.
  • Whether textual content should be augmented or replaced by tactile content, and whether to augment or replace.

Assistive Technology Settings

  • Whehter a screen reader is active.
  • Whether a screen magnifier is active.
  • The name of each active assistive technology.
  • The version of each active assistive technology.
  • Screen magnifier properties, including zoom level, zoom window size and center point.
  • Whether content is required to be compatible with screen readers and other assistive technologies.
  • With which accessibility APIs or versions thereof the content is required to be compatible (e.g., Web or operating system-specific APIs).

[Editorial note: the desirability of some of the requirements in this section has been questioned. It has not been decided whether to disclose which assistive technology a user is running to Web applications, and further analysis of the issue is necessary in order to reach consensus.]

User Interface Organization and Complexity Settings

  • Whether a simple user interface is required.
  • Whether the number of user interface elements presented simultaneously should be limited.
  • Whether the text included in the content should use simple language or be suitable for a given reading level.
  • Whether the options and functionality available to the user should be restricted to those essential to the primary purpose of the interaction.
  • Whether symbols (in symbol systems used by persons with cognitive disabilities) should be substituted for text.

Matching Use Cases and Requirements

This is a table of requirements, with links to which section of the spec satisfies the requirement.

Requirement # Specification Section Link Test Links

Other Considerations

Sources and Inspiration

  • This format is based on the Audio WG Use Cases and Requirements
  • From the Indie UI WG charter: Indie UI: User Context 1.0 is A specification defining a set of properties and methods related to the environmental context of a specific user, and a vehicle to access them to facilitate a Web application's ability to adapt to the user's needs. This is meant to provide information about whether a user is using a screen reader, screen magnifier, or other Assistive Technology, and to expose relevant user settings, allowing optimal adaptation of the Web application's user interface. This has important privacy implications because the information exposed may imply facts about the user's disability, which can be socially or legally problematic if misused. These issues are important to resolve and the group will consult with the Privacy Interest Group and Web Application Security Working Group to help ensure these issues are fully addressed.