Web Accessibility Initiative: WAI Activities Proposal Review

RNIB strongly supports this working group proposal and looks forward to being able to raise awareness of the outcomes from the group. Although we are unable to participate directly in the group at this time we would like to offer support where we can on reviewing work and drafts.

Response:

Thank you, we appreciate that the value of this will be understood by the accessibility community and we look forward to your help in evangelizing this technology.

The scope section is too vague. I'm supporting this because I assume it means the same thing as the representational events part of the Web Events WG charter. It should be as clear as the scope in that charter. I don't think this should be delayed to make it clearer, but as part of the approval process (without any additional delay) some more detail in the charter would be good. We don't need to join this WG because we are already in the Web Events WG. But if we did have to join the vague charter would cause us pain in our internal review about what the scope is.

Response:

We have added some specifics to the Scope section to clarify the two specific deliverables. In the deliverables section, we have also clarified that these deliverables overlap with the "higher-level user-action events" mentioned as part of the overall deliverable of the Web Events charter, while the Scope section specifically places out of scope any other aspects of the Web Events work. We added examples of the types of events and clarified that they are "granular user interface events" to underscore that broader event models are not in scope. We also explained out the user agent's role in mapping between platform-specific events and Indie UI.

The primary addition to the scope section that reflects these changes is "The types of actions that can be represented in this model are those prevalent among GUI and Web applications at this time, such as scrolling the view, canceling an action, changing the value of a user input widget, selecting a range, placing focus on an object, etc. These are basic user interface gestures that are common to most platforms but are actuated in various ways depending on hardware features, system design, and user interaction modality, yet via Indie UI can be exposed in a simple and universal manner to Web applications. These events enhance or complement APIs from other Working Groups, and provide an intermediate layer between device- and modality-specific events (which are out of scope) and the functionality needed by Web applications."

The updated description of the Indie UI: Events deliverable that reflects these changes is: "Indie UI: Events 1.0, an abstraction between device-specific user interaction events and inferred user intent such as scroll, activate, etc. This provides an intermediate layer between device- and modality-specific user interaction events, and the basic user interface functionality used by Web applications. Indie UI: Events focuses on granular user interface interactions such as scrolling the view, canceling an action, changing the value of a user input widget, selecting a range, placing focus on an object, etc. Implementing platforms will take modality-specific user input, user idiosyncratic heuristics to determine the specific corresponding Indie UI event, and send that to the Web application (along with details of the modality-specific input such as mouse or keyboard events should applications wish to process it)."

Clarify the relationship with the Model-Based UI Working Group, part of the Ubiquitous Web Activity (for details please contact carlos.velasco@fit.fraunhofer.de)

Response:

At this time it is not clear what relationship there may be between Indie UI and Model-Based UI. MBUI appears to be a fairly low-level way of generating user interface that would not in itself impact the Indie UI model. If the MBUI model would benefit from incorporating Indie UI, then the Indie UI WG would support that and would be open to coordinating with their group on additional features needed. We have added this liaison to the charter to explore this relationship further.

1) Microsoft feels that the charter is too vague. We would like to see the scope limited to the listed deliverables, and would like a draft of each deliverable to be included for consideration. In particular, we would like more detail on what is in and out of scope for User Context. For Indie UI, We would like direct access to Assistive Technology to be out of scope, as it is device dependent and compromises the integrity of the accessibility API layer.

2) Once the charter is updated with more specificity, we will further evaluate our participation in this work.

Response:

To address your concerns about concreteness of the scope section, we have modified the Scope section to state explicitly that Indie UI: Events 1.0 and Indie UI: User Context 1.0 are the only two Recommendation-track deliverables, and that any other Recommendation-track deliverable is explicitly out of scope. We are also clarifying that Indie UI is an intermediate layer between device- and modality-specific events (which are out of scope) and the functionality needed by Web applications.

