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
WARNING - IN EDIT AT THIS TIME -andy
Contents
- 1 Requirements, Use Cases, Scenarios, Preferences
- 1.1 Plain Access Mode Alternatives
- 1.2 Superimposed Access Mode Alternatives
- 1.3 Miscellaneous Access Mode Alternatives
- 1.4 accessFeature Preferences
- 2 Legacy Stuff
- 2.1 AT Compatible
- 2.2 accessHazard:flashing
- 2.3 accessHazard:motionSimulation
- 2.4 Scenario 4: accessHazard:sound
- 2.5 auditoryForVisual
- 2.6 Scenario 6: textualForAuditory
- 2.7 textualForVisual
- 2.8 Scenario 8:visualForAuditory
- 2.9 Scenario 9:visualForTextual
- 2.10 Scenario 10:auditoryForText
- 2.11 alternativeText
- 2.12 Scenario 12:audioDescription
- 2.13 braille
- 2.14 captions
- 2.15 Scenario 15:ChemML
- 2.16 describedMath
- 2.17 displayTransformability
- 2.18 haptic
- 2.19 Scenario 19:highContrast
- 2.20 largePrint
- 2.21 latex
- 2.22 longDescription
- 2.23 MathML
- 2.24 musicBraille
- 2.25 nemethBraille
- 2.26 signLanguage
- 2.27 structuralNavigation
- 2.28 Scenario 28:tactileGraphic
- 2.29 tactileObject
- 2.30 transcript
- 3 Requirements
- 4 Matching Use Cases and Requirements
- 5 Other Considerations
- 6 Sources and Inspiration
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
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
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.