[BUG]: Spurious "Form control element <input> has no associated label" error

[wkeese]

Project

accessibility-checker for Node

Browser

No response

Operating system

MacOS

Description

I get a spurious error when running from Node:

Form control element has no associated label

It works when run from Chrome.

Version tested:

% npm list accessibility-checker
@ibma/[email protected] /Users/bill/oss/equal-access/accessibility-checker/boilerplates/jest
└── [email protected]
% node --version
v20.9.0
% npm list jsdom
@ibma/[email protected] /Users/bill/oss/equal-access/accessibility-checker/boilerplates/jest
└─┬ [email protected]
  └── [email protected]

Steps to reproduce

cd boilerplates/jest
npm install
Update basic.test.js as:

/**
 * @jest-environment jsdom
 */

const originalGetComputedStyle = window.getComputedStyle;
window.getComputedStyle = (node) => originalGetComputedStyle(node);

describe("Hello World - Baseline Basics", () => {
    test("Image missing alt without Baseline", async () => {
        document.body.innerHTML = `
<input
        id="myCheckbox"
        type="checkbox"
        name="myc"
      />
      <label
        class="cds--checkbox-label"
        for="myCheckbox"
      >
        My checkbox
      </label>
        `
        await expect(document).toBeAccessible("IMG_NO_BASELINE")
    })
})

Output will include

    - Message: Form control element <input> has no associated label
      Level: violation
      XPath: /html[1]/body[1]/input[1]
      Snippet: <input name="myc" type="checkbox" id="myCheckbox">
      Help: https://able.ibm.com/rules/archives/2024.11.13/doc/en-US/input_label_exists.html#%7B%22message%22%3A%22Form%20control%20element%20%3Cinput%3E%20has%20no%20associated%20label%22%2C%22snippet%22%3A%22%3Cinput%20name%3D%5C%22myc%5C%22%20type%3D%5C%22checkbox%5C%22%20id%3D%5C%22myCheckbox%5C%22%3E%22%2C%22value%22%3A%5B%22VIOLATION%22%2C%22FAIL%22%5D%2C%22reasonId%22%3A%22Fail_1%22%2C%22ruleId%22%3A%22input_label_exists%22%2C%22msgArgs%22%3A%5B%22input%22%5D%7D

Version tested:

bill@Bills-MacBook-Pro-2 jest % npm list accessibility-checker
@ibma/[email protected] /Users/bill/oss/equal-access/accessibility-checker/boilerplates/jest
└── [email protected]

[shunguoy]

@wkeese can you please also post your HTML test case? thanks

[philljenkins]

@wkeese

It works when run from Chrome.

1. Which version of the Checker in Chrome, v3.1.78?
2. Does it also fail in the extension in Firefox DevTools with v3..1.78?
3. With the Latest Deployment ruleset?

[wkeese]

@wkeese can you please also post your HTML test case? thanks

I already did, but here it is again:

<input
        id="myCheckbox"
        type="checkbox"
        name="myc"
      />
      <label
        class="cds--checkbox-label"
        for="myCheckbox"
      >
        My checkbox
      </label>

Which version of the Checker in Chrome, v3.1.78?

Yes, 3.1.78.

Does it also fail in the extension in Firefox DevTools with v3..1.78?

No error in Firefox, only Node.

With the Latest Deployment ruleset?

My config settings are:

// optional - Specify the rule archive
// Default: latest
// Run `npx achecker archives` for a list of valid ruleArchive ids and policy ids
ruleArchive: "latest",

// optional - Specify one or many policies to scan.
// Run `npx achecker archives` for a list of valid ruleArchive ids and policy ids
policies: ["IBM_Accessibility"],

That's also what I tested on Firefox:

Cross reference:

% npx achecker archives

Archive [Archive Id]
  - Policy [Policy Id]:
-----------------------

Latest Deployment [latest]
  - IBM Accessibility 7.3 [IBM_Accessibility]
  - IBM Accessibility next [IBM_Accessibility_next]
  - WCAG 2.2 (A, AA) [WCAG_2_2]
  - WCAG 2.1 (A, AA) [WCAG_2_1]
  - WCAG 2.0 (A, AA) [WCAG_2_0]

[shunguoy]

