Independent User Interface Task Force Teleconference -- 18 Dec 2013

<trackbot> Date: 18 December 2013

<janina_> Meeting: IndieUI Task Force Teleconference

preview agenda with items from two minutes

<jcraig> Big editor's report here: http://lists.w3.org/Archives/Public/public-indie-ui/2013Dec/0018.html

<MichaelC> scribe: jasonjgw

<janina_> http://lists.w3.org/Archives/Public/public-indie-ui/2013Nov/0032.html

Janina notes a request for review from the UAAG working group of particular sections of User Agent Accessibility Guidelines 2.0.

The primary concern is to avoid inconsistencies between UAAG 2.0 and the work of IndieUI.

Janina suggests that we all carry out a review.

James notes that UAAG guideline 2.1 requires full keyboard access, which will not be a strict requirement as abstract user interface events become available.

James clarifies in discussion that UAAG appears to be requiring more than WCAG 2.0 - that is, UAAG appears to require full keyboard access.

Jason notes that WCAG 2.0 refers specifically to a keyboard or keyboard interface and therefore has a wider scope.

James notes interfaces that are fully speech-oriented (in cars for example), and which are not going to be operated via a keyboard. He suggests that user agents need not be fully keyboard operable.

He clarifies that operability is a requirement but it need not be via a keyboard/keyboard interface.

Maybe it's "through a keyboard or other API".

Janina notes the significance of the issue and suggests a group or individual comment on the point.

Michael suggests the assumptions of WCAG 2 are no longer valid - it was originally thought that even a non-keyboard-based technology would ultimately provide its input via a keyboard interface, but current practice has already transcended this assumption and will do so increasingly.

Janina: next meeting - 8 January 2014. The meeting on 22 January is problematic due to travel of some participants to the ARIA face to face meeting.

Calendar Review and Updates Through January 2014

<jcraig> Summary of my comment: "Guideline 2.1 - Ensure full keyboard access" could be better phrased as "Guideline 2.1 - Allow a keyboard interface or another equivalent API interface that allows full access to the content."

A decision will need to be made, once travel plans are known, about that meeting.

Editor's Report

<jcraig> Although "keyboard interfaces" should be supported in web content (WCAG), requiring User Agents to support full keyboard access (UAAG) is not as relevant with modern interfaces: mobile devices, car interfaces, speech interfaces, etc.

James notes the report posted to the list. All of the changes arising from TPAC have been made to the User Contexts draft.

<jcraig> Summary of substantive changes to IndieUI User Context from today's editor report: http://lists.w3.org/Archives/Public/public-indie-ui/2013Dec/0018.html

<jcraig> 1. Brought back the general JavaScript interface (was window.settings.valueForKey(); now window.userSetting()) for accessing all user settings, including those that do and do not make sense as media features.

<jcraig> 2. Removed the Media Features that the CSS editor (Tab Atkins) objected to. These settings can still be queried via the userSetting() method, but are no longer proposed as Media Features.

This covers all settings, including those which may be treated as media queries.

<jcraig> 3. Demoted remaining Media Features to be an alternate means of access through @media and matchMedia, rather than the primary interface for IndieUI User Context.

All settings can be queried through a simple JavaScript interface; a subset can be obtained via media queries.

<jcraig> 4. Clarified some example uses of color settings using HSLA suffixes (e.g. user-background-color-luminosity, user-subtitle-background-color-alpha) as useful Media Features.

<jcraig> Discussion of this idea is ongoing with the CSS WG. I plan to follow-up on www-style in the New Year.

Thus those which can be accessed through media queries can be obtained in two ways (via two distinct interfaces).

<jcraig> 5. Reorganized the document to list the Settings Keys along with an optional “Associated Media Feature” where appropriate. Presumably these Media Feature references will eventually move to the CSS specs. One such example (monochrome) is already in CSS3, so it’s referenced by link rather than specified in the IndieUI User Context draft.

Example: using media queries to respond appropriately to colour contrast.

The associated media feature would be supplied as a reference to a CSS spec; it would not be specified by IndieUI.

<jcraig> 6. Brought back some additional Settings (e.g. subtitle-languages) that were never attempted as Media Feature because that format didn’t make sense for these settings.