The description of Indie UI: User Context in the Deliverables section is "a set of contextual properties and methods, and a vehicle to access them to facilitate a Web application's ability to adapt to the user's needs within a particular context." We are adding a clarification that this is meant to provide information about whether a user is using a screen reader, screen magnifier, etc. and relevant settings of the AT (if the user chooses to allow this information to be exposed). The updated description reads: "Indie UI: Events 1.0, an abstraction between device-specific user interaction events and inferred user intent such as scroll, activate, etc. This provides an intermediate layer between device- and modality-specific user interaction events, and the basic user interface functionality used by Web applications. Indie UI: Events focuses on granular user interface interactions such as scrolling the view, canceling an action, changing the value of a user input widget, selecting a range, placing focus on an object, etc. Implementing platforms will take modality-specific user input, user idiosyncratic heuristics to determine the specific corresponding Indie UI event, and send that to the Web application (along with details of the modality-specific input such as mouse or keyboard events should applications wish to process it)"

While the motivation behind requesting a draft of the proposed deliverable is understandable, charters for new groups typically don't have such a draft available to reference - it requires the group to be formed first to produce such a document. There is an unofficial starter draft posted in the Protocols and Formats WG, but it does not represent any consensus-based input into the work, so was not appropriate to reference from the charter. As soon as the group is formalized we plan to prepare a consensus-based draft and reference that from the group home page.

Member A is strongly supportive of the WAI Activities -- including the newly proposed work on Indie-UI. However we would like to see the following changes incorporated to ensure that the WAI technical activities have the maximal chance of success in today's standards landscape.

1. WAI-PF: Make it a fully open group that does its work in public.

WAI-PF being a member-confidential group is a carry-over from the past that needs to change. At one point, many/all of the groups that the PF group liaised with were member-confidential, which forced PF to be member-confidential. Over the years, the shift in the standards landscape has caused WGs that wish to be relevant to move to a public WG model; that shift has made PF's work as a member-only group a significant handicap with respect to its effective working with groups such as HTML-WG, WebApps. We are happy to see that the new Indie-UI group will operate in public; it's even more important that PF also now be made a public WG.

Response:

This issue with the Protocols and Formats Working Group was raised and responded to during the November 2010 rechartering of the group (Director Announcement, detailed Disposition of Comments). The charter for the Protocols and Formats group is not itself up for review at this time. Nevertheless, we hope that the following clarifications will be helpful in addressing your concerns for now. Because of the nature of its interface with other groups that may operate primarily in Member-visible space, the Protocols and Formats Working Group must have the ability to operate in this space. However, it is true that much of its work now is not required for coordination reasons to be in Member-visible space. The issue of making these aspects of the PFWG public was raised in the previous update to the WAI Activity Statements. The group has been conscious of this and uses several resources to make its work more public, including the x-tech mailing list which is increasingly the primary locus of technical discussion; the public archive of comments; public information about the status of comments being processed; public Editors' Drafts; a mailing list public-pfwg-cvs@w3.org to announce edit commits; a publicly visible wiki; and the public PFWG home page. It now conducts most of its work via task forces, and new task forces are automatically public (unless they are joint with a Member-only Working Group, a situation that has not arisen yet). Two aspects of its work that have historically not been public include the overall work coordination meeting, and the ARIA development task force. This is an ongoing project over the term of the current charter with the expectation that a formal change will be made at the next charter update, in July 2013.

2. Feedback on the Indie-UI Charter:

We would like to see the deliverables for the Indie-UI group to be made more concrete so that member companies can make the relevant IP commitments up-front, rather than receiving surprizes later in the process. We note that the charter explicitly places voice and touch interaction to be out of scope; however, it's not clear what *is* in scope. We have reviewed the initial draft proposal that went to the PF group a while ago and are in general supportive; however, we would like to see this portion of the deliverable tightly scoped.

Response:

