Re: Review Request; 1 of 2

Here are my initial comments for consideration by the group.

Guideline 2.7

1. Suppose that the user agent discloses certain accessibility-related
settings via a mechanism such as User Contexts 1.0. When the user changes a
setting which has been forwarded to a Web application in this way, the Web
application should be notified of the change so that it can adjust its user
interface appropriately.

IndieUI User Contexts is expected to provide the necessary mechanism (e.g.,
registration of a callback function) to support this, but the user agent
should also be required to dispatch the notification whenever a relevant
preference changes. Should this be specified anywhere, and if so, in UAAG, or
in User Contexts as a conformance requirement or as (informative) implementation advice?

2. An assumption in much of the discussion of IndieUI User Contexts is that a
user agent may adjust its accessibility-related settings spontaneously in
response to environmental conditions. For example, a mobile device may respond
to changes in environmental sound levels and light conditions. Guideline 2.7
addresses only settings which are adjusted explicitly by the user. If,
however, user agents are likely to make user interface changes in response to
environmental circumstances, should the user have an opportunity to suppress
or override these decisions? If so, should this issue be covered under UAAG
2.0 guideline 2.7 or addressed elsewhere?

This appears to be an issue for UAAG, not for IndieUI as such.

Guideline 2.1

1. The note following guideline 2.1 appropriately recognizes the possibility of
"modality independent controls", and refers usefully to the work on IndieUI
Events. It is unclear, however, how this note relates to the material that
follows. Specifically, as currently understood, the device independent
controls would be associated, within the user agent, with certain
device-specific controls, thereby providing a uniform set of actions to Web
applications that can be triggered by inputs appropriate to the user's
needs and hardware. By contrast, guideline 2.1 is concerned with the user
agent's input processing, which (unless operating systems implement modality
independent controls directly) remains modality and device-dependent. Should
anything under guideline 2.1 encourage user agents to implement modality
independent controls for the benefit of Web applications, and ultimately of
users?

2. Success criterion 2.1.1 has raised interesting questions in IndieUI
discussions as to whether keyboard operability should be required of all user
agents in order to be accessible. In particular, might implementing a
combination of other input methods be sufficient to satisfy the full range of
users' needs, or at least enough of them for the user agent to be considered
accessible in a minimal (appropriate to level A conformance) sense?
Furthermore, should user agents designed for specific environments (e.g.,
deployment in vehicles) be required to meet 2.1.1 in order to be considered
accessible? While participants in IndieUI have not given these questions full
consideration, much less drawn conclusions, they seem appropriate matters to
raise in relation to guideline 2.1.

Success criterion 2.12.2

This criterion raises a question of interpretation with respect to IndieUI
Events. If the user agent provides modality independent controls to Web
applications, does 2.12.2 then require these controls to be operable via any
device that the platform supports? Presumably, these controls are part of the
"user agent functionality other than text input" referred to in the criterion,
and hence the requirement would apply to them. This seems reasonable in view
of the fact that 2.12.2 is at level AA, but the implication is one that
implementors would need to take into account should they wish to support
IndieUI Events and satisfy 2.12.2.

Received on Thursday, 9 January 2014 01:05:26 UTC