<jcraig> 7. Removed the taxonomy parameter of the previous JS interface in favor of using a simplified prefixed key name for taxonomy- or vendor-proposed settings. e.g. window.settings.valueForKey('foo', 'bar') would now be accessed as window.userSetting('-bar-foo'). It was also proposed this could/should be a map (window.settings.fooBar or window.settings['fooBar']) but my understanding is that the map approach would not work well with the privacy model, so this needs

<jcraig> to be an explicit accessor method.

Subtitle language and certain other settings have been re-introduced, now that there are two separate interfaces (media queries and User Contexts' own).

An extension mechanism is introduced, e.g., to allow ua extensions to provide Web applications with access to GPII properties.

The suggested mechanism is a vendor prefix.

<jcraig> 8. Clarified the privacy model some more.

Editorial clarifications have been made to the privacy model.

James clarifies in response to Katie that the privacy determinations are made per user or per device depending on whether the device/OS is single-user or multi-user (i.e., different login sessions are active).

He further clarifies that the granularity of the user prompting is not specified normatively.

Informative advice is provided, e.g., that subtitle-related settings would be prompted for separately from screen reader-related settings.

It would however be a valid implementation to combine these.

This is essentially similar to prompting for location sharing.

<jcraig> 9. Added additional code examples.

James further clarifies that in most cases the user will be logged into and hence identifiable by the Web application.

<jcraig> 10. Updated some of the ReSpec utilities for auto-generating sections/lists based on other markup in the document. e.g. there are now generated alphabetical lists of the settings keys and media features referenced in the document.

James proceeds to note that he has added code examples.

<jcraig> 11. Added IDL methods to bind settings listeners (window.addUserSettingListener and window.removeUserSettingListener) as well as the IDL for the callback interface (handleUserSettingChanged).

<jcraig> 12. Various editorial changes and to-dos.

James notes that he added a callback mechanism.

<jcraig> Current Editor’s Draft

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html

James and Janina discuss progress, with the suggestion of a first public working draft in January or February.

James notes regarding privacy that (entirely independently of IndieUI) the personal identification and tracking problem is already very significant due to already available technologies such as tracking of users on 802.11 networks within buildings.

Katie notes that this issue is generally addressed by non-technical (i.e., regulatory) mechanisms and emphasizes the importance of having taken it into account in designing the spec.

There is discussion of the W3C's privacy work and the possibility of having our approach reviewed appropriately.

Janina clarifies that we should have our approach well defined before requesting review from privacy-related groups, e.g., privacy interest group.

Michael notes this is a charter obligation.

James suggests inviting such review once the architecture of the technology is reasonably well settled.

James: Microsoft's high contrast mode proposal is currently not subject to privacy restrictions and has been designed very specifically to reflect Microsoft's implementation.

The IndieUI proposal generalizes the properties to work across a variety of different implementations.

<jcraig> -ms-high-contrast: active; would be equivalent to:

<jcraig> contrast: 1;

<jcraig> -ms-high-contrast: black-on-white; would be equivalent to:

<jcraig> contrast: 1;

<jcraig> user-color: black;

<jcraig> user-background-color: white;

<jcraig> -ms-high-contrast: white-on-black; would be equivalent to:

<jcraig> contrast: 1;

<jcraig> user-color: white;

<jcraig> user-background-color: black;

<jcraig> -ms-high-contrast: none; would be equivalent to the default value:

<jcraig> contrast: 0;

Events Requirements Status & Actions

<MichaelC> IndieUI Requirements

Michael introduces the question raised on the list of whether requriements for both specs should comprise a single document.

His current draft combines Events and User Contexts requirements. He summarizes the structure of the draft.

The Events Requirements section now captures the items developed at the face to face meeting.

Michael notes the need for additional explanatory text to accompany some of the items.

For tracking purposes, the requirements are currently linked to the Events draft.

There are requirements which currently aren't justified by any of the existing scenarios. Some of these are substantive features that should be associated with scenarios.

Michael suggests maintaining a single document encompassing both specs; the requirements need not be published formally as a note before Events becomes a recommendation.

Michael clarifies that post-1.0 requirements will be documented separately at that time, and any which are currently not met by the draft need to be satisfied, dropped or moved to post-1.0 requirements.

Janina: next meeting, 8 January.

- DRAFT -

Independent User Interface Task Force Teleconference

18 Dec 2013

Attendees

Contents

preview agenda with items from two minutes

Calendar Review and Updates Through January 2014

Editor's Report

Events Requirements Status & Actions

Summary of Action Items

Scribe.perl diagnostic output