@wkeese I just wanted to confirm you used an HTML fragment to test. I did a quick test and I didn't get the error on the element. The results were the same in Chrome, Firefox, and NodeJs. Need more investigation on this.

[philljenkins]

When I run the Chrome and Firefox Checker in the devtools extension, I do not see any errors flagged on the testcase.
@shunguoy @wkeese do you see the same "non errors flagged" when running in Node?
Use testcase.html

Node boilerplate for scanning local files
https://github.com/IBMa/equal-access/tree/master/accessibility-checker/boilerplates/batch-scan

[wkeese]

Guys, I'm not claiming that accessibility-checker fails for every single theoretical test case, I'm saying that it fails for the test case I gave in this ticket description. Was that unclear? Or are just trying to prove that accessibility-checker works in other cases?

Here's another way to reproduce the problem. Follow these instructions exactly and you should see the problem:

git clone [email protected]:wkeese/accessibility-checker-tests.git
cd accessibility-checker-tests
npm install
npx jest label.test.js

@wkeese I just wanted to confirm you used an HTML fragment to test. I did a quick test and I didn't get the error on the element. The results were the same in Chrome, Firefox, and NodeJs. Need more investigation on this.

@shunguoy - The original test was using RTL, but I reduced it to the exact test I wrote in the initial description. Did you try using the exact test case I gave?

When I run the Chrome and Firefox Checker in the devtools extension, I do not see any errors flagged on the testcase.

Yes, that's what I see too. It only fails in Node.

[shunguoy]

@wkeese yes, I used your test case in the Node test and didn't get the same error.

[wkeese]

@shunguoy - Hmm, can you try these commands and post the output here?

git clone [email protected]:wkeese/accessibility-checker-tests.git
cd accessibility-checker-tests
npm install
npx jest label.test.js

[shunguoy]

@wkeese seems I don't have permission to your test repo.

[wkeese]

@shunguoy - Hmm, free github accounts are public by definition, but try this instead to check it out:

git clone https://github.com/wkeese/accessibility-checker-tests.git

[shunguoy]

@wkeese I can duplicate the error using your test package. The only difference to me is that you use Jsdom in your test. I am not sure if that is the cause of the error.

[wkeese]

@wkeese I can duplicate the error using your test package.

Great!

The only difference to me is that you use Jsdom in your test.

I agree, that's a working theory.

I ran a few JSDOM tests like document.querySelector('label[for="myCheckbox"]'), but I didn't see any issues, except for the fact that getComputedStyle() doesn't work on pseudo elements, ex: getComputedStyle(node, "before"). That's why the test converts getComputedStyle(node, "before") to getComputedStyle(node).

Out of curiosity... are you implying that https://github.com/IBMa/equal-access/tree/master/accessibility-checker (aka "Accessibility checker for Node") sometimes uses Puppeteer, and scans for errors using headless Chrome? Or something like that?

In any case, it's supposed to work using standard JSDOM, as shown by https://github.com/IBMa/equal-access/tree/master/accessibility-checker/boilerplates/jest and https://github.com/IBMa/equal-access/tree/master/accessibility-checker/boilerplates/jest-customRS.

[shunguoy]

Our tests focus on Chrome, Firefox, and Edge which most of our customers use. We also use Puppeteer (a sort of embedded Chrome) for automated tests. The browsers do have differences that affect accessibility test results.

[wkeese]

@shunguoy - But I didn't ask about your tests, I asked how https://github.com/IBMa/equal-access/tree/master/accessibility-checker (aka "Accessibility checker for Node") runs internally.

Does https://github.com/IBMa/equal-access/tree/master/accessibility-checker (aka "Accessibility checker for Node") run completely within Node? Or does it sometimes use Puppeteer, and scan for errors using headless Chrome? Or something like that?

[shunguoy]

@wkeese our NodeJS test uses Puppeteer.

[wkeese]

our NodeJS test uses Puppeteer.

Even in this case? If so, something must be getting corrupted in the HTML page sent to Puppeteer.

Also, this problem started recently. It was working on accessibility-checker version 3.1.76 one month ago, but now it fails, both on accessibility-checker 3.1.76 (the same version as before) and 3.1.78. So something changed outside of accessibility-checker, like the ruleset or some other dependency.