ARIA page template
Remove before publishing
Title and slug
An ARIA role page should have a title and slug of ARIA:NameOfTheRole. For example, the button role has a title and slug of ARIA/NameOfTheRole_role and the aria-labelledby attribute has a title of ARIA-labelledby Attribute.
Top macros
By default, there are four macro calls at the top of the template. You should update or delete them according to the following advice:
- {{draft()}}—generates a Draft banner that indicates that the page is incomplete, and should only be removed when the first draft of the page is completely finished. After it is ready to be published, you can remove this.
- {{deprecated_header}}—generates a Deprecated banner that indicates the technology is deprecated. If it isn't, then you can remove the macro call.
-
{{ariaref}}—generates a suitable ARIA sidebar, depending on what tags are included on the page.
Tags
In ARIA role or attribute subpages, you need to include the following tags (see the Tags section at the bottom of the editor UI): ARIA, Reference, ARIA Role or ARIA Attribute, the name of the Role or Attribute (e.g. ARIA button or aria-labelledby), ARIA widget, Experimental (if the role or attribute is experimental), and Deprecated (if it is deprecated).
Specifications
Update the fragment link within the following specifications to the correct section:
- ARIA: https://www.w3.org/TR/wai-aria-1.1/
- ARIA Authoring Practices: https://www.w3.org/TR/wai-aria-practices-1.1/
Additional resources:
- Accessibility Object Model: https://wicg.github.io/aom/spec/
- ARIA in HTML: https://w3c.github.io/html-aria/
Draft
This page is not complete.
The summary paragraph—start by naming the role or attribute and saying what it does. This should ideally be 1 or 2 short sentences. This content appears as a tool tip on links to this page, so craft it well.
<!-- Insert code block showing common use cases -->
(Optional) Include a short description of the preceding example.
Description
Include a complete description of the attribute or role.
Associated ARIA roles, states, and properties
- Name of associated roles
- Explanation of requirement, link to features pages.
- Name of associated attribute(s)
- Explanation of requirement, link to attribute's pages, along with link to JS required to change the value, if appropriate.
Keyboard interactions
Required JavaScript features
- Required event handlers
- Explanation of each
- Changing attribute values
- explanation of each
Include a note about semantic alternatives to using this role or attribute. The first rule of ARIA use is that you can use a native feature with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so. Then post full details in best practices section below.
Examples
Fill in a simple example that shows a typical usage of the property, then perhaps some more complex examples. For more information, see our guide on how to add code examples.
my code blockAnd/or include a list of links to useful code samples that live elsewhere:
- x
- y
- z
Accessibility concerns
Optionally, warn of any potential accessibility concerns that exist with using this property, and how to work around them. Remove this section if there are none to list.
Best practices
Optionally, list any best practices that exist for this role. Remove the section if none exist.
Added benefits
- Associated role
- If that role is a required parent, child or sibling, and what it does.
Any additional benefits this feature has for non-typical screen reader users, like Google or mobile speech recognition.
Specifications
Precedence order
What are the related properties, and in what order will this attribute or property be read (which property will take precedence over this one, and which property will be overwritten.
Screen reader support
See also
- Include list of
- other links related to
- this role or attribute that might
- be useful