You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the ARIA specs, from my perspective, there's clarity on how user agents should handle empty or invalid references for properties accepting ID reference list as values. However, it's less clear whether this is an authoring issue. This ambiguity might explain why testing tool implementers handle them inconsistently, with some tools issuing errors and others alerts.
This could also stem from the varying terminology used for different attributes.
States and properties specifically applicable to the role and child roles. Authors MAY provide values for supported states and properties, but need not in cases where default values are sufficient. user agents MUST map all supported states and properties for the role to an accessibility API. If the state or property is undefined and it has a default value for the role, user agents SHOULD expose the default value.
it appears that authors are permitted to omit providing a value in this context.
The value of the aria-ownsattribute is a space-separated ID reference list that references one or more elements in the document by ID. The reason for adding aria-owns is to expose a parent/child contextual relationship to assistive technologies that is otherwise impossible to infer from the DOM.
where it seems that using aria-owns="" or aria-owns="$invalid_id" is not permitted.
In aria-controls property instead, specs simply says:
Identifies the element (or elements) whose contents or presence are controlled by the current element. See related aria-owns.
Someone may argue that this implies that aria-owns has stricter requirements compared to aria-controls.
I believe the specifications, especially considering the dynamic nature of contemporary websites, aim to empower authors to set empty or "invalid" values as long as the DOM is populated accordingly when necessary. If this interpretation is accurate, I suggest it would be beneficial to clarify this in the specifications. Conversely, if this interpretation is incorrect, it becomes even more crucial to add clarity to the specifications.
In the meantime, I'm working on drafting a PR.
The text was updated successfully, but these errors were encountered:
Issue Description:
In the ARIA specs, from my perspective, there's clarity on how user agents should handle empty or invalid references for properties accepting ID reference list as values. However, it's less clear whether this is an authoring issue. This ambiguity might explain why testing tool implementers handle them inconsistently, with some tools issuing errors and others alerts.
This could also stem from the varying terminology used for different attributes.
For example, chapter 5.2.3 Supported States and Properties states:
it appears that authors are permitted to omit providing a value in this context.
But in aria-owns property, specs says:
where it seems that using aria-owns="" or aria-owns="$invalid_id" is not permitted.
In aria-controls property instead, specs simply says:
Someone may argue that this implies that aria-owns has stricter requirements compared to aria-controls.
I believe the specifications, especially considering the dynamic nature of contemporary websites, aim to empower authors to set empty or "invalid" values as long as the DOM is populated accordingly when necessary. If this interpretation is accurate, I suggest it would be beneficial to clarify this in the specifications. Conversely, if this interpretation is incorrect, it becomes even more crucial to add clarity to the specifications.
In the meantime, I'm working on drafting a PR.
The text was updated successfully, but these errors were encountered: