Independent User Interface Task Force Teleconference -- 26 Jun 2013

<trackbot> Date: 26 June 2013

<janina_> Meeting: IndieUI Task Force Teleconference

preview agenda with items from two minutes

<jasonjgw> Janina explains that the purpose is to introduce news relevant to the group and make any adjustments to the agenda.

<hober> Scribe: jasonjgw

Michael notes the technical plenary meeting page.

<MichaelC> TPAC 2013 for IndieUI

Visa requirements are noted, which must be addressed in good time prior to the meeting.

Also Janina notes that registration information is on the page and that forms should be completed. More details of the meeting will be added in due course. Thursday and Friday 14 and 15 November are the meeting dates.

<Zakim> James_Craig, you wanted to ask what this means: "There are slots for up to 4 people to join [Zakim] at a given time. "

Michael clarifies that typically 4 slots are reserved on the bridge at face to face meetings, but more can be requested if necessary.

<jcraig> ISO-24752?

<jcraig> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42311

<jcraig> ISO-24751 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=41521

Janina notes the Universal Remote Console specification, ISO 24752 - means of negotiating remote console access to devices. Also noted is ISO 24751 considers how to support user preferences, and therefore has relevance to our work.

There's a registry associated with 24751.

<hober> jasonjgw: access to ISO documents is different than with the W3C; will we be able to get copies of these documents?

<hober> janina_: yes

Jason and Janina discuss accessibility of the specifications, to be continued off-line.

TPAC2013 https://www.w3.org/2013/11/TPAC/

Editor's Update

<jcraig> ACTION-55?

<trackbot> ACTION-55 -- James Craig to add DOMImplementation.hasFeature() specifics for IndieUI Events -- due 2013-06-24 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/55

James notes technical errata and notes that the basic IndieUI module is in WebKit under an implementation flag. Work on keyboard operation is ongoing. There are two actions to complete prior to next heartbeat draft of Events.

<jcraig> ACTION-56?

<trackbot> ACTION-56 -- James Craig to determine how to add interface for accessing interface constants, (e.g. valuechangerequest.UNKNOWN = 0; valuechangerequest.INCREMENT = 1; valuechangerequest.INCREMENT_SMALL = 2;) so authors don't have to memorize all these integers. -- due 2013-06-24 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/56

The first is to allow authors to determine which features have been implemented. Also action 56, to create a property of the window object to define constants for values (sliders etc.).

James clarifies that parts of IndieUI Events have been implemented, including the infrastructure required.

Janina raises the question of whether Blink (Chromium) will write a separate implementation or take the WebKit code, and this will affect implementation discussions later.

Value change and dismiss request James thinks have been implemented.

Publishing an Events Stabilization Draft

<jcraig> first IndieUI commit for WebKit https://bugs.webkit.org/show_bug.cgi?id=117367

<jcraig> https://www.w3.org/WAI/IndieUI/track/products/2

James explains that there are 14 actions and 4 issues pertaining to IndieUI 1.0 events. He notes issues with media events, mark requests (selection, drag/drop) which all need to be added to the spec. These may or may not be included in version 1.0, subject to working group decisions.

Last Call later this year may be feasible on this basis.

<jcraig> point-of-regard focus and blur events also need to go into 1.0

Janina suggests moving to Last Call sooner rather than later.

<jcraig> ACTION-58?

<trackbot> ACTION-58 -- James Craig to add another UIEvent for point-of-regard focus and blur (separate from keyboard focus/blur) -- due 2013-06-28 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/58

Michael notes the need to formalize and clarify requirements so that it can be assured at the CR stage that the spec meets its requirements.

Janina notes that a sooner last call entails a less ambitious 1.0 spec.

<jcraig> Automated IndieUI tests starting here: http://trac.webkit.org/browser/trunk/LayoutTests/indieui/

Michael clarifies that the time-frame under discussion is consistent with clarifying the requirements, as necessary.

James suggests raising certain issues with the Web Applications working group - event object changes require coordination.

