CSS: handing the a11y of anchor positioning #545
Comments
|
+1 on copying the logic from popover siblings, and to not doing it for
aria-details=""
…On Fri, May 10, 2024 at 10:51 AM scottaohara ***@***.***> wrote:
briefly spoke about this with @aleventhal <https://github.com/aleventhal>
today (cc @mfreed7 <https://github.com/mfreed7>)
from what i understand there have been talks about creating an
aria-details relationship, similar to the one defined for popovers, if
authors were to use CSS anchor positioning to associate elements with one
another.
this may be useful / help provide a baseline of information for instances
where an author has decided to 'tether' one element to another in the UI,
but not provide any meaningful semantics to programmatically communicate
this relationship.
if this were to be done, would expect this to have similar logic to
popovers, where the aria-details relationship is not exposed if the
elements are direct accessibility siblings to each other. Additionally, it
might make sense to not expose this relationship depending on the roles of
the elements that are associated. e.g., if someone were to use a
role=tooltip and/or had an aria-describedby association already made, then
the aria-details association would likely just be extra noise - so maybe
don't do that then.
also, might be worth reiterating that if someone were to use an
aria-details="" on one of the elements, that the details relationship
should be considered null - as that should be considered a signal from the
author that they do not want there to be a details relationship, for
whatever reason.
—
Reply to this email directly, view it on GitHub
<#545>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZU72TPDSPUF23UBTNTZBTNIZAVCNFSM6AAAAABHQYRRSOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4DSOBYG43DKNI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
That makes sense to me. I think it'd be good to expand the list of cases where the relationship would not be added -- does this list make sense to you two?:
|
|
Hi Sarah, interesting, I hadn't thought of these.
After mulling it over, I think that probably only aria-details needs to
prevent aria-details from being auto-added. Well that, and if the detail
thing would have been the next sibling anyway (same rule as for popover).
For example, just because something has a label or description doesn't mean
that another area of the page being pointed to is irrelevant.
As far as aria-owns, these should be treated like any other children,
shouldn't they? Maybe we can imagine use cases. Since I don't understand
this one very well, I'm tempted to leave it out as well.
In the end I think a clear rule where we aren't guessing a lot might be
better, even if we get it wrong sometimes.
So my vote so far is to go with the same rule as for popovers. WDYT?
…On Thu, May 23, 2024 at 5:53 PM Sarah Higley ***@***.***> wrote:
That makes sense to me. I think it'd be good to expand the list of cases
where the relationship would not be added -- does this list make sense to
you two?:
- aria-labelledby
- aria-describedby
- aria-details (would this be excluded just with an empty string, or
for any existing details relationship?)
- aria-owns
—
Reply to this email directly, view it on GitHub
<#545 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZSASP5TCA3JWFHSVB3ZDZQNFAVCNFSM6AAAAABHQYRRSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRYGA3TQMZXGY>
.
You are receiving this because you were mentioned.Message ID:
<w3c/html-aam/issues/545/2128078376 ***@***.***>
|
|
@aleventhal sorry, I think I should've been more specific 😅. I didn't mean if the anchor had any My thought behind |
|
Oh ok, all of this makes sense.
…On Tue, May 28, 2024 at 5:22 PM Sarah Higley ***@***.***> wrote:
@aleventhal <https://github.com/aleventhal> sorry, I think I should've
been more specific 😅. I didn't mean if the anchor had any aria-labelledby
/aria-describedby at all, but specifically if it already had that
relationship with the anchored element. In that case, I think it would be
good to not make the anchored element into both the label and the details
of the anchor.
My thought behind aria-owns is similar to excluding it for siblings -- if
the anchored element is already a child or owned element of the anchor,
then it probably doesn't also need a details relationship. I suppose that
could get a little iffy for containers with a lot of content, though (also
not sure how common that is).
—
Reply to this email directly, view it on GitHub
<#545 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZUPHPLN4PMT6W4QXL3ZETYQHAVCNFSM6AAAAABHQYRRSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGEZTENRUGM>
.
You are receiving this because you were mentioned.Message ID:
<w3c/html-aam/issues/545/2136132643 ***@***.***>
|
|
Discussed in today's meeting: https://www.w3.org/2024/05/30-aria-minutes.html#t06 |
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Sep 24, 2024
Anchor positioning is a new CSS feature that allows elements to be positioned relative to other elements on a web page. To make this feature accessible, an aria-details relationship is created between the anchor element and the related positioned element to convey the elements' association with each other. More specifically, detailsIds will be set on the anchor element to the id of the positioned element. If there are multiple anchors for an element, it is likely the anchors are used for layout purposes. To avoid creating extra noise for AT, we only add an aria-details relationship if there is a one to one mapping of anchor to positioned element. [1] w3c/html-aam#545 Change-Id: I7ee03ed5404bf4ed55a66e8f4aac7e2f17508b9d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5774305 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Commit-Queue: Jocelyn Tran <[email protected]> Reviewed-by: Aaron Leventhal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1359411}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
briefly spoke about this with @aleventhal today (cc @mfreed7)
from what i understand there have been talks about creating an aria-details relationship, similar to the one defined for popovers, if authors were to use CSS anchor positioning to associate elements with one another.
this may be useful / help provide a baseline of information for instances where an author has decided to 'tether' one element to another in the UI, but not provide any meaningful semantics to programmatically communicate this relationship.
if this were to be done, would expect this to have similar logic to popovers, where the aria-details relationship is not exposed if the elements are direct accessibility siblings to each other. Additionally, it might make sense to not expose this relationship depending on the roles of the elements that are associated. e.g., if someone were to use a role=tooltip and/or had an aria-describedby association already made, then the aria-details association would likely just be extra noise - so maybe don't do that then.
also, might be worth reiterating that if someone were to use an
aria-details=""on one of the elements, that the details relationship should be considered null - as that should be considered a signal from the author that they do not want there to be a details relationship, for whatever reason.The text was updated successfully, but these errors were encountered: