From 06bc28a6ab0d1071abe2591aae835c785ac897ce Mon Sep 17 00:00:00 2001
From: Daniel
Date: Wed, 18 Feb 2026 19:36:13 +0100
Subject: [PATCH 1/7] First cleanup
---
index.html | 258 +++++++++++++++++++++++++++--------------------------
1 file changed, 131 insertions(+), 127 deletions(-)
diff --git a/index.html b/index.html
index c385660..cc87a15 100644
--- a/index.html
+++ b/index.html
@@ -6,23 +6,28 @@
@@ -162,10 +167,7 @@
This document is informative only. Resources are for information purposes only, no endorsement implied.
- It is published by the Web Platform Working Group.
-
- It is a draft document and its contents is subject to change without notice.
-
+ Using ARIA is a Discontinued Draft. There are no plans to continue work on this document. For further guidance on how to include accessibility semantics into web design patterns and widgets using ARIA, see the ARIA Authoring Practices Guide (APG).
Introduction
@@ -178,15 +180,15 @@ Introduction
related technologies.
This document provides advice for use of ARIA attributes in [[HTML]].
For general best-practice information about using ARIA, see the
- [[WAI-ARIA-PRACTICES-1.2]] document.
+ ARIA Authoring Practices Guide (APG).
The following is a longer list of resources that provide relevant information:
+ HTML5 Accessibility
+
Notes on ARIA Use in HTML
@@ -196,9 +198,9 @@ First Rule of ARIA Use
If you can use a native HTML element [[HTML]] or attribute 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.
Under what circumstances may this not be possible?
Second Rule of ARIA Use
Do not change native semantics, unless you really have to.
@@ -207,14 +209,14 @@ First Rule of ARIA Use
<h2 role=tab>heading tab</h2>
Do this:
<div role=tab><h2>heading tab</h2></div>
- If a non-interactive element is used as the basis for an interactive element, developers have to add the semantics using ARIA and the appropriate interaction behavior using scripting. In the case of a button, for example, it is much better and easier to Just use a (native HTML) button.
- It is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fallback. For example, using HTML list elements for the skeleton of an ARIA-enabled, scripted tree widget.
+ If a non-interactive element is used as the basis for an interactive element, developers have to add the semantics using ARIA and the appropriate interaction behavior using scripting. In the case of a button, for example, it is much better and easier to Just use a (native HTML) button.
+ It is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fallback. For example, using HTML list elements for the skeleton of an ARIA-enabled, scripted tree widget.
Third Rule of ARIA Use
All interactive ARIA controls must be usable with the keyboard.
If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.
All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable.
For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.
- Refer to the Design Patterns and Widgets and Developing a Keyboard Interface sections of [[WAI-ARIA-PRACTICES-1.2]]
+ Refer to the APG Patterns and Developing a Keyboard Interface sections of WAI-ARIA Authoring Practices Guide.
@@ -237,11 +239,11 @@ Fourth Rule of ARIA Use
<button tabindex="-1" aria-hidden="true">press me</button>
If an interactive element is hidden using display:none or visibility:hidden (either on the element itself, or any of the element's ancestors),
- it won't be focusable, and it will also be removed from the accessibility tree. This makes the
+ it won't be focusable, and it will also be removed from the accessibility tree. This makes the
addition of aria-hidden="true" or explicitly setting tabindex="-1" unnecessary.
Fifth Rule of ARIA Use
-All interactive elements must have an accessible name.
+All interactive elements must have an accessible name.
An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value.
For example, the input type=text in the code example below has a visible label 'user name' , but no accessible name:
@@ -254,7 +256,7 @@ Fourth Rule of ARIA Use
The control's MSAA accName property is empty:

- In comparison, the input type=text in the code example below has a visible label 'user name' and an accessible name. This example has an accessible name because the input element is a labelable element and the label element is used correctly to associate the label text with the input.
+ In comparison, the input type=text in the code example below has a visible label 'user name' and an accessible name. This example has an accessible name because the input element is a labelable element and the label element is used correctly to associate the label text with the input.
<!-- Note: use of for/id or wrapping label around text
and control methods will result in an accessible name -->
@@ -270,11 +272,11 @@ Fourth Rule of ARIA Use
The control's MSAA accName property has a value of "user name":

- Note: The example above is for ARIA widgets. For regular HTML inputs, follow the First Rule of ARIA, and use the label element with a for attribute to associate labels with input elements.
+ The example above is for ARIA widgets. For regular HTML inputs, follow the First Rule of ARIA, and use the label element with a for attribute to associate labels with input elements.
HTML label element and labelable elements
- The following is about using the label in HTML. If you are building ARIA widgets, refer to the ARIA Authoring Practices Document
-
The label element cannot be used to provide an accessible name for custom controls, unless the label is referencing a native HTML labelable element.
+ The following is about using the label in HTML. If you are building ARIA widgets, refer to the ARIA Authoring Practices Guide
+
The label element cannot be used to provide an accessible name for custom controls, unless the label is referencing a native HTML labelable element.
<!-- HTML input element with combox role -->
@@ -282,9 +284,9 @@ HTML label element and labelable elements
user name <input type="text" role="combobox">
</label>
- The control's MSAA accName property has a value of "user name":
+ The control's MSAA accName property has a value of "user name":

- A div element regardless of what role is assigned is not an HTML labelable element.
+ A div element regardless of what role is assigned is not an HTML labelable element.
<!-- HTML div element with combox role -->
@@ -292,28 +294,28 @@ HTML label element and labelable elements
user name <div role="combobox"></div>
</label>
- The control's MSAA accName property is empty:
+ The control's MSAA accName property is empty:

5th rule is a work in progress
What Does Adding a Role Do to the Native Semantics?
- Adding an ARIA role overrides the native role semantics in the accessibility tree which is reported via the accessibility API, and therefore ARIA indirectly affects what is reported to a screen reader or other assistive technology.
+ Adding an ARIA role overrides the native role semantics in the accessibility tree which is reported via the accessibility API, and therefore ARIA indirectly affects what is reported to a screen reader or other assistive technology.
For example, this code in the HTML tree:
<h1 role=button>text</h1>
Becomes this in the accessibility tree:

What Adding a Role Does Not Do
- Adding an ARIA role will not make an element look or act differently for people not using assistive technology. It does not change the behaviors, states and properties of the host element but only the native role semantics.
+ Adding an ARIA role will not make an element look or act differently for people not using assistive technology. It does not change the behaviors, states, and properties of the host element but only the native role semantics.
For example, this code in the HTML tree:
<button role=heading aria-level=1>text</button>
Becomes this in the accessibility tree:

- But it can still be pressed, it is still in the default tab order, still looks like a button and still triggers any associated actions when pressed. That's why it is an HTML5 conformance error to change a button into a heading.
- Note: Changing the role of an element does not add behaviors, properties or states to the role used. ARIA does not change the way it looks or acts in a browser. For instance, when links are used to behave like buttons, adding role=button alone is not sufficient. It will also be necessary to make act like a button, by including a key event handler that listens for the space key which native buttons do, because native buttons can be activated using the enter key or the spacebar.
+ But it can still be pressed, it is still in the default tab order, still looks like a button and still triggers any associated actions when pressed. That's why it is an HTML5 conformance error to change a button into a heading.
+ Note: Changing the role of an element does not add behaviors, properties or states to the role used. ARIA does not change the way it looks or acts in a browser. For instance, when links are used to behave like buttons, adding role=button alone is not sufficient. It will also be necessary to make act like a button, by including a key event handler that listens for the space key which native buttons do, because native buttons can be activated using the enter key or the spacebar.
Add ARIA Inline or via Script?
- If the ARIA role or aria-* attribute does not rely on scripting to provide interaction behavior, then it is safe to include the ARIA markup inline. For example, it is fine to add ARIA landmark roles or ARIA labeling and describing attributes inline.
- If the content and interaction is only supported in a scripting-enabled browsing context, i.e. Google docs (its applications require JavaScript enabled to work), it is also safe to include the ARIA markup inline as the application simply will not work (for anyone) without JavaScript enabled.
+ If the ARIA role or aria-* attribute does not rely on scripting to provide interaction behavior, then it is safe to include the ARIA markup inline. For example, it is fine to add ARIA landmark roles or ARIA labeling and describing attributes inline.
+ If the content and interaction is only supported in a scripting-enabled browsing context, i.e. Google docs (its applications require JavaScript enabled to work), it is also safe to include the ARIA markup inline as the application simply will not work (for anyone) without JavaScript enabled.
Otherwise insert, change and remove ARIA via scripting. For instance, a collapsed section of a tree widget might look like this:
<li role=treeitem aria-expanded=false ...
When the user opens the section, it is changed to this using JavaScript :
@@ -321,12 +323,12 @@ What Adding a Role Does Not Do
ARIA Validation
- The easiest method is to use the HTML5 DOCTYPE with ARIA markup and validate using the W3C Nu Markup Checker. ARIA works equally well with any other DOCTYPE, but validation tools will produce errors when they encounter ARIA markup as the associated DTDs have not been updated to recognize ARIA markup and it is unlikely they ever will be.
+ The easiest method is to use the HTML5 DOCTYPE with ARIA markup and validate using the W3C Nu Markup Checker. ARIA works equally well with any other DOCTYPE, but validation tools will produce errors when they encounter ARIA markup as the associated DTDs have not been updated to recognize ARIA markup and it is unlikely they ever will be.
These validation errors in versions of HTML prior to HTML5 are in no way indicative of ARIA creating any real world accessibility problems nor do they mean there will be a negative user experience. They are merely the result of old automated validation tests that do not accommodate ARIA accessibility annotations.
- Note: The W3C Nu Markup Checker support for ARIA checking is a work in progress, so cannot be wholly relied upon (though it is pretty darn good!) to provide the correct results. It is recommended that if you encounter a result that conflicts with the ARIA conformance requirements in the ARIA specification or the HTML specification, please raise an issue.
+ The W3C Nu Markup Checker support for ARIA checking is a work in progress, so cannot be wholly relied upon (though it is pretty darn good!) to provide the correct results. It is recommended that if you encounter a result that conflicts with the ARIA conformance requirements in the ARIA specification or the HTML specification, please raise an issue.
Use of Role=presentation or Role=none
- role=presentation, or its synonym role=none, removes the semantics from the element it is on.
+ role=presentation, or its synonym role=none, removes the semantics from the element it is on.
For example, this code in the HTML tree:
<h1 role="presentation">text</h1>
Becomes this in the accessibility tree:
@@ -364,7 +366,7 @@ Use of Role=presentation or Role=none
</tr>
</table>
Becomes this in the accessibility tree:
- 
+ 
By adding role=presentation/none to the outer table element, this code in the HTML tree:
<table role="presentation">
@@ -397,7 +399,7 @@ Examples of role=presentation/none Use
<table role="none">
<tbody><tr role="row">
<td role="gridcell">Fido</td>
- <td role="gridcell">Whiskers</td>
+ <td role="gridcell">Whis kers</td>
<td role="gridcell">Clarabella</td>
</tr>
<tr role="row">
@@ -411,13 +413,13 @@ Examples of role=presentation/none Use
Practical Support: aria-label, aria-labelledby and aria-describedby
Well supported elements
- aria-label, aria-labelledby and aria-describedby are robustly supported for interactive content elements such as links and form controls including the many input types. They also work well on div and span elements with interactive roles such as role=link, button. By design, aria-label or aria-labelledby replace any other label text inside the element.
+ aria-label, aria-labelledby and aria-describedby are robustly supported for interactive content elements such as links and form controls including the many input types. They also work well on div and span elements with interactive roles such as role=link, button. By design, aria-label or aria-labelledby replace any other label text inside the element.
- All three are OK on
nav and main elements.
- They are OK on
div elements IF they have role=navigation, search, main, img.
- They are OK on a
table element (except ignored by VoiceOver on iOS).
Other static elements with aria-label, aria-labelledby and aria-describedby
-NOTE: There are no appreciable differences in these tests across popular browsers, platforms or in iframes.
+There are no appreciable differences in these tests across popular browsers, platforms or in iframes.
@@ -445,16 +447,16 @@ Other static elements with aria-label, aria-labe
aria-describedby |
Well supported on static content |
h1, h2, h3, h4, h5, h6 are OK as are elements with role=heading.
-Ignored on static content not listed above unless given an interactive role and tabindex=0, and then only if the users tabs to it (not arrows to it). |
+Ignored on static content not listed above unless given an interactive role and tabindex=0, and then only if the user tabs to it (not arrows to it).
VO on MacOS is different from iOS
VO on MacOS is OK on most static content.
VO on iOS only reads it if on landmark roles. |
Well supported on static content |
-aria-label and aria-labelledby have similar behaviour in screen readers and the Accessibility API, but aria-label should be reserved for when there is no visible text on the page to reference or when keeping track of id values would be too difficult. Test sources
+aria-label and aria-labelledby have similar behaviour in screen readers and the Accessibility API, but aria-label should be reserved for when there is no visible text on the page to reference or when keeping track of id values would be too difficult. Test sources
Internet Explorer notes on aria-labelledby, aria-label, and aria-describedby
- In Internet Explorer, if you use aria-labelledby with multiple id references or aria-describedby with single or multiple id references, the referenced elements must be what Microsoft terms as accessible HTML elements.
-The following example of aria-labelledby with multiple references uses a span with a tabindex=-1 added. Refer to Making Non accessible Elements Accessible.
+In Internet Explorer, if you use aria-labelledby with multiple id references or aria-describedby with single or multiple id references, the referenced elements must be what Microsoft terms as accessible HTML elements.
+The following example of aria-labelledby with multiple references uses a span with a tabindex=-1 added. Refer to .
<label
id="l1"
for="f3">label text</label>
@@ -469,7 +471,7 @@ Internet Explorer notes on aria-labelledby, aria-label, and aria-describedby
tabindex="-1"
id="l2"
>more label text</span>
- Elements also become accessible HTML elements in Internet Explorer when the element has an ARIA role. For example:
+ Elements also become accessible HTML elements in Internet Explorer when the element has an ARIA role. For example:
<div aria-describedby="test">text</div>
<div id="test"
@@ -477,10 +479,10 @@ Internet Explorer notes on aria-labelledby, aria-label, and aria-describedby
>tooltip text</div>
Hiding Content Has No Effect on Accessible Name or Description Calculation
- By design, hiding the content (using CSS display:none or visibility:hidden or the HTML hidden attribute) of the element(s) referenced by aria-labelledby and aria-describedby does not stop the content from being used to provide the name/description.
+
By design, hiding the content (using CSS display:none or visibility:hidden or the HTML hidden attribute) of the element(s) referenced by aria-labelledby and aria-describedby does not stop the content from being used to provide the name/description.
- By default, assistive technologies do not relay hidden information, but an author can explicitly override that and include hidden text as part of the accessible name or accessible description by using aria-labelledby or aria-describedby.
-
+ By default, assistive technologies do not relay hidden information, but an author can explicitly override that and include hidden text as part of the accessible name or accessible description by using aria-labelledby or aria-describedby.
+
In the following example the description will be available to assistive technology users in both states:
Non-error state: message visually hidden
@@ -509,13 +511,13 @@ Methods to Provide Context Sensitive Name/Description Text
The Effect of Accessible Name on Background Images
Try to avoid presenting informational images in CSS backgrounds. If your image contains important information for the end user, then it should be provided in an HTML <img> tag with proper alt text. The CSS Spec says this:
- For accessibility reasons, authors should not use background images as the sole method of conveying important information. See WCAG failure #F3 [WCAG20] . Images are not accessible in non-graphical presentations, and background images specifically might be turned off in high-contrast display modes. Source .
+ For accessibility reasons, authors should not use background images as the sole method of conveying important information. See WCAG failure #F3 [WCAG20] . Images are not accessible in non-graphical presentations, and background images specifically might be turned off in high-contrast display modes. Source .
What If You Can't Avoid Using CSS Images or If You Want Alternate Text for "Non-important" Ambient Photos, Etc.?
- The CSS spec makes its discouragement of CSS informational background images a "SHOULD" not a "MUST" because there are times when visual design or existing code makes it difficult to change it to an HTML image without redesigning the front-end. Other times the author may want to provide alternate text for an ambient image that is not "important" to the understanding of the content but as a courtesy to screen reader users who prefer knowing what is in the image. Here is a detailed article on ambient images vs pure decoration vs informational images.
+ The CSS spec makes its discouragement of CSS informational background images a "SHOULD" not a "MUST" because there are times when visual design or existing code makes it difficult to change it to an HTML image without redesigning the front-end. Other times the author may want to provide alternate text for an ambient image that is not "important" to the understanding of the content but as a courtesy to screen reader users who prefer knowing what is in the image. Here is a detailed article on ambient images vs pure decoration vs informational images.
When Providing Alternate Text for the CSS Image, There Are Number of Considerations
- If the <div> tag has any content inside it, then a role="img" and aria-label could obscure the inside content because of the accessible name calculation, or the assistive technology might just ignore the aria-label.
+
If the <div> tag has any content inside it, then a role="img" and aria-label could obscure the inside content because of the accessible name calculation, or the assistive technology might just ignore the aria-label.
So do not put the CSS background image inside a <div> that contains any content. It's best to use an empty <span> and an aria-label with role="img"
Do this:
@@ -581,7 +583,7 @@ So Where Do I Put role=application in the Rare Cases
Only put it on the body element if your page consists solely of a widget or set of widgets that all need the focus mode to be turned on. If you have a majority of these widgets, but also have something you want the user to browse, use role=document on the outermost element of this document-ish part of the page. It is the counterpart to role=application and will allow you to tell the screen reader to use browse mode for this part. Also make this element tabbable by setting a tabindex=0 on it so the user has a chance to reach it.
As a rule of thumb: If your page consists of over 90 or even 95 percent of widgets, role=application may be appropriate. Even then, find someone knowledgeable who can actually test two versions of this: One with and one without role=application set to see which model works best.
NEVER put role=application on a widely containing element such as body if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode. This will cause huge headaches for any assistive technology user trying to use your site/application.
- For further information on the use of role=application refer to If you use the WAI-ARIA role "application", please do so wisely!
+
For further information on the use of role=application refer to MDN's ARIA: Application role
Custom Control Accessible Development Checklist:
Check your custom control against the following design considerations. If the answer to any of them is 'No' then consider fixing before release or at least documenting the issues to inform other developers that your custom control will not be usable by some people due to limited accessibility support.
@@ -595,13 +597,13 @@ Custom Control Accessible Development Checklist
| focusable |
-Can you get to the control via the keyboard? Refer to Providing Keyboard Focus
+ | Can you get to the control via the keyboard? Refer to Discernable and Predictable Keyboard Focus
|
|
| keyboard operable |
- Can you use the control with the keyboard? Refer to Keyboard Navigation |
+ Can you use the control with the keyboard? Refer to Keyboard Navigation Within Components and Keyboard Navigation Inside Components |
|
@@ -611,51 +613,53 @@ Custom Control Accessible Development Checklist
| expected operation |
- Can you operate the control using the standard keys (Refer to ARIA Widget Design Patterns) and/or touch gestures for the control type? |
+ Can you operate the control using the standard keys (Refer to ARIA Widget Design Patterns) and/or touch gestures for the control type? |
|
| clear indication of focus |
-Can you easily see it when the control has focus? Refer to Visible Focus (WCAG2) |
+Can you easily see it when the control has focus? Refer to Visible Focus (WCAG 2) |
|
| label |
-The control has a text label that is exposed as an accessible name in accessibility APIs |
+The control has a text label that is exposed as an accessible name in accessibility APIs |
|
| role |
-The control has an appropriate role exposed in accessibility APIs |
+The control has an appropriate role exposed in accessibility APIs |
|
-| states and properties |
-The control has any UI states and properties that it has exposed in accessibility APIs |
+states, and properties |
+The control has any UI states, and properties that it has exposed in accessibility APIs |
|
| color contrast |
- The control label/description/icon and its states are perceivable/usable for low vision users (Use a color contrast checker.) |
+ The control label/description/icon and its states are perceivable/usable for low vision users (Use a color contrast checker.) |
|
| high contrast mode |
-The control is perceivable/usable when High Contrast Mode is enabled (e.g. Windows HC mode) |
+The control is perceivable/usable when High Contrast Mode is enabled (e.g. Windows HC mode) |
|
ARIA Adds Nothing to Default Semantics of Most HTML Elements
-In some cases the semantics of an HTML element can be expressed by an ARIA role, state or property. This is known as the element's 'Default Implicit ARIA semantics'
-None of the elements defined in HTML4 need ARIA roles added to expose their default semantics. Adding an ARIA role is extra work for no gain and could lead to pain for you or somebody else. The new features defined in HTML5 , where implemented, now have their default semantics exposed by most browsers.
+In some cases the semantics of an HTML element can be expressed by an ARIA role, state or property. This is known as the element's 'ARIA Implicit semantics'
+None of the elements defined in HTML4 need ARIA roles added to expose their default semantics. Adding an ARIA role is extra work for no gain and could lead to pain for you or somebody else. The new features defined in HTML5 , where implemented, now have their default semantics exposed by most browsers.
-The HTML Specification includes this note:
-
In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.
+The Document Conformance Requirements for Use of ARIA Attributes in HTML includes this note:
+While setting an ARIA role and/or aria-* attribute that matches the implicit ARIA semantics
+ is NOT RECOMMENDED, in some situations explicitly setting these attributes can be helpful – for instance,
+ for user agents that do not expose implicit ARIA semantics for certain elements.
Some Examples of Redundant ARIA
-Adding default implicit roles to interactive elements listed in the HTML5 Recommendation is a waste of time:
+
Adding default implicit roles to interactive content elements listed in the HTML5 Standard is a waste of time:
<button role="button">press me</button>
Adding ARIA state or property attributes in addition to their native HTML counterparts is a waste of time:
@@ -669,86 +673,86 @@
Some Examples of Redundant ARIA
Aria Roles and Properties Not Available as Features in HTML
-Below are listed the ARIA roles and properties not considered to be available natively in HTML. It is clear that many roles and properties provided by ARIA, which can be used to convey information to users, are not available in HTML.
+Below are listed the ARIA roles and properties not considered to be available natively in HTML. It is clear that many roles and properties provided by ARIA, which can be used to convey information to users, are not available in HTML.
-
+