1950495 - MozCheckbox (<checkbox>) fails AccessibilityUtils.js check on click: Form elements should have a visible text label

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[Rob Wu [:robwu]]

See bug 1940773 for context. Relevant parts are quoted below.

In short, when a test clicks a <checkbox> xul element, AccessibilityUtils.js warns "Form elements should have a visible text label". If <checkbox> is considered sufficiently accessible, then this might be a bug in AccessibilityUtils.js.

Relevant quotes, from https://bugzilla.mozilla.org/show_bug.cgi?id=1940773#c5:

(In reply to Rob Wu [:robwu] from comment #5)

I simulate a checkbox change with checkbox.click() at https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/toolkit/mozapps/extensions/test/browser/browser_permission_prompt_userScripts.js#115-116.
The checkbox is visible, with a label - nothing special: https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/browser/base/content/browser-addons.js#345-351

When a11y checks are enabled, that apparently triggers an error at https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/testing/mochitest/tests/SimpleTest/AccessibilityUtils.js#755. This error is independent of my test.
The error is in an attempt to call SimpleTest.todo, which should have been a non-fatal error. The intended result is to log "Form elements should have a visible text label" at https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/testing/mochitest/tests/SimpleTest/AccessibilityUtils.js#981

Oddly, when I run the test on macOS, I don't get any failures (nor warnings):

./mach test toolkit/mozapps/extensions/test/browser/browser_permission_prompt_userScripts.js --headless --log-mach-verbose --enable-a11y-checks

Relevant analysis (which includes another quote with a description of the involved <checkbox> element):

(In reply to James Teh [:Jamie] from comment #21)

(In reply to Rob Wu [:robwu] from comment #6)

Do you know what is going on here?

• <checkbox> with label created at https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/browser/base/content/browser-addons.js#345-351
• <checkbox> custom element defined at https://searchfox.org/mozilla-central/source/toolkit/content/widgets/checkbox.js
• Checkbox toggled by checkbox.click() at https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/toolkit/mozapps/extensions/test/browser/browser_permission_prompt_userScripts.js#115-116
  For some reason, AccessibilityUtils.js thinks that the checkbox does not have a form label, on Linux only (not on macOS)

Note that a11y-checks jobs only run on CI for Linux. There can also be timing issues with Fluent that cause a11y-checks to not be able to examine the label in time, in which case we will pass silently rather than failing. There's not much we can do about that.

at https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/testing/mochitest/tests/SimpleTest/AccessibilityUtils.js#981.

Looking at this briefly, I think this might be happening because the accessibility engine knows how to get the label text for XUL controls which use label="text", but not the label element itself. The label element possibly isn't even in the accessibility tree because check boxes aren't supposed to have children in accessibility terms. So, I think the fix here will probably be to make an exception to avoid this warning in this case in AccessibilityUtils.

Comment 1

[Mark Striemer [:mstriemer]]

Is there still work to do on the checkbox element side here? Looks like the test is reenabled thanks to changes in AccessibilityUtils.js?

Comment 2

[Rob Wu [:robwu]]

Yes there is still something to do.

The other bug was about a hard test failure due to an error in the AccessibilityUtils.js file. There is an a11ywarn call at https://searchfox.org/mozilla-central/rev/13d864c116029fe5d067d589005f49c1c46f74b5/testing/mochitest/tests/SimpleTest/AccessibilityUtils.js#986

Before the other bug was fixed, that call did not log a warning, but threw an error unexpectedly.

Now that the bug is fixed, that line will display the warning as reported in the summary of this bug, and as expanded in the initial comment.

All relevant information for reproducing the issue along with some analysis is included in the initial comment, please take a look.

Comment 3

[James Teh [:Jamie]]

The fix for the warning might be in AccessibilityUtils rather than the checkbox element itself (yet to be determined for certain), but yes, as Rob noted, there is still work to do here.

Comment 4

[Mark Striemer [:mstriemer]]

Perhaps we can link the label to the checkbox element with ARIA Element Reflection (although we haven't tested this)

Comment 5

[James Teh [:Jamie]]

(In reply to Mark Striemer [:mstriemer] from comment #4)

Perhaps we can link the label to the checkbox element with ARIA Element Reflection (although we haven't tested this)

Unfortunately, that won't work. For a XUL checkbox, the label is a child, but in the accessibility tree, a checkbox isn't allowed to have children. I think the only fix we have is to make an exception for this in AccessibilityUtils.