Protocols and Formats Working Group (PFWG) Charter

Table of Contents

  1. Mission
  2. Scope and Success Criteria
  3. Duration
  4. Deliverables
  5. Milestones
  6. Dependencies
  7. Confidentiality
  8. Meetings
  9. Communication
  10. Voting
  11. Patent Policy
  12. Participation

This charter is written in accordance with Section 6.2.6 of the 14 October 2005 W3C Process Document.

Information on how to participate in the PFWG is available.


1. Mission

The mission of the Protocols and Formats Working Group (PFWG) (Member Confidential PFWG) is to increase the support for accessibility in Web specifications. This mission flows from the W3C mission of promoting universal access and interoperability across the Web.

Through its relationships with other Working Groups, and with the assistance of the Hypertext and WAI Coordination Groups, the PFWG will work to coordinate plans of action across working groups to improve the level of accessibility support in Web technology as it evolves and is implemented.

Wherever possible, the Working Group will document solutions to problems as they are worked out.  This information will help to inform future developments.  This will take the form of the XML Accessibility Guidelines (XAG), several Recommendations supporting the accessibility of dynamic Web content, and various Working Group Notes as described under Deliverables below.

This mission is complementary to the work of other Web Accessibility Initiative (WAI) groups within the WAI Technical Activity and the WAI International Program Office Activity. The PFWG is part of the WAI Technical Activity.

The PFWG was chartered in December 1997. It has been re-chartered in November 2000 and again in January 2005.

2. Scope and Success Criteria

The PFWG's scope of work includes:

Consistent with W3C Process requirements on Task Forces, the PFWG may spawn or join Task Forces working on topics pertinent to this general scope.

Minimum success criteria for PFWG will be that they review all new W3C specifications that bear directly on the user experience not later than in Last Call, and that they release a 1.0 version of a role taxonomy and a states and properties specification that affords the authors of scripted interactive widgets a clear path to get their interactive objects interoperating with the client platform accessibility APIs (see Deliverables, below). 

Beyond the minimum success criteria (above) for this charter, PFWG's goals are to contribute to the following criteria with regard to the Web:
functional:
People with disabilities do not encounter the failure of functions of the specified technologies as a result of their disability.
usable:
Web content and applications implemented using the specified technologies can be adapted for people with disabilities with a high level of usability.
interoperable:
Accessibility involves both "direct" accessibility, without additional technology, and also accessibility by compatibility with assistive technologies.  Web technologies can optimize compatibility with assistive technologies through full support of applicable protocols and accessibility APIs.
authorable:
Content that exhibits the above-described broad, high usability is easy to author based on the formulation of content formats and service protocols.
small footprint:
Compatibility with assistive technology will be optimized where assistive technology has to implement a minimum of special logic or code to deal with the Web.   This will be the case if, in W3C specifications, similar functions occurring in different Web technologies are handled in consistent or at least compatible ways.

3. Duration

This Working Group was scheduled in the January 2005 charter to last for 36 months, from 1 January 2005 through 31 December 2007. This charter update does not change the duration, but includes updated deliverables as described in section four.

In January 2008, the duration of this charter was extended to 30 June 2008 (Member-only link). In November 2008, the duration of this charter was extended to 31 December 2008 (Member-only link). In April 2009, the duration of this charter was extended to 30 June 2009 (Member-only link).

4. Deliverables

4.1 Feedback to specification developers

The primary deliverable of PFWG is input to W3C Working Groups on the technologies they are developing. This will include:

Comments on Drafts
The Working Group will review working drafts of technology developers to detect and explain problems in the drafts.
Topical Discussion
From time to time the Working Group will seek real-time dialog with other groups when a point at issue requires considerable background or to frame the general issues for a technology early in its development cycle. In particular it has proven productive to seek ad-hoc discussions when the first reaction of a Working Group is to reject a comment that the PFWG has lodged. Many of these points can be resolved to mutual satisfaction with careful analysis and review of alternatives.
Expert Opinion
In a situation where a third party has inferred a disability access issue and the Working Group developing the draft either requests assistance or rejects the comment, the Protocols and Formats Working Group may offer to assist in clarification.