Michael suggests including requests for feedback on these points in the heartbeat draft, and we can be sure to raise the questions with them. It's also important to have well documented requirements associated with potentially controversial changes that necessitate inter-group coordination.

<jcraig> Appendix B. Normative changes since the last public working draft https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#changelist

Events Module Timeline

Testing Events Discussion

Janina explains the need to prepare for testing well ahead of last call. It should be happenging for events approximately now.

There is also a question regarding tools to be adopted for handling test cases.

Michael notes that there are several testing harnesses available, including a W3C harness and the one used by PF for Aria.

Michael also notes that testable requirements need to be identified. There must be two implementations of every normative requirement.

<Zakim> James_Craig, you wanted to mention Automated WebKit tests for IndieUI starting here: http://trac.webkit.org/browser/trunk/LayoutTests/indieui/

He clarifies further that the events need not be tested for all HTML elements, for example.

James acknowledges the difficulty of sharing automated tests among implementations, due to different test harnesses.

Michael emphasizes the value of automated testing of rendering engines to reduce manual testing.

He notes that markup may be added to the spec to identify normative requirements.

<hober> jasonjgw: i'm interested in helping with testing

Janina calls for volunteers.

Requirement gathering for User Contexts: next steps http://lists.w3.org/Archives/Public/public-indie-ui/2013Jun/0022.html

<hober> Scribe: hober

jasonjgw: not much to say since last meeting
... coordinating with michael to get the reqs doc up on the wiki
... open to additional use cases
... would like contributions of reqs and use cases from implementors and folks from other wgs
... we should add use cases for each section of the doc
... we can then look to see if we need more granular cases
... we're not yet at the stage of removing requirements
... holding back on deleting reqs for now

MichaelC: got jasonjgw's use cases into the wiki just before the call

<MichaelC> Jason´s proposal for User Context Requiremnets

[MichaelC and jasonjgw double check that jason's content got on there correctly]

janina_: we want to look at the iso documents mentioned earlier to see if that adds anything here
... secondly, is there a good cheat sheet for people to work with the wiki in emacs

hober: i should be able to help with that (wiki editing in emacs)

<scribe> Scribe: jasonjgw

User Contexts: identifying AT

Janina asks whether anyone wants to add comments regarding this issue or raise questions.

James is concerned about the perception that people may be locked out of access if they don't identify their AT. He explains a parallel with location sharing, which doesn't prevent a Web site from working if sharing is not permitted by the user.

He explains that there are valid use cases for AT-specific preferences in rare but significant cases.

<hober> jasonjgw: i didn't quite catch the use case

<hober> jasonjgw: i think the concern was the way in which less scrupulous implementors could not enable a11y features if the user doesn't declare their AT requirements

<hober> jasonjgw: not about access being blocked, but the question was to how vulnerable is this tech to misuse

Rich clarifies that there are cases in which implementations turn off accessibility features entirely for performance reasons: they won't support those features unless they know that an assistive technology of a specific type is running.

He cites several examples. In at least one instance, the user has to active accessibility explicitly through a menu option.

The concern is that some Web applications will not include accessibility support unless AT is declared (if such a declaration is made possible by IndieUI Events).

<jcraig> For example, one use case was a Zoom user visiting a website which displayed a alert outside the viewable window of the zoomed AT. If the user exposes certain aspects of their AT, the app can adapt and display the alert within the available view.

Rich argues that we should obtain wider input regarding these issues.

<Zakim> James_Craig, you wanted to respond to Rich's point about Google Docs performance

Janina notes thtat we are over the hour and that this conversation will continue.

James notes that a Web application can provide a means in the user interface to turn on accessibility in such cases.

Rich clarifies that Web applications could by default not expose Aria features unless the user agent declares a need for them, via AT preferences.

James clarifies his point that, for example, a prominent control in the Web application's UI can then offer to enable Aria and other accessibility features.

Janina closes the meeting at this point.

- DRAFT -

Independent User Interface Task Force Teleconference

26 Jun 2013

Attendees

Contents