Skip to content

Commit

Permalink
Add Cross Root Aria status (#46)
Browse files Browse the repository at this point in the history 
* Add Cross Root Aria status

* Add code sample

* Remove unused sections.
  • Loading branch information
@Westbrook
Westbrook authored Sep 2, 2022
1 parent c612d51 commit 690c40c
Showing 1 changed file with 76 additions and 21 deletions.
97 changes: 76 additions & 21 deletions reports/2022.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -370,51 +370,106 @@ <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>
<h4>Delegation API</h4>
<p>HTML</p>
<pre>
<code>
&lt;span id="foo">Description!&lt;/span>
&lt;template id="template1">
&lt;input id="input" autoarialabel autoariadescribedby />
&lt;span autoarialabel>Another target&lt;/span>
&lt;/template>
&lt;x-foo aria-label="Hello!" aria-describedby="foo">&lt;/x-foo>
</code>
</pre>
<p>JS</p>
<pre>
<code>
const template = document.getElementById('template1');

class XFoo extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: "open", delegatesAriaLabel: true, delegatesAriaDescribedBy: true });
this.shadowRoot.appendChild(template.content.cloneNode(true));
}
}

customElements.define("x-foo", XFoo);
</code>
</pre>
<h4>Reflection API</h4>
<p>HTML</p>
<pre>
<code>
&lt;input aria-controlls="foo" aria-activedescendent="foo">Description!&lt;/span>
&lt;template id="template1">
&lt;ul reflectariacontrols>
&lt;li>Item 1&lt;/li>
&lt;li reflectariaactivedescendent>Item 2&lt;/li>
&lt;li>Item 3&lt;/li>
</ul>
&lt;/template>
&lt;x-foo id="foo">&lt;/x-foo>
</code>
</pre>
<p>JS</p>
<pre>
<code>
const template = document.getElementById('template1');

class XFoo extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: "open", reflectsAriaControls: true, reflectsAriaActivedescendent: true });
this.shadowRoot.appendChild(template.content.cloneNode(true));
}
}
customElements.define("x-foo", XFoo);
</code>
</pre>
</section>
<section>
<h3>Key Scenarios</h3>
<p>---</p>
</section>
<section>
<h3>Concerns</h3>
<ul>
<li>---</li>
</ul>
</section>
<section>
<h3>Dissenting Opinion</h3>
<ul>
<li>---</li>
</ul>
<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>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>
Expand Down

0 comments on commit 690c40c

Please sign in to comment.