Outdated Content!

The Protocols and Formats Working Group is no longer chartered to operate. Its work will continue in two new Working Groups:

  • https://www.w3.org/WAI/APA/ Accessible Platform Architectures, to review specifications, develop technical support materials, collaborate with other Working Groups on technology accessibility, and coordinate harmonized accessibility strategies within W3C; and
  • https://www.w3.org/WAI/ARIA/ Accessible Rich Internet Applications, to continue development of the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies and other technical specifications when needed to bridge known gaps.

Resources from the PFWG remain available to support long-term institutional memory, but this information is of historical value only.

This Wiki page was edited by participants of the Protocols and Formats Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Specification Review Task Force

From Protocols and Formats Working Group Wiki
Jump to: navigation, search


Reviews of accessibility considerations in W3C specifications.

Note: this is a public wiki instance, but the PFWG must often do specification reviews in Member space. Be careful about what content is posted here.

HTML 5 is a W3C specification requiring sustained attention from the PFWG. Therefore, work on HTML 5 is performed by the HTML Task Force, not this specification review task force.

Potential Projects

  • Spec review matrix - groups, specs we care about, people with relevant expertise
  • Monitor Community Groups for relevance to accessibility
  • Come up with ways to identify specs that need review
  • Organizer reviewers by knowledge area
  • Track comments we send on specs and their disposition; in particular, be able to verify that our comments were addressed before the spec undergoes the next transition
  • Ensure that reviews are conducted and comments sent in a timely manner
  • Collect general accessibility principles we're discovering or using in our reviews
  • Create review principles, e.g.,
    • Focus on First Public Working Drafts and Last Call Working Drafts
    • PFWG should only send accessibility comments
  • Create use case personae to guide questions that should be asked
  • Support accessibility of W3C specifications
  • Create a feature wishlist for various technologies, e.g., HTML, CSS, etc. that we can submit for consideration as requirements when windows open
  • Proxys - have good reasons to exist but have accessibility implications that need investigation, as a general topic rather than in the context of specific things that have come up. Some specs that have triggered this:
  • AT support for Unicode
  • Web Technology Accessibility Guidelines
  • Use Cases for Extended Descriptions

Specific Specs