There are two specific deliverables in the charter, and the Working Group's activity is limited to these deliverables. These are described in specific terms in the Deliverables section of the charter, and more generally in the Scope section. We have added some specifics to the Scope section to clarify this. In particular, the charter specifically places out of scope any other aspects of the Web Events work. Because this is a new Working Group, there are no formal drafts available to provide further information about the nature of the proposed deliverables. However, an initial proposal entitled User Interface Independence for Accessible Rich Internet Applications was posted to the wai-tech mailing list, and a follow up unofficial starter draft was posted in the Protocols and Formats WG, but it does not represent any consensus-based input into the work.

3. The second deliverable for the Indie-UI group needs to be concretely specified for the same reasons as above --- presently it reads:

<cite>
o Indie UI: User Context 1.0, a set of contextual properties and methods, and a vehicle to access them to facilitate a Web application's ability to adapt to the user's needs within a particular context. This will be a joint deliverable with the Web Events WG.
</cite>

We ask that "context" above be clearly defined, and that the work be clearly scoped to avoid the WG rat-holing with scope-creep. Note also that this has strong implications on privacy and we would like to see those dependencies called out.

Response:

The description of Indie UI: User Context in the Deliverables section is "a set of contextual properties and methods, and a vehicle to access them to facilitate a Web application's ability to adapt to the user's needs within a particular context." This is meant to provide information about whether a user is using a screen reader, screen magnifier, etc. and relevant settings of the AT (if they choose to allow this information to be exposed). We have added the latter clarification to the charter.

We are very conscious of the privacy issues related to this technology, although it seemed a detail that did not need to be called out in the charter. However, we have added reference to this in the description of the deliverable. Since the time the charter was first proposed, a Privacy Interest Group has been created, so we are adding a formal liaison to that group as well. To address possible security issues we are also adding a liaison to Web Application Security Working Group.

4. The Indie-UI needs to explicitly liaise with the W3C's activities in speech interaction -- including but not limited to VBWG. At present the charter calls out the connection to the MMIWG -- but in our experience, that group has not produced anything that is relevant or implementable on the Web. the Indie-UI charter needs to explicitly call out connections between the work from the HTML-Speech XG as that work moves forward within the W3C Process --- since it's not yet clear how that will happen, we ask that the charter broadly calls for liaison between Indie-UI and any/all speech-related standards work at the W3C.

Response:

A Speech API Community Group was formed after the time the Indie UI charter review was closed. Because this group now exists, it is possible to use it as a liaison point for speech, so we have added this liaison to the charter. The Indie UI Working Group will also document active liaisons on its group home page to accommodate new points of contact that emerge.

5. Success Criterian: At present, the charter does not lay out any success criteria for the Indie-UI group -- and in our experience, charters for WGs that fail to do this create WGs that last for ever. Please define concrete, measure CR exit criteria -- e.g.:

A. The group's "abstract" mechanisms/APIs are used by at least 2 interaction modalities,
and
B. That the above have two interoperable implementations within mainstream browsers.

Response:

We have updated the success criteria to include "The technology is demonstrated interoperable via at least two implementations in user agents of each normative feature".

6. Finally, we note that Indie-UI has a strong dependency on WebEvents; and that that WG's work is going to get stalled due to IP claims from a member company. We consider the Indie-UI work to be placed at considerable risk because of this --- to the extent that the group's work will ultimately fail because any/all abstract mechanisms it creates will remain irrelevant because there is nothing concrete to map to e.g., Touch and/or Voice -- we urge the Team to look ahead and prepare for success -- rather than launch a WG that is set up for failure.

Response:

Independent User Interface is a separate layer from the majority of events dealt with by the Web Events Working Group. Although it is true that Indie UI events would be triggered by a translation of hardware events to inferred user intent events, the specific event model of Indie UI is not dependent on this translation. Indeed, different hardware devices or software applications may translate between these layers differently, as a way to maintain a proprietary "look and feel". For this reason, normative mappings between Indie UI events and other layers are unlikely to exist, though informative suggestions may be provided. Therefore, Indue UI is not directly dependent on the work of the Web Events Working Group. The dependency in the charter reflects the desire of both groups to develop Indie UI, but should the Web Events WG fail, the work on Indie UI in the Indie UI WG would still be able to proceed, both procedurally and technologically.