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.

Process to submit HTML spec comments

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

The HTML Accessibility Task Force expects to submit a number of accessibility issues to the HTML WG, some of which may also be formal comments from the PFWG. The HTML Working Group Decision Policy states how issues should be submitted. This process extends the HTML WG process to allow tracking of accessibility-specific issues.

Note that for things more complicated than simple bugs, the best solution may be to propose and publish an extension specification.

  1. Enter an issue in Bugzilla following the guidance in the HTML Decision Policy. In particular, be sure the issue is well described and includes concrete suggestions for improvement.
  2. Add the email address "public-html-a11y@w3.org" to the cc for the issue. The cc field is shortly before the description field and ensures that activity on the issue will be sent to that email list.
  3. Add the keyword "a11y" to the issue. The keywords list is towards the bottom of the issue entry screen. Keywords are space delimited and must match (case-sensitive) keywords known to the system. This tags the issue as an accessibility issue, allowing us to track it.
  4. If the issue is formal feedback from the PFWG, add the "PFWG" keyword in the same manner. Please do this only if you have formal authorization from the PFWG for the issue. We can always add this keyword later, so it is not crucial to declare it formal PFWG feedback immediately.

If you do not see the keywords field, please contact a Team Contact of the task force who can give you access.