Notes for March 28 f2f

[alice]

Phase 1 topics

• Status of ARIA reflection discussion?
• Options for Element reflection?
  • fooElements or just foo?
  • if fooElements, what reflection is there between fooElements and foo?
  • which ARIA properties should be exposed this way?
• Any discussion of ARIA properties on ShadowRoot? Where should that happen?

Phase 2 topics

• What events should we support?
• Where should this be specced? Who needs to buy in/approve?
• What are we saying about permissions and privacy?
  • Should we limit this to HTTPS?

Phase 3 topics

• How do we attach a virtual tree?
  • Strawman proposal (based heavily on Shadow DOM pattern)

  // Removes all DOM-based children from consideration for the computed accessibility tree
  // (including Shadow DOM)
  canvas.attachAccessibleRoot();
  
  // The AccessibleRoot object is just a "container" for virtual AccessibleNode children of the
  // host (canvas in this case) element, does not appear in the computed tree, has no semantics -
  // analogous to how the ShadowRoot does not appear in the flat tree.
  let table = canvas.accessibleRoot.appendChild(new AccessibleNode());
  table.role = 'table';
  table.ariaColCount = 10;  // See below
  table.ariaRowcount = 100;
  let headerRow = table.appendChild(new AccessibleNode());
  headerRow.role = 'row';
  headerRow.ariaRowindex = 0;
  // etc. etc.

• What is the API for a virtual AccessibleNode?
  • Is it more like Node or more like ComputedAccessibleNode?

Phase 4 questions

https://github.com/dot-miniscule/aom/blob/gh-pages/phase-4-explainer.md#open-questions

[alice]

Notes

f2f notes

Phase 1 topics

• Status of ARIA reflection discussion?
• Options for Element reflection?
  • fooElements or just foo? Add ARIA property string reflection on Element w3c/aria#691 (comment)
    • "Mixed" (polymorphic) array option?
    • setter?

  // <div id="foo" aria-activedescendant="id1">
  
  foo.ariaActiveDescendant = el2;
  
  // --> <div id="foo"> OR <div id="foo" aria-activedescendant>
  // OR <div id="foo" aria-activedescendant="id1"> <!-- dirty bit -->
  // What happens if you then set the attribute again?

  • https://html.spec.whatwg.org/multipage/canvas.html#canvasfillstrokestyles seems to be a precedent

  • https://developer.mozilla.org/en-US/docs/Web/API/FileReader/result

  • https://developer.mozilla.org/en-US/docs/Web/API/AnimationEffectTimingReadOnly/duration

  • if fooElements, what reflection is there between fooElements and foo?

    • Issues with two way reflection:
      • Computational complexity - need to check all elements for IDs
      • Confusing that reflection has "holes" in it
    • One way reflection options:
      • Dirty bit?
      • Possible to "clear" the overriding fooElements property?
      • More backwards compatible to explicitly set activeDescendantElement to clear the attributes (?)
      • Test tools may flag things which are set using fooElements either way

  • which ARIA properties should be exposed this way?

  • Concerns about Shadow DOM: relations going into Shadow DOM are exposing implementation details, while relations going out of Shadow DOM are completely fine

  • Can we reverse that relationship?

    • Ordering is significant and can be specified by aria-labelledby

  • Activedescendant probably most important use case here.
    Shadow Host will have semantics but will probably need to specify an active descendant inside its shadow root.

  • Can custom element return an object representing a "target"/proxy for relationships?

  • And/or can a shadow root "delegate" to a single internal element as its "actual" target?

    <my-listbox>
        # shadow root
        |    <div role="listbox" aria-activedescendant="c">
        |    </div>
        |    <slot></slot>
        <my-option>
            # shadow root
            |    <div role="option" id="c"></div>
        </my-option>
    </my-listbox>

    <!-- IS THIS A THING -->
    <my-list id="fruits"></my-list>
    <my-list id="tree"></my-list>
    <my-option for="fruits tree">
        Apple
    </my-option>

    <my-option>
        # shadow root
        |  <div role="none">
        |       <div role="none">
        |           <div role="option">
    ...

  • Consensus: let's allow going out of shadow root.

  • Consensus: let's defer discussion of potential delegate API until we have acutal pain points available.

  • Consensus: let's use the general pattern for element reflection, whatever that ends up being.

• Any discussion of ARIA properties on ShadowRoot? Where should that happen?

Phase 2 topics

• What events should we support?
• Where should this be specced? Who needs to buy in/approve?
• What are we saying about permissions and privacy?
  • Should we limit this to HTTPS?

Phase 3 topics

• How do we attach a virtual tree?

  • Strawman proposal (based heavily on Shadow DOM pattern)

  // Removes all DOM-based children from consideration for the computed accessibility tree
  // (including Shadow DOM)
  canvas.attachAccessibleRoot();  // this also returns the accessibleRoot
  
  // The AccessibleRoot object is just a "container" for virtual AccessibleNode children of the
  // host (canvas in this case) element, does not appear in the computed tree, has no semantics -
  // analogous to how the ShadowRoot does not appear in the flat tree.
  let table = canvas.accessibleRoot.appendChild(new AccessibleNode());
  table.role = 'table';
  table.colCount = 10;  // See below
  table.rowCount = 100;
  let headerRow = table.appendChild(new AccessibleNode());
  headerRow.role = 'row';
  headerRow.rowIndex = 0;
  // etc. etc.
  // In order for a table to work we'd need some additional methods.

  • Consensus: attachAccessibleRoot() is ok

• What is the API for a virtual AccessibleNode?

  • Is it more like Node or more like ComputedAccessibleNode?
  • Consensus: More like ComputedAccessibleNode (no aria prefix, etc.)

• What about the list/table/set APIs like rowcount etc?

  • These exist on all platforms...
  • Unclear if we want to ship this if there might be a better way to build an accessible table/grid using a new API. Do we ship the old thing if we wouldn't have designed it the same way with a new API?
  • Can we explore what a future new table API would look like?
  • Sounds like Dominic could do some exploration here.

• AI: James to provide whitelist of properties we want on AccessibleNode/ComputedAccessibleNode

  • May wish to refer to https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/ComputedAccessibleNode.idl?q=ComputedAccessibleNode&sq=package:chromium&dr=C&l=10

• Interaction between shadowRoot and accessibleRoot?

  • Should we throw() if someone tries to have both on the same element?
    • No.

Phase 4 questions

https://github.com/dot-miniscule/aom/blob/gh-pages/phase-4-explainer.md#open-questions