4.2 XML Accessibility Guidelines (XAG)

The XML Accessibility Guidelines explain best practices for creating more accessible XML-based document formats.  Generic practices identified in the course of more topical solutions will be added to this volume.  The Working Group will evaluate whether to publish this specification as a Working Group Note under this charter or request that W3C approve rechartering the group to publish it as a W3C Recommendation.

The XML Accessibility Guidelines will be structured and edited to serve as a technology architect's bridge to the user-centric W3C Accessibility Guidelines and Techniques, and as a complement to the W3C Specification Guidelines.  In addition the XAG will itself be edited to conform to the W3C Specification Guidelines.

4.3 Accessibility of Dynamic Web Content

The working group is working on strategies for making dynamic web content more accessible. Strategies are outlined in the
Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) document. This work will produce two to three recommendation - track deliverables and a roadmap note providing an overview of the end-to-end strategies for making content more accessible.

The roadmap note will explain how we plan to:
- solve existing accessibility problems with scripted behavior in Web content
- demonstrate the complementary use of markup and metadata to solidify the knowledge base for transforming the presentation of web content and applications
- assure that assistive technologies have adequate programmatic access (through the W3C DOM) to properties and changes that happen as a document interacts with the user (between network communication events)
- assist the Hypertext CG in coordinating concurrent developments.

This group will deliver an RDF taxonomy of roles, a specification of Roles for Accessible Rich Internet Applications (WAI-ARIA Roles). These roles describe custom GUI widgets, such as combo box and grid, and basic document structure which may be used to support platform accessibility APIs. Roles encapsulate semantic information which may be used to help: user agents support assistive technologies; authoring tools enforce accessibility, and assistive technologies discover new custom objects and how to interoperate with them. RDF types defined by this taxonomy would be used as values of the @role attribute proposed in XHTML 2.0. This deliverable is expected to contain material suitable for, and to gain W3C consensus support to become, a W3C Recommendation.

Another deliverable will be a States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) specification. This specification shall address the usable access of dynamic web content by addressing keyboard accessibility problems in today's XHTML markup and promoting interoperable access to accessible state and property data needed to support access to scripted web content. States and Adaptable Properties are mapped to accessibility frameworks (such as a screen reader) that use this information to provide alternative access solutions. Similarly state and author properties can be used to dynamically change the rendering of content using different style sheet properties. The result is to provide an interoperable way for associating behaviors with document-level markup. Additionally, this specification includes markup to fix keyboard focus problems with today's XHTML 1.X markup.

The States and adaptable properties specification will be accompanied by an XHTML 1.1 compatible module and profile which allow for the changes to keyboard navigation, role attribute incorporation, and the additional States and adaptable properties. This deliverable is expected to contain material suitable for, and to gain W3C consensus support to become, a W3C Recommendation.

These specifications will be matured to Recommendation status as a version 1.0.  The 1.0 version will contain enough roles and supporting syntax to enable effective binding of user-interactive widgets modeled in Access APIs today, even if these widgets are created by adding scripted behavior to generic elements such as <div> in XHTML.  The Working Group will continue to analyze requirements for features not addressed in the 1.0 version.  This should address some of:

A possible third deliverable would detail how to enable a subset of this functionality in HTML 4.01 documents, to enable at least the indication of navigation-critical page parts through mechanisms available in HTML 4.01 such as the 'link' element.

4.4 Working Group Notes

At any time the PFWG may encounter a recurring or ill-understood pattern in the origins of disability barriers or in the successful delivery of disability access. When this happens the group will create a Working Draft discussing the issue and if a clear contribution to Web engineering and accessibility emerges, publish the stable form of the point paper as a Working Group Note.

The Working Draft Inaccessibility of Visually-Oriented Anti-Robot Tests exemplifies this type of output.

Additional topics that may reach Working Draft or Working Group Note status during the duration of this Charter include:

Language Assistance
A profile of techniques for clarifying language usage in Web documents and supporting comprehension assistance for those reading in a second language or with reading-affecting disabilities. Some early thoughts in this area have been collected in a working site Web page on the topic.
Hotkeys and Accessibility
HTML introduced hotkeys in the form of the 'accesskey' attribute. For a number of reasons it was not fully successful. This note could review accessibility considerations for the re-engineering of this feature, which is under way in the design of XHTML 2.0.

5. Milestones

The following publication and decision events are anticipated.  The "quarters" below refer to "calendar quarters" (1st Quarter 2007 = January, February, March 2007, etc.).

3rd Quarter, 2006
WAI-ARIA Roadmap Note, First Public Working Draft
First Public Working Draft of WAI-ARIA Roles
First Public Working Draft of WAI-ARIA States and Properties
4th Quarter, 2006
Second Public Working Draft of WAI-ARIA Roles
Second Public Working Draft of WAI-ARIA States and Properties
1st Quarter, 2007
Publish last call working draft of WAI-ARIA Roles v1.0
Publish last call working draft of WAI-ARIA States and Properties v1.0
Publish WAI-ARIA Roadmap as a Working Group Note
2nd Quarter, 2007
Publish test suite for role taxonomies
Publish test suite for states and properties
Publish WAI-ARIA Roles v1.0 as candidate recommendation for implementation guidance
Publish WAI-ARIA States and Properties v1.0 as candidate recommendation for implementation guidance
3rd Quarter, 2007
Review end-state expectations for XAG
Publish implementation report for WAI-ARIA Roles
Publish implementation report for WAI-ARIA States and Properties
Publish WAI-ARIA Roles specification v1.0 as proposed recommendation
Publish WAI-ARIA States and Properties v1.0 as proposed recommendation
4nd Quarter, 2007
Publish WAI-ARIA Roles v1.0 as a W3C Recommendation
Publish WAI-ARIA States and Properties v1.0 as a W3C Recommendation
Update WAI-ARIA Roadmap Note to guide work past version 1.0
Publish note on dynamic web content accessibility strategies

6. Dependencies

W3C Dependencies

Since the mission of PFWG is to detect otherwise unrecognized interactions between technical features of W3C technologies and usability by people with disabilities, it is not possible to enumerate all dependencies in advance.

The accessibility and usability of the Web depends most directly on the protocols and formats that interact most directly with the user. These include formats such as HTML, SVG and SSML, and protocols and algorithms used in presentation adaptation such as content negotiation in HTTP or the cascading algorithm in CSS. These technologies are mostly developed by groups represented in the Hypertext Coordination Group. The PFWG also participates in this group, to maintain awareness of workflow, issues, and to share cross-technology perspectives arising from the broad review of W3C technologies.

The PFWG is also dependent on its fellow groups in the WAI Technical Activity for knowledge of the actual dependencies of functional, usable, and authorable Web experiences on technology factors. This dependency is managed through the regular meetings of the WAI Coordination Group.

The 'states and properties specification' is expected to conform to some version of XHTML Modularization.

External Dependencies

Formal relationships outside the W3C are managed by the WAI International Program Office. If an outside group will be best connected with the work of PFWG though a formal relationship, the relationship will be referred to the International Program Office.

On the other hand, PFWG seeks to maintain liaisons with important technical initiatives outside the W3C which:

This is a major source of knowledge as to the true use cases and requirements that should guide technology development. The DAISY/NISO Standard Digital Talking Book, ANSI/NISO Z39.86-2002 and the newly-announced Accessibility activity in the Free Standards Group are examples of this outreach.

7. Confidentiality

