[css-anchor-position-1] Make the a11y section clearer about anchorpos not having any a11y implications itself. w3c/css-aam#14

Author: tabatkins

css-anchor-position-1/Overview.bs

@@ -2412,24 +2412,37 @@ using existing JS APIs (such as {{Element/getBoundingClientRect()}}).
 Accessibility Implications {#accessibility}
 ==========
 
-It's important to remember that Anchor Positioning
+Advisement: CSS Anchor Positioning does not create, delete, or alter any accessibility bindings between elements.
+Authors must use appropriate markup features to control such bindings.
+
+Because it can be used in many different ways
+for many different use cases,
+CSS Anchor Positioning
 does not automatically establish any semantic relationship
 between a positioned box
-and any of its anchors,
-because it can be used in many different ways.
-Authors must not rely solely on a <em>visual</em> connection
-implied by the positioning
-to link elements together semantically;
-without additional help,
-the elements often have <em>no</em> meaningful DOM relationship,
-making them difficult or impossible to use in non-visual user agents,
-like screen readers.
+and any of its anchors.
+For example, the <em>visual</em> anchoring relationship in a design
+might be between an element and its <em>semantic</em> anchor,
+or it might connect the element to an ancestor, sibling, or descendant of the semantic anchor,
+depending on the desired visual effect.
+Siimilarly, a design might opt out of a visual anchoring relationship even while there is a semantic one,
+or vice versa.
+
+Authors must not rely on the visual connections
+implied by CSS positioning
+to link elements together semantically.
+Without appropriate markup,
+the elements linked visually have <em>no</em> meaningful DOM relationship--
+which if there <em>is</em> a meaningful relationship,
+can make them difficult or impossible to use in non-visual user agents,
+like screen readers,
+or in non-graphical navigation modes,
+such as tab navigation.
 
 Many features on the web platform,
 both existing and upcoming,
-allow establishing such connections explicitly,
+allow establishing semantic connections explicitly,
 so that non-visual user agents can also benefit.
-
 For example, the [[HTML#the-popover-attribute|Popover API in HTML]]
 automatically links the invoker button
 to the popover element,
@@ -2445,13 +2458,17 @@ ARIA features such as
 the <a href="https://w3c.github.io/aria/#aria-details"><code>aria-details</code></a>
 or <a href="https://w3c.github.io/aria/#aria-describedby"><code>aria-describedby</code></a> attributes
 on an anchor element
-can provide this information
-in a slightly more manual fashion;
-in concert with the <{html-global/role}> attribute on the positioned element,
-non-visual user agents
-can tell their users about the relationship between the elements
+can create connections
+in a slightly more manual fashion.
+In concert with the <{html-global/role}> attribute on the positioned element,
+it allows non-visual user agents
+to tell their users about the relationship between the elements
 and let them automatically navigate between them.
 
+However, authors should not overuse such features either,
+since overburdening the page with extra, unnecessary semantic connections can also
+make the page difficult to comprehend.
+
 
 
 <!-- Big Text: cssom