[version numbers]
Steps to reproduce:
# Enter this html into the Omnibox:
data:text/html,
<label id="label" for="input">
Label text
</label>
<p>Very very long,
and even longer,
intervening paragraph.</p>
<input id="input" type="checkbox" checked>
# Go to chrome://accessibility and examine the tree
Expected: label is respected
Actual: It's ignored.
The bug does not reproduce with this HTML and the label is not ignored.
data:text/html,
<label id="label" for="input">
Label text
</label>
<p>Intervening paragraph.</p>
<input id="input" type="text" value="value">
For checkbox or radio, the label is ignored, regardless where it is in the DOM, even miles away from the control.
If you put a text field or any other form control the label is not ignored.
That's inconsistent.
Google Chrome 70.0.3508.0 (Official Build) canary (64-bit) (cohort: Clang-64)
JAWS 2018.1807.8 ILM
Steps to reproduce:
# Enter this html into the Omnibox:
data:text/html,
<label id="label" for="input">
Label text
</label>
<p>Very very long,
and even longer,
intervening paragraph.</p>
<input id="input" type="checkbox" checked>
# Go to chrome://accessibility and examine the tree
Expected: label is respected
Actual: It's ignored.
Verbalization from JAWS on this page:
Very very long, and even longer, intervening paragraph.
Page has no links
Very very long, and even longer, intervening paragraph. Label text
Page has no links
Very very long, and even longer, intervening paragraph.
blank
Label text check box checked
text
__
The bug does not reproduce with this HTML and the label is not ignored.
data:text/html,
<label id="label" for="input">
Label text
</label>
<p>Intervening paragraph.</p>
<input id="input" type="text" value="value">
Verbalization from JAWS on this page:
Label textIntervening paragraph.value
Page has no links
Label textIntervening paragraph.value
Page has no links
Label text
blank
Intervening paragraph.
blank
Edit value
value
For checkbox or radio, the label is ignored, regardless where it is in the DOM, even miles away from the control.
If you put a text field or any other form control the label is not ignored.
That's inconsistent.
Further comments from nektar@
I know the reasoning, Windows screen readers double speaking the label and the name of the control. But that's assuming that both appear on the same line in the virtual buffer. This is not guaranteed. Even with today's state of Jaws and NVDA, say the label is too long, or it has a line break embedded into it.
Aha, now I know why my radio buttons on the survey I sent out had no labels above them.
Comment from dmazzoni@
I think there's a good reason to special-case checkboxes and radio buttons, because they're the only controls that don't have any visible text inside them, so it's far more common for the label to be adjacent to those. Of course there are exceptions, I'm just saying I can see the reasoning.
How about instead as a new heuristic we always ignore a label when it's adjacent to the control it labels (in the sense that there are no other non-ignored accessibility objects in-between the label and the control)?
Comment from nektar@
How about <input type="file"> does that have text inside it?
Comment 1 by leberly@chromium.org
, Jul 31