This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
A11ytf keyword criteria
From HTML accessibility task force Wiki
"A11yTF" Keyword Criteria (Draft)
According to the Bugzilla keyword descriptions the"a11ytf" keyword means "Issues referred to the HTML Accessibility Task Force for work".
However, the March 18, 2010 teleconference minutes indicate that a non trivial cost exists to tagging bugs "a11ytf" and that the task force needs to agree on criteria for our decisions to take on bugs.
The following develops the ideas begun in the email "Criteria for 'a11yTF' keyword application".
For a bug to have the "a11ytf" keyword applied, it:
- Must be a bug that falls under task force scope of work, AND
- Must have a minimum of one task force member volunteering and agreeing to actively work on/see through to closure, AND
- A minimum of one of the following must be applicable.
- The bug's purpose is to expedite, clarify, or aid an existing HTML Tracker Issue Change Proposal , OR
- The bug has a dependency or blocker relationship with an existing bug that the task force has already accepted  , OR
- The bug reports a problem where HTML 5 conflicts with WCAG, UAAG, or ATAG, OR
- The bug impacts one of the task force's work topics, OR
- The bug's purpose is to introduce features that will facilitate or enhance accessibility. , OR
- The bug's purpose is to restore an accessibility feature back into HTML for which no superior mechanism or replacement exists, OR
- The bug is one that the task force has made a resolution committing to work on it .
- "a11ytf" keyword
- Issues referred to the HTML Accessibility Task Force for work. Source: Bugzilla Keyword Descriptions
- Actively work on
- May include but is not limited to drafting, filing, commenting, writing surveys, escalating to tracker issues, writing change proposals.
- Bug closure
- The bug is considered dead, the resolution is correct. Source: Bugzilla - A Bug's Life Cycle
-  Example bugs submitted at requested of a HTML WG Chair to clarify and expedite Change Proposal for ISSUE 31
- Example Dependency Bug Trees:
-  Example bug to introduce features that will enhance accessibility. (ARIA)
-  Example resolution committing to work on figure, aside, details, meter, progress, and hidden to make them better.
Starting Drafts for Boilerplate Messages
After a decision is made, to avoid confusion going forward, we should probably have language and a link to the decision added to bugs for clear documentation of task force intentions.
The HTML Accessibility Task Force intends to track this bug, per the decision at: http://decisionlink.html
Per the decision at http://decisionlink.html, the HTML Accessibility Task Force does not plan to formally work on this bug at this time. This does not mean the Task Force has no interest in it, but does not have immediate plans to work on it. The Task Force may review the issue in the future.