To enable a close working relationship with W3C Working Groups developing specifications on Member-confidential terms, the PFWG is a Member-confidential group as defined by Section 4.1 of the W3C Process Document. The Working Group maintains a public mailing list at wai-xtech@w3.org.  When to use the public list vs. the Member-confidential list is discussed below under Communication.

8. Meetings

The PFWG works primarily by a combination of email and telephone conferences. However face-to-face meetings will be held two to three times a year.

Telephone conferences

PFWG meets weekly by teleconference.

Face-to-face meetings

The PFWG will hold face-to-face meetings

9. Communication

Communication within the Working Group

RSVP notices of meetings and minutes are carried by the archived Member-only mailing list with email address w3c-wai-pf@w3.org.  Discussions that are relevant to the PFWG scope and do not depend on W3C Member Confidential sources should be addressed to the publicly archived mailing list with email address wai-xtech@w3.org.  From time to time the group may create and use additional mailing lists in support of Task Forces they sponsor or participate in, as was done, for example, with the list with email address w3c-wai-pf-braille@w3.org.

The group will maintain a list of open issues, and track their progress toward closure. These will be reflected on the Member Confidential PFWG home page and as appropriate as well on the Public Working Group page at <http://www.w3.org/WAI/PF/>.

Communication within the WAI Domain

PFWG will not normally take a Group position on issues within the chartered areas of other groups within the WAI Domain. PFWG will not normally represent itself as authoritative in interpreting W3C specifications to other WAI Groups but will assist the WAI Groups in obtaining clarification from the W3C Groups that maintain or that originally developed a specification. PFWG will take up and seek Group consensus on issues referred to PFWG for discussion by the WAI CG.

Correspondence of a process planning nature (such as coordinating when issues of joint interest will be on the agenda in what group) flows from Chair to Chair with copies to the affected Team Contacts and if more than two groups are interested the WAI CG.

Communication outside the WAI Domain but within W3C

Communication on behalf of the group to other W3C Groups shall:

The PFWG maintains a professional and cordial relationship with other W3C Working Groups so that these other groups take the initiative to bring questions to the attention of the PFWG.

Member visibility into Group activity

PFWG shall maintain a Member Confidential PFWG home page which presents a central point of reference for Advisory Committee Representatives and other Member representatives to find Group information including Participants in Good Standing and Patent Disclosures.

Communication outside the W3C

Public visibility into Group activity

The primary channel for PFWG communication will be through the Notes discussed above in 4 Deliverables above. The development and release of these Notes shall follow the policies in the W3C Process Document effective at the time the work is performed and the procedures established by the W3C Communications Team.

In addition the PFWG shall maintain a Public Working Group page at <http://www.w3.org/WAI/PF/> which presents a central point of reference for members of the public to find Group information including the Charter, published Notes, etc.

No Formal Representation

PFWG shall not otherwise formally represent W3C or WAI outside the W3C, unless delegated this responsibility from the WAI Domain.  In the latter case communication will follow whatever protocol or talking points have been established.

10. Voting

Decisions

The primary means of decision-making in the PFWG is consensus. This charter is written in accordance with Section 3.4, Votes of the 5 February 2004 W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Escalation

Participants may appeal Working Group decisions. Decision authority rests with the Director, however appeals should be made first to the WAI Coordination Group (through the CG chair) and then to the W3C team (first the Domain leader and then the Director).

11. Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

12. Participation

W3C Member and Invited Expert participation

To be a Participant of the PFWG, an individual must meet all the requirements set out in the Working Group and Interest Group Participation section of the Process Document. In particular, PFWG Participants to remain in Good Standing are expected to:

Information about how to participate in the PFWG is available in a separate page.

Level of Involvement of Team

Michael Cooper (cooper -at- w3 -dot- org) Team Contact spends 40% of their time on PFWG.

The PFWG Chair is Alfred S. Gilman (Alfred.S.Gilman -at- IEEE -dot- org).


Last updated: $Date: 2009/04/16 12:10:49 $