Re: User contexts submission - general comments

Hi Jason,

Good to be working with you again. I am in your neck of the woods, Sydney,
Australia, this week but have limited access to email. This submission is
from Andy and I, and although it is used in education, it is indeed not
limited to education.

We can work to get you use cases from IMS but keep in mind we do not want
to reproduce 8 years of work and implementations for this effort. There is
tremendous value in reusing what has already been established. Furthermore,
the U.S. Department of Education is looking to adopt APIP and AccessForAll
so we have industry uptake. It is understood that we need to expand on the
vocabulary, ... particularly for device capabilities such as touch devices.

So, from our perspective this submission talks to the vocabulary.

The API should have the ability to get properties, and be notified of
context changes. Although we can prototype with a plug-in we also need to
have the browser be able to adjust the properties based on situational
changes such as noisy areas.

Rich

Rich Schwerdtfeger



From:	Jason White <jason@jasonjgw.net>
To:	public-indie-ui <public-indie-ui@w3.org>,
Date:	08/08/2012 03:59 AM
Subject:	User contexts submission - general comments



I am responding to the submission as posted by Andy Heath to this list. The
submission offers a welcome and useful summary of prior work relevant to
the
proposal to develop a user contexts specification as described in this
group's
charter and work statement.

Several of the standards cited in the submission have been developed and
applied in an educational setting, whereas this working group is required
to
consider a wider variety of applications in order to create a technology
suitable for the Web generally. As a first step, it would be very helpful
to
have a collection of use cases from which to work, including some of the
educational scenarios that have influenced the work of IMS Global and ISO,
in
addition to cases of interest to those concerned with mobile devices,
touch-screen and speech interfaces, and accessibility. The success of a
user
contexts specification will be determined, in part, by its ability to
address
the overlapping as well as the distinct needs of diverse users and devices,
including mobile delivery contexts.

The submission suggests defining a Web API enabling Web applications to
query user context assertions. Assistive technologies and other tools
implemented in Web technologies, as browser extensions for example, will
also
need to be able to set and modify the user context. This raises the
question
of whether the API should also provide functions for this purpose, and I
think
it should; otherwise these functions would be left to user-agent-specific
extension APIs and it would be more difficult to implement an assistive
technology or other tool that is compatible with multiple user-agents.

A final issue that I would like to raise here concerns the interaction of
user
contexts with accessibility requirements and best practices for designing
mobile applications. The purpose of the user contexts specification is to
facilitate customization of the application according to the delivery
context.
I think it is important to ensure that the use cases amount to genuine
customizations that extend beyond the requirements of accessibility and
other
applicable guidelines. The purpose of allowing a user context to be
asserted
is to empower the author of a Web application to create a user interface
which
better meets the needs and preferences of the user, in ways that are not
otherwise required or expected. Clearly, if no user context is asserted,
whether for privacy or other reasons, accessibility guidelines would need
to
be satisfied by default, since it is still possible that the user has
unasserted access needs; the only circumstance in which one would depart
from
such access requirements arises where user context assertions are made
which
are incompatible with them. For example, an assertion amounting to
"captions
are not required" would justify omitting markup that associates captions
with
multimedia. Whether simply not asserting a user context attribute should be
deemed equivalent to asserting its negation is an open issue. For privacy
reasons, one might refrain from asserting an attribute/property that
actually
holds true in the delivery context, without wanting it to be treated as an
assertion that the associated support (e.g., for captions) should not be
provided. I am simply raising the issue here, not attempting to decide it.