target-size doesn't respect inline exception for display: inline-block elements

[dbjorge]

Product

axe-core

Product Version

4.9.0

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

Expectation

The tooltip-button with id repro in the repro code below meets SC 2.5.8's Inline exception, so it shouldn't fail the target-size rule.

Actual

False positive (it does fail the rule)

How to Reproduce

Run the target-size rule against the following repro:

<style>
  .no-spacing * {
    margin: 0;
    padding: 0;
  }
  .tooltip {
    border: 0;
    background: none;
    font-family: inherit;
    font-size: inherit;
    cursor: help;
    text-decoration: dotted underline;
  }
</style>
<div class="no-spacing">
  <p>This is a <button id="repro" class="tooltip">term</button> in a sentence.</p>
  <button style="width: 500px; height: 28px">this is a button that's within 24px of the term</button>
</div>

Additional context

This was reported as impacting a customer website by one of our internal auditors.

This is happening because the button in question is display: inline-block (the default for buttons), which the widget-not-inline-matches implementation used as target-size's matcher treats as being "block-like" for the purposes of its isInTextBlock implementation (its code equivalent of the inline exception).

This is related to #3841, but in the other direction; in both cases, the isInTextBlock behavior that treats inline-blocks as not being part of surrounding text blocks is the root cause of the issues, but in #3841 that creates false negatives in some circumstances, and here it's instead creating false positives in some circumstances.

Like @WilcoFiers mentioned in #3841 (comment), because inline-block is the default display for buttons, it's difficult in practice for us to tell whether an inline-block should be treated as part of surrounding text or not (in the repro example above, both buttons are inline-block, but we'd ideally come up with different answers). I definitely don't think we should blanket-incomplete all inline-block things (that would make target-size treat most buttons as inapplicable), but maybe incompleting inline-block things that meet the rest of the parentText/widgetText comparison in isInTextBlock could make sense.

[MelSumner]

Came looking for this; per 2.5.8 Target Minimum, targets in a sentence are acceptable exceptions.

Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;

[straker]

To solve this we're thinking we'll look at the siblings of the inline-block node and if at least one sibling is inline or text then the inline-block node is potentially inline (this also applies to other inline block-like displays such as inline-flex and inline-grid). This means that isInTextBlock needs to be updated to return a 3rd indeterminate state (e.g. undefined) that signifies the potential to be inline.

The caller of isInTextBlock then determines what to do with the indeterminate result. For link-in-text-block that means the matcher we will treat it as a block element and return false in the matcher to not return potential false positives. For target-offset we'll treat it as an inline element and ignore it as a potential neighbor for nearest neighbor calculations.

[straker]

We will split this work into 2 different prs. The first pr will only update walkDomNode of isInTextBlock to look at the siblings and differentiate between block and inline elements for parsing the nodes descendants. The second pr will then address this issue specifically by updating isInTextBlock to return the tri state.