ARIA state or property: various editorial improvements#2012
ARIA state or property: various editorial improvements#2012WilcoFiers merged 13 commits intodevelopfrom
Conversation
Jym77
left a comment
Jym77
left a comment
There was a problem hiding this comment.
The whole aria-controls on combobox may be better taken in a separate PR, but I think this PR won't close #1849 until it's done.
And it may also require us to have the same exception on "Element with role attribute has required states and properties".
I did tried to give it a shot before seeing this PR 😅 : #2014, maybe things are salvageable from it.
| For value types `ID Reference` and `ID Reference List` for [WAI-ARIA required properties](https://www.w3.org/TR/wai-aria-1.2/#requiredState) at least one of the elements with the given ids exists in the same [document tree](https://dom.spec.whatwg.org/#document-trees) or in the same [shadow tree](https://dom.spec.whatwg.org/#shadow-trees) as the element that specifies the target attribute. | ||
|
|
||
| For value type `URI` the value matches the [generic URI syntax](https://www.ietf.org/rfc/rfc3986.txt). | ||
| **Exception**: For `ID Reference` and `ID Reference List` value types, if the test target is not a [WAI-ARIA required states and properties][] for the [semantic role][] of its element, no ID referenced elements are required. Otherwise at least one of the elements with the given IDs exists in the same [document tree][] or in the same [shadow tree][] as the test target's element. |
There was a problem hiding this comment.
To fully close #1849, I think we need to consider aria-controls as not required on closed combobox (and thus include it in this exception).
This matches the combobox authoring practice, and follows suit with changes made on ARIA 1.3 on combobox. And this is what we discussed on June 23rd.
From the authoring practices (second bullet):
Note that
aria-controlsonly needs to be set when the popup is visible.
ARIA Issue and PR: w3c/aria#1334 / w3c/aria#1335
Co-authored-by: Jean-Yves Moyen <jym@siteimprove.com>
WilcoFiers
requested review from
carlosapaduarte,
colabottles,
daniel-montalvo,
dd8,
kengdoj,
tombrunet and
wcreedle
Jym77
left a comment
Jym77
left a comment
There was a problem hiding this comment.
I think that works.
Exploring a bit different ways of phrasing it, but the current version is good.
| Each test target has an [attribute value][] that is valid according to its [WAI-ARIA value type][value type], except if one of the following is true: | ||
|
|
||
| For value types `ID Reference` and `ID Reference List` for [WAI-ARIA required properties](https://www.w3.org/TR/wai-aria-1.2/#requiredState) at least one of the elements with the given ids exists in the same [document tree](https://dom.spec.whatwg.org/#document-trees) or in the same [shadow tree](https://dom.spec.whatwg.org/#shadow-trees) as the element that specifies the target attribute. | ||
| - <dfn id="off6ek:id-reference">ID Reference</dfn>: For `ID Reference` value types an ID referenced elements is only required for `aria-controls` with [semantic][semantic role] `scrollbar` elements, and with [semantic][semantic role] `combobox` elements that have an `aria-expanded` [attribute value][] of `true`. The ID referenced element must exist in the same [document tree][] or [shadow tree][] as the test target's element. | ||
|
|
||
| For value type `URI` the value matches the [generic URI syntax](https://www.ietf.org/rfc/rfc3986.txt). | ||
| - <dfn id="off6ek:id-reference-list">ID Reference List</dfn>: For `ID Reference List` value types, no ID referenced elements are required. |
There was a problem hiding this comment.
I feel the exceptions are getting somewhat out of hand and hard to read. Trying something in a different direction to see where it goes…
For each test target, depending on its type, either:
- the type is neither ID reference, nor ID reference list, and the value is valid; or
- the type is ID reference, and the attribute is required, and this is not
aria-controlson acomboboxwitharia-expanded != true, and the value is an existingid; or- all other cases pass.
(plus adding Background note that currently no ID reference list is required, and that apart from combobox, the only required ID reference is aria-controls on a scrollbar)
I prefer listing the combobox as an exception as it makes the rule more future proof (if a new required ID ref comes up, we don't need to change the rule)
Maybe it can be make clearer by splitting the requirements:
Expectation 1
For each test target, either the type is ID reference/ID reference list; or the value is valid.Expectation 2
For each test target, either the the type is not ID reference, or it is not required, or it isaria-controlson an closedcombobox, or the value is an existingid.
(again with Background note to explain the reasoning and effect)
This one might makes it harder to see when Expectation 2 triggers since it gets all the negation 🤔
| Only for [WAI-ARIA required properties](https://www.w3.org/TR/wai-aria-1.2/#requiredState) with value types `ID Reference` and `ID Reference List` is there a requirement that the elements with the given ids actually exists. For non-required properties, this is not a requirement. For example, the value of the `aria-errormessage` attribute on an `input` does not need to reference an `id` that exists within the same document, because an [HTML element](https://html.spec.whatwg.org/#htmlelement) with such and `id` may be created in response to an [event](https://dom.spec.whatwg.org/#event) that may or may not happen. | ||
|
|
||
| For value type `URI`, this rule does not require that the destination URI exists. | ||
| Only for [WAI-ARIA required properties][] with value types `ID Reference` and `ID Reference List` is there a requirement that the elements with the given IDs actually exists. For non-required properties, having the referenced element is optional. For example, `aria-errormessage` attribute on an `input` element may have a fixed value, but the element with the error message is only added to the page when an error actually occurred. |
There was a problem hiding this comment.
We should expand on that to explain the combobox exception.
Co-authored-by: Carlos Duarte <caduarte@campus.ul.pt>
|
From the CG call: remove the exceptions from this rule and create a second rule to address the exceptions (in the first rule include a background note stating the second rule is under development) |
WilcoFiers
requested review from
Jym77,
carlosapaduarte,
colabottles and
tombrunet
Jym77
left a comment
Jym77
left a comment
There was a problem hiding this comment.
(requesting change for one description update)
I'm not a huge fan of splitting the rule. I feel the other rule could more or less just be an Expectation 2 in this one. I won't block anything on that account, but it feels we are diluting things a bit too much.
Co-authored-by: Jean-Yves Moyen <jym@siteimprove.com>
|
@Jym77 The reason to split this is because that second expectation got unnecessarily complicated. A new rule lets us keep things simple. It also fits better with the requirement to write atomic rules. There are other rules for which we may do things like this too. For example an allowed ARIA attribute is different from a prohibited attribute, from a deprecated attribute. |
5 participants
This is addressing feedback from the recent ACT TF survey. I've also updated several examples, and filled in a few gaps.
Closes #1849
Need for Call for Review: 1 week, since I'm updating a number of examples
This PR is closely related to #2041, which introduces a new rule that ensures required ID references exist in the page. We're basically splitting that part of this rule off into its own.
How to Review And Approve