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
B. Computing an accessible name for an element. Multiple steps in the algorithm at https://w3c.github.io/accname/#computation-steps for computing an accessible name for an element in turn require computing a role for that element.
That is: In order to implement A. Computing a role for an aside or section element in my code, I need to have that code call my implementation of B. Computing an accessible name for an element. But in order to implement B. Computing an accessible name for an element in my code, I need to have that code call my implementation of A. Computing a role for an aside or section element.
In other words, my code gets into an infinite loop if I implement the requirements as specified.
Does the issue exists in the editors draft is the most recent draft of the specification? Yes
The text was updated successfully, but these errors were encountered:
sideshowbarker
changed the title
[html-aam] Computing a role for the “aside” element creates an infinite loop
[html-aam] Computing a role for a “aside” or “section” element creates an infinite loop
Dec 5, 2024
B.…computing an accessible name for an element in turn require computing a role for that element.
aside has either a complementary or generic role. Since genericcan’t be named, when checking whether aside has an accessible name, its role can be assumed to be complementary, right? By assuming that, actual role computation would be unnecessary, avoiding the infinite loop.
would this make more sense if the spec indicated the default roles to be complementary / region - and THEN have a condition to change those roles based on ancestral checks (for aside) or if the elements are named (for both elements) - rather than separating these out so the elements each had two tables?
I think you should resolve the loop in the algorithms somehow. E.g., give "computing an accessible name" a boolean that indicates it's invoked for role computing purposes in which case it uses fallback roles for certain elements might do the trick?
Consider these two things:
A. Computing a role for an
aside
orsection
element. The conditions at https://w3c.github.io/html-aam/#el-aside and https://w3c.github.io/html-aam/#el-section for computing a role for anaside
element orsection
element in turn require computing an accessible name for theaside
element orsection
element.B. Computing an accessible name for an element. Multiple steps in the algorithm at https://w3c.github.io/accname/#computation-steps for computing an accessible name for an element in turn require computing a role for that element.
That is: In order to implement A. Computing a role for an
aside
orsection
element in my code, I need to have that code call my implementation of B. Computing an accessible name for an element. But in order to implement B. Computing an accessible name for an element in my code, I need to have that code call my implementation of A. Computing a role for anaside
orsection
element.In other words, my code gets into an infinite loop if I implement the requirements as specified.
See also Siteimprove/alfa#298
Link to documentation: https://w3c.github.io/html-aam/#el-aside
Does the issue exists in the editors draft is the most recent draft of the specification? Yes
The text was updated successfully, but these errors were encountered: