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.