Add Cross Root Aria status

Author: Westbrook

reports/2022.html

@@ -370,28 +370,34 @@ <h3>Links</h3>
           <dt>Previous WCCG Report(s)</dt>
           <dd><a href="https://w3c.github.io/webcomponents-cg/index.html#cross-root-aria">2021</a></dd>
           <dt>GitHub issues:</dt>
-          <dd>---</dd>
+          <dd><a href="https://github.com/leobalter/cross-root-aria-delegation" target="_blank">Cross-root ARIA Delegation</a></dd>
+          <dd><a href="https://github.com/Westbrook/cross-root-aria-reflection" target="_blank">Cross-root ARIA Reflection</a></dd>
           <dt>Browser positions:</dt>
           <dd>---</dd>
         </dl>
       </section>
       <section>
         <h3>Description</h3>
-        <p>---</p>
+        <p>
+          Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time.
+        </p>
+        <p>
+          Developers of a custom element should be able to outline to browsers how content from outside of their shadow root realtes to the content within it and visa versa. Cross-root ARIA Delegation would allow developers to define how content on the outside is mapped to the content within a shadow root, while Cross-root ARIA Reflection would define how content within a shadow root was made available to content outside of it.
+        </p>
       </section>
       <section>
         <h3>Status</h3>
-        <ul>
-          <li>---</li>
-        </ul>
+        <p>
+          Implementors participating in bi-weekly Accessibility Object Model syncs with WICG have all been favorable to the delegation work and are interested in the reflection work as a tighly related API that maybe is a fast follower. Leo Balter is working on finalizing proposal text for the delegation API at which time Westbrook Johnson will apply similar teminology to the reflection API proposal.
+        </p>
       </section>
       <section>
         <h3>Initial API Summary/Quick API Proposal</h3>
         <p>Summary or proposal based on current status; paragraph(s) and code.</p>
       </section>
       <section>
         <h3>Key Scenarios</h3>
-        <p>---</p>
+        <p>When developing many of the patterns outlines in the <a href="https://www.w3.org/WAI/ARIA/apg/patterns/" target="_blank">ARIA Authoring Practices Guide</a> having this capability would allow for encapsulating responsibilities outlined by the `role` attribute in a shadow root.</p>
       </section>
       <section>
         <h3>Concerns</h3>
@@ -408,13 +414,17 @@ <h3>Dissenting Opinion</h3>
       <section>
         <h3>Related Specs</h3>
         <ul>
-          <li>---</li>
+          <li><a href="https://github.com/WICG/aom" target="_blank">AOM</a></li>
+          <li><a href="https://wicg.github.io/aom/aria-reflection-explainer.html" target="_blank">ARIA Reflection</a></li>
+          <li><a href="https://github.com/WICG/aom/blob/gh-pages/element_reference_properties.md" target="_blank">Element reference DOM properties</a></li>
         </ul>
       </section>
       <section>
         <h3>Open Questions</h3>
         <ul>
-          <li>---</li>
+          <li>Should these two ideas can/should really ship separately? While the reflection API was ideated after the delegation API it may not be practical to separate them at the implementation/comsuption level.</li>
+          <li>Is `delegation` and `reflection` the right name for these APIs? Particularly, "reflection" is used in <a href="https://wicg.github.io/aom/aria-reflection-explainer.html" target="_blank">ARIA Reflection</a>.</li>
+          <li>There are non-ARIA attributes that would benefit from being supported by these APIs. Should they be drafted in a more general way?</li>
         </ul>
       </section>
     </section>