Elements with Fallback, Proxy, Replacement, Substitute, or Surrogate Elements

[AdamSobieski]

What problem are you trying to solve?

What if DOM elements could provide fallback, proxy, replacement, substitute, or surrogate elements for themselves?

This would enable scenarios including shadow tree navigation, accessibility, internationalization, and content negotiation.

What solutions exist today?

The DOM provides means to navigate shadow trees. The approach broached here would add to the existing solution, in these regards.

Solutions exist for Web accessibility such as placing ARIA attributes on documents' elements. Creating a means for elements to provide fallback, proxy, replacement, substitute, or surrogate elements would enable accessibility surrogates, alternative elements custom-tailored for accessibility scenarios.

Solutions exist for Web internationalization such as ITS.

How would you solve it?

I would first consider adding to the Element interface in a manner resembling:

partial interface Element
{
  Element? getProxy(DOMString type, optional object options);

  readonly property boolean isProxy;
  readonly attribute DOMString? proxyType;
  readonly attribute object? proxyOptions;
  readonly property Element? origin;
}

Developers would then be able to query elements to see whether they have fallback, proxy, replacement, substitute, or surrogate elements for indicated scenarios. For examples:

var x1 = element.getProxy('shadow');

var x2 = element.getProxy('wai-aria');

var x3 = element.getProxy('content', {
  acceptLanguage: 'en;q=0.8, de;q=0.7, fr;q=0.6, *;q=0.5'
});

var x4 = element.getProxy('content', {
  accept: 'text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8',
  acceptLanguage: 'en;q=0.8, de;q=0.7, fr;q=0.6, *;q=0.5'
});

I would also consider adding to the ElementCreationOptions dictionary for the Document::createElement() and Document::createElementNS() methods. Alternatively, Document::createProxyElement() and Document::createProxyElementNS() methods could be considered.

Anything else?

Accessibility surrogates for HTML elements and (nestable) custom elements could be comprised of HTML elements decorated with ARIA attributes or could be comprised of ARIA elements.

For example, a nested custom element resembling:

<custom-widget>
  <custom-button>Click here</custom-button>
</custom-widget>

could provide an HTML-based accessibility surrogate resembling:

<div class="accessibility-surrogate">
  <button aria-details="info-note">Click here</button>
  <div role="note" id="info-note">
    <p>Please visit our <a href="...">accessibility page</a> for more information.</p>
  </div>
</div>

Or, for an example of what an ARIA-elements-based accessibility surrogate might resemble:

<aria:input aria:role="button" xhtml:onclick="...">
  <aria:label>
    <aria:alt>
      <aria:data aria:type="text/plain">Click here</aria:data>
      <aria:data aria:type="application/xhtml+xml" aria:media="(prefers-contrast: more)">
        <xhtml:span class="high-contrast">Click here</xhtml:span>
      </aria:data>
      <aria:data aria:type="application/ssml+xml">
        <ssml:speak>
          <ssml:phoneme ssml:alphabet="ipa" ssml:ph="klɪk">Click</ssml:phoneme>
          <ssml:phoneme ssml:alphabet="ipa" ssml:ph="hir">here</ssml:phoneme>
        </ssml:speak>
      </aria:data>
      <aria:data aria:type="application/braille">⠠⠉⠇⠊⠉⠅ ⠓⠑⠗⠑</aria:data>
    </aria:alt>
  </aria:label>
  <aria:details>
    <aria:note aria:type="application/xhtml+xml">
      Please visit our <xhtml:a href="...">accessibility page</xhtml:a> for more information.
    </aria:note>
  </aria:details>
</aria:input>

Accessibility trees and HTML document trees are already "parallel structures". ARIA elements could be "parallel structures" intended for consumption by assistive technologies.

Thank you. I look forward to discussing these ideas with you.