Product: cli

Motivation:

ARIA 1.2 introduces the following imperative in the role aria-errormessage definition: When aria-errormessage is pertinent, authors MUST ensure the content is not hidden so users can navigate to and examine the error message. Similarly, when aria-errormessage is not pertinent, authors MUST either ensure the content is hidden or remove the aria-errormessage attribute or its value.

Replication of error:

If you run the AXE cli (axe-core 4.3.2 in chrome-headless with --tags cat.aria) on an HTML with the following HTML you will see some errors, but it seems like incorrect ones.

<input type="text" id="input-1" aria-invalid="true" aria-errormessage="id-message-1"></div>
<div id="id-message-1" hidden>Error message 1</div>

<input type="text" id="input-2" aria-invalid="true" aria-errormessage="id-message-2"></div>
<div id="id-message-2" style="display: none">Error message 2</div>

<input type="text" id="input-3" aria-invalid="true" aria-errormessage="id-message-3"></div>
<div id="id-message-3" style="visibility: hidden">Error message 3</div>

<input type="text" id="input-4" aria-invalid="true" aria-errormessage=""></div>

The error is:

  Violation of "aria-valid-attr-value" with 3 occurrences!
    Ensures all ARIA attributes have valid values. Correct invalid elements at:
     - #input-1
     - #input-2
     - #input-3

The failure summary is: Fix all of the following:\n aria-errormessage value id-message-1 must use a technique to announce the message (e.g., aria-live, aria-describedby, role=alert, etc.)",

Expectation:

You should see an error about how the divs have a hidden value, and you should see this error on all four examples listed above. The error reported seems incorrect according to the 1.2 specification.