This Wiki page is edited by participants of the WCAG 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. Much of the content of this wiki is being migrated to the WCAG wiki at W3C.

From WCAGWiki

Proposal for including externally developed sufficient and advisory techniques in W3C "How to Meet" documents

The following is a proposed approach that would allow vendors of non-W3C technology to document and test techniques for using their technologies in a way that would allow the techniques to be listed in W3C WCAG 2.0 related documents.

Specifically, the objective would be to allow companies to develop documented sufficient, and advisory techniques that could be included in the "How to Meet" document alongside the W3C WCAG 2.0 working group techniques.

This approach could also be used with techniques proposed by any third party, for any technology.

Proposal

In order for externally developed techniques to be included, the following conditions would need to be met:

1. The techniques would have to be written up in a complete fashion, including testing procedure.
2. The techniques would have to have undergone public review. This involves
   • widely advertised public comment period
   • comments resolved in a manner equivalent to processing of comments on W3C techniques.
   • public documentation of both comments and responses
3. For each technique, a test page would need to be generated that was suitable for accessibility support testing.
4. Accessibility support testing by multiple independent and credible testers.
   • For techniques to be listed as sufficient, there must be accessibility support at a similar level as required for inclusion of W3C technologies as sufficient techniques. Gaps in accessibility support must be noted in the user agent notes field.
5. All of the technique-related documents, including the public review, comments, and responses, must be stored in a public place with persistent URLs.
   • (The W3C might consider creating a separate non-W3C domain, which could be used to provide stable URLs for such materials. Perhaps www.stableurl.org.)

Such a set of conditions would provide a parallel and equivalent process to that used for W3C technologies. Techniques for non-W3C technologies that follow this procedure may be listed in the "How to Meet" documents alongside the W3C techniques. To distinguish them, they may have a non-pejorative tag such as "(externally submitted technique)".

Discussion 03 March 2009 with Judy:

• State in so many words that we will integrate the techniques with our own
• Clearly state how we will differentiate them (e.g., using "(externally submitted technique)").
• The "may have a non-pejorative" is problematic, that shouldn't be "may".
• "Non-pejorative" needs to be balanced, e.g., "clear but non-pejorative".

Alternate Proposal based on 12 March 2009 Teleconference

The following procedure will apply to all techniques, whether originating internally or externally.

1. The WG will review proposed techniques for any technology for which there is evidence of accessibility support.
2. The processing of a technique may be delayed in the Working Group (perhaps indefinitely) by lack of sufficient expertise on the technology
   • It may be desirable to recruit additional WG members with the desired technology expertise.
   • The WG may request assistance from technology experts outside the WG, who would need to adhere to the W3C patent policy.
3. The techniques would have to be written up in a complete fashion.
4. New sufficient techniques must include a test page suitable for public review try out.
5. New techniques that are accepted by the WG will be added to drafts of the "How To Meet", Techniques, and Understanding documents and sent for public review. New and revised techniques will be explicitly called out in the draft documents. All public comments must be addressed before adding the techniques to the published documents.
6. With the inclusion of additional base technologies, it is desirable to be able to uncheck HTML in the "How to Meet" web page.
7. Since all techniques will follow the standard process, there will be no distinction between W3C and non-W3C technologies.

Proposed addition after the teleconference:

1. In order to include a technique, it must be possible to create a web page that contains the technique in some way and conforms at Level A.

BBC: The text above was modified 9 April, but is tabled for future discussion
LGR: I also added the (undiscussed) clause about patent policy.

Alternate form

1. In order to include a technique for a technology, it must be possible to create a web page that conforms at Level A that contains an implementation of that technique.