Proposed ARIA heuristics

[tabatkins]

Aaron and I have been working on the ARIA auto-detection heuristics, and I think I've got them accurately distilled down to this if/then chain:

• If 'toggle-root' is on a container element |container|,
  'toggle-trigger' is on a descendant |summary|,
  and 'toggle-visibility' is on a different descendent |panel|,
  |container| is disclosure-ish:

  • If |container| does not have any [=disclosure-ish=] siblings
    (or possibly if it does, but most siblings aren't):

    • If there is a 'toggle-group' in action for |container|'s toggle,
      this is NOTHING.
      (It's something without a detectable ARIA pattern.)
    • If |panel| is absolutely positioned or popup'd,
      this is the POPUP PATTERN.
    • Otherwise,
      this is the DISCLOSURE PATTERN.

  • If all (or most?) of |container|'s siblings are [=disclosure-ish=],
    |container|'s parent is accordion-ish:

    • If |panel| is also [=accordion-ish=],
      and there is no 'toggle-group' in action for |container|'s toggle,
      this is the TREE PATTERN.

    • If |panel| isn't [=accordion-ish=]:

      • If there's a 'toggle-group' in action for |container|'s toggle:
        this is the ACCORDION PATTERN.
      • Otherwise,
        this is probably also accordion, but non-exclusive;
        Aaron's not sure how it should be classified.

• If 'toggle-group' is on a container element |container|,
  and all (most?) of |container|'s children are either
  'toggle-root'+'toggle-trigger'
  or 'toggle-visibility' for one of the other sibling's toggles,
  this is the TABS PATTERN.

• If 'toggle-root'+'toggle-trigger' on a single element,
  and no 'toggle-visibility' for that toggle:

  • If there's a 'toggle-group' for the toggle,
    this is the RADIO GROUP PATTERN.

  • Otherwise,
    this is the CHECKBOX PATTERN.
    (or SWITCH PATTERN;
    maybe we auto-decide based on device,
    or make it controllable)

    Aaron wants to also recognize when there are multiple checkbox siblings,
    with no (or few?) non-checkbox siblings,
    as a CHECKBOX GROUP,
    but this isn't a recognized ARIA pattern yet.
    (This is also what the multi-select listbox,
    aka <select multiple>,
    looks like.
    Unsure if worth distinguishing.)

    If you have a CHECKBOX GROUP,
    and its container is itself the |panel| of a POPUP,
    this is instead part of the COMBOBOX pattern
    (aka <select> normally).

• If 'toggle-trigger' on an element,
  and no 'toggle-visibility' is tied to that toggle,
  this is the BUTTON PATTERN.

• Otherwise,
  no pattern detected.

---

For clarity I've omitted the details of exactly what element is what in each pattern (like, Tree has several components), this should hopefully all be relatively obvious.

How do these sound? Do we think these will over-detect? Under-detect? If under, do we need to offer some syntax to opt a toggle into one of the above patterns?

/cc @dbaron @aleventhal

[tabatkins]

For the "most? all?" questions, should auto-exclude non-textual content from consideration. Still need to allow for some text to not disrupt the pattern (like a footer on a tab element, sub-headings on a tree element, etc), but can probably be aggressive after ignoring the decorative elements.

[aleventhal]

I'm adding comments to the google doc for now:
https://docs.google.com/document/d/1dkxgsCVS0mxedDq9czgsPyNwMyuGrmRvYqlz8brPdMU/edit

[patrickhlauke]

to me, this feels like a retrospective effort to fix something that, at its very core, is perhaps not the best idea: making CSS handle state and semantics/behaviour, and now trying to define how this then should be exposed to the accessibility tree, through the use of clever heuristics?

is it perhaps missing the more fundamental "is CSS the right place to define state, semantics, and behaviour"? this really seems to blur the separation of concerns for no good reason other than "we can now do CSS-only widgets"

should behaviour not be done in JS? and explicit role/state/etc, rather than inferring it by the backdoor through heuristics? as developers, we're already often fighting heuristics that "know best" (case in point, situations where webkit decides not to expose something as a list because the bullets have been styled away), and having to then re-redefine the correct semantics back in explicitly with unnecessary role="..." etc. this just adds yet another indirection layer.

[aleventhal]

Hi @patrickhlauke I hear you. Let's come up with a demo. I'm not an expert as to whether it should be in CSS or not — but I understand that it solves a lot of other problems if we do that. So, if authors really like it and use that over the current div-soup, we could have really nice a11y by default compared to what we have now, and still provide authors a means to override with more customize a11y. But the base state would be a lot more accessible than now.

[patrickhlauke]

back in the days, it would have been a new set of HTML elements with built-in semantics/attributes/interactions - and doing it declaratively.

to me, it just feels odd that these days this is pushed from the CSS side, with heuristics instead.

i have no doubt that some devs will gladly take this up, if the alternative is having to - like today - do due diligence and setting correct roles/ARIA attributes via JS themselves, not sure that gives a good indication on whether or not different approaches might be better suited.

[aleventhal]

I believe the plan is to also have high level elements that are backed by this, but the browser would also expose the underlying power to the developer who wants it.

Everyone wants to know why this should be in CSS, including me. Nicole has a bunch of reasons why that's a good thing, even though it's so against what CSS is usually supposed to be. This Q is going to come up again and again :)

[FremyCompany]

Adding myself to this thread, and back-linking #40

[FremyCompany]

Let's look at the demo that was made, and how the heuristics apply to it.

<section style="toggle-root: slides 3 at 1 cycle-on;">
    <div class="control">
        <div class="btn prev-slide" style="toggle-trigger: slides prev;"></div>
        <div class="btn next-slide" style="toggle-trigger: slides next;"></div>
    </div>
    <div class="slide-content">
        <article></article>
        <article></article>
        <article></article>
    </div>
    <div class=pagination>
        <div class="number" style="toggle-trigger: slides set 1">1</div>
        <div class="number" style="toggle-trigger: slides set 2">2</div>
        <div class="number" style="toggle-trigger: slides set 3">3</div>
    </div>
</div>

Let's run the heuristics:

If 
  'toggle-root' is on a container element |container|, 
     // yes, |container| would be <section>
  'toggle-trigger' is on a descendant |summary|, 
    // yes, though there are multiple candidates for |summary|
  and 'toggle-visibility' is on a different descendent |panel|, 
    // no, there is no such element
then 
  |container| is disclosure-ish

So <section> is not a disclosure element. Already failed, because <section> was an accordion.

I followed the list of rules further, none apply, so basically we get:

Otherwise,
  no pattern detected.

Do I have to mention how the "buttons" are not keyboard-focusable either?

[FremyCompany]

I also really do not like that the total number of pages has to be defined in CSS. This is not a "styling" value, this is a content value, and this belongs in the markup (or it should be inferred).

I think this proposal is interesting, but still needs a lot of work before it can be considered seriously.

[yisibl]

I also really do not like that the total number of pages has to be defined in CSS.

@FremyCompany Please follow this: w3c/csswg-drafts#4559

[aleventhal]

Hi all, the proposed heuristics are just a start. Please give us a chance to show a prototype. I'm sure there will be gaps to address. I personally won't give my blessing to anything that provides a poor a11y experience. Patience appreciated.

[FremyCompany]

I am personally very afraid of something that gives the impression :toggle is accessible because we can define heuristics that work in a few selected cases, but which results in nothing working accessibly in many cases in the wild (because authors cannot run these heuristics in their head, or someone down the line makes a tiny change that destroy the heuristics they were not aware were necessary for the app to stay accessible).

When a single feature can trigger that many different types of aria patterns, each of which is not easy to implement, it probably means the feature is not tailored enough and just tries to do to many things at once.

I'm still very much of opinion that the current proposal is not the right approach for the list of problems it tries to target, and this is the reason why it requires so complex heuristics in the first place. If authors need to add properties that "do nothing" or "are not strictly necessary" but are required for making things accessible, I think we are reinventing ARIA in CSS, and I would be very concerned about that.

[aleventhal]

@FremyCompany that's fair. I hear you. How about we see how it works? I believe that in the worse case scenario it will fall back on something reasonable. But, I will try to build it, and the community can try to break it. Thus we will either figure out it doesn't work or end up with something pretty good. I believe that this is much better than what we have now, which is that authors get nothing for free, and if they do try to use ARIA, it does not usually go very well.