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.
ARIAExtensions
Proposed Rules for Extending ARIA 1.x
Note: This model is based upon the HTML Working Group's model for Extension specifications [1].
The Model for Extending ARIA 1.x
- Anyone can start working on an extension.
- At some point an extension should be exposed to the broader (ARIA) community for socialization / comment / approval.
- If the community ultimately finds an extension interesting, it can be formalized and merged into the core spec, left as an independent specification, or some combination of the two.
- The earlier a group starts coordinating with the PFWG in their development process, the more likely it is that there will be a smooth transition into the W3C and its Recommendation Track. However, there is no guarantee this will happen.
- As with all W3C work, User agents are encouraged to implement support for extension modules which have become W3C Recommendations.
- These extension modules DO NOT automatically become part of the conformance requirements for the ARIA Core specification.
NOTE: There should be a mechanism to programatically detect which extension modules are supported by a user agent (e.g., if w3c.aria.isSupported("module_name") == true ... ).
Technical Requirements for Extending Roles, States, and/or Properties
- Acceptable extensions MUST conform to and MUST extend the existing taxonomy.
- Any new roles MUST be a descendant of a role or roles in the ARIA Core specification. To promote faster adoption, new roles SHOULD be a descendant of a role or roles in the current ARIA Core W3C Recommendation (as opposed to a future version of that Recommendation).
- Newly introduced roles can reference existing states or properties from the ARIA Core or other extensions that are Recommendations.
- Any new states or properties MUST be very carefully coordinated with the ARIA Core development group as well as user agent and AT implementors.
- Roles/State/Properties that are named in a scoped manner (myvocab-myrole, aria-myvocab-mystate) are more easily adopted than ones that are in an unscoped space (myrole).
- Extension specification developers are responsible for providing the normative rec-track Specification, rec-track Accessibility API mapping specification, use cases, and conformance tests.
The Role attribute, its values, and WAI-ARIA states and properties are first and foremost designed to support accessibility and, in particular, interoperability with assistive technologies. This is why the working group controls the role values. However, it has never been the intention to limit their use to accessibility as this technology has always been intended to be a cross-cutting technology. This process is put in place to ensure that the use of this information in web content does not break accessibility, while empowering others to use WAI-ARIA to enable semantic driven user experiences that benefit all users.