axe-core icon indicating copy to clipboard operation
axe-core copied to clipboard

Reconsider the impact of the parent/child rules

Open WilcoFiers opened this issue 2 years ago • 2 comments

With axe-core support for IE deprecated, it is no longer quite as important for pages to get their parent/child relationships correct. One case that came up recently was where a site had double-nested their dd / dt elements in divs:

<dl>
  <div> <div> <dt>Hello world</dt> </div> </div>
</dl>

This fails axe-core. However the importance of this to screen readers seems pretty minimal. Where this may still matter is to people who make heavy use of custom style sheets. If you wanted an alternative presentation of definition lists you may use dl:has(> dt, > dd, > div > dt, > div > dd) as a selector. This would let you style valid definition lists, but it would break on this invalid scenario.

Since custom style sheets are often highly individualized there isn't a big repository out there we could check to see if this is an issue. It still theoretically could be, but it is difficult to know whether in practice this creates accessibility issues. We should do some research in this subject and figure out whether impact needs to be updated and/or maybe this should no longer fail under WCAG.

There are quite a few rules that do parent/child relationship checking. We'll probably need to update them all for this.

  • list
  • listitem
  • definition-list
  • dlitem
  • aria-required-child
  • aria-required-parent

WilcoFiers avatar Dec 20 '23 17:12 WilcoFiers

There was a report of this in the a11y-web community slack yesterday that noted that axe-core's current behavior is actually inconsistent between the assorted rules that do parent/child relationship tracking. I agree with the consensus in that thread that we probably shouldn't treat semantic lists and role="list" differently now that 4.1.1 isn't a thing (unless we find an actual difference in accessibility-supported-ness, which I didn't see in my testing below)

The specific example from the thread was:

<h2>Cases where it's questionable that they're treated differently</h2>
<!-- violation of list rule -->
<ul id="a">
  <div>
    <li>item 1</li>
    <li>item 2</li>
  </div>
</ul>

<!-- *not* a violation of aria-required-children -->
<div id="b" role="list">
  <div>
    <div role="listitem">item 1</div>
    <div role="listitem">item 2</div>
  </div>
</div>

I tested these in (Chrome, Firefox, Safari) x (NVDA, VO) and it seemed like they were all read consistently as being lists of 2 items.

I also tested some other cases that do cause problems for ATs (including case "f" that's probably a false negative for aria-required-children):

<!-- violation of list rule -->
<ul id="c">
  <div aria-label=""> <!-- or any other global aria attr -->
    <li>item 1</li>
    <li>item 2</li>
  </div>
</ul>

<!-- violation of aria-required-children -->
<div id="d" role="list">
  <div aria-label=""> <!-- or any other global aria attr -->
    <div role="listitem">item 1</div>
    <div role="listitem">item 2</div>
  </div>
</div>

<!-- violation of list rule -->
<ul id="e">
  <!-- yes, just adding an id to the div really does change most AT behavior into misreading as a list of 1 items -->
  <div id="e-intermediate">
    <li>item 1</li>
    <li>item 2</li>
  </div>
</ul>

<!-- *not* violation of aria-required-children -->
<div id="f" role="list">
  <div id="f-intermediate">
    <div role="listitem">item 1</div>
    <div role="listitem">item 2</div>
  </div>
</div>

dbjorge avatar May 01 '25 16:05 dbjorge

See also related but slightly different issue https://github.com/dequelabs/axe-core/issues/4294

dbjorge avatar May 01 '25 16:05 dbjorge