standards-support
standards-support copied to clipboard
JAWS reads disabled checked checkbox as both unavailable and clearable
Summary
Using the following HTML:
<div tabindex="0">
<input type="checkbox" checked disabled tabindex="-1">
</div>
TAB to the div.
Expected result
The state of the checkbox should be read correctly, "checkbox checked unavailable."
Actual result
JAWS reads, "checkbox checked unavailable, to clear checkmark press spacebar" even though a) pressing the spacebar has no effect on a div, and b) the checkbox is "unavailable" (disabled).
Example
Additional Information
JAWS version and build number
JAWS Version 2022.2207.25
Operating System and version
Windows 10 Pro 19044.1889
Browser and version:
Chrome Version 105.0.5195.102
I see the problem more with JAWS outputting the checkbox when the div gets focus. Also interesting that JAWS always outputs the first control in the div, whether the div has a label or not. If the div contains text, however, the checkbox is not output. In general, though, a div with tabindex and a disabled checkbox in it would not make sense. If a disabled checkbox should get the focus (why actually?), then it should rather be marked with aria-disabled and get the focus directly.
Whether or not it makes sense, it's valid HTML, and this is a minimal reproduction of the issue. I haven't included the full CSS styling, event handlers, etc. that comprise the full implementation of a component that encapsulates this construct.
I could have worked around it using ARIA tags that hide the checkbox and provide my own labels and/or descriptions, and that's probably what I will end up doing. It seemed like a bug to me, so I reported it. If the answer is "don't write HTML that way," then please feel free to close this bug, but seems it like a disservice to the intended user of the product.
@nborko Please open the ticket again. It is of course a bug that needs to be worked on. My comment was not to deny that, but purpose of my comment was just:
- to ask why a disabled checkbox needs to get focus and how this could be done with aria-disabled to work around the bug.
- to state that I think the bug is more extensive because the output when a div element gets focus is very inconsistent (because sometimes the checkbox is not output at all)
It was not actually my intention to close, I hit the wrong button on submission. Sorry about that.
I have added a use case in the code pen where the wrong information also read using only a div with role="checkbox" and aria attributes.
It should be added that the problem also occurs if the checkbox is not checked (aria-checked=false or without checked attribute).
Indeed, the actual state of the checkbox or aria-checked
doesn't matter, it's always read as being "unavailable" but actionable, despite either being disabled
(as in a checkbox) or aria-disabled="true"
(as in a pseudo-control).
The reason an actual checkbox might be encapsulated inside a pseudo-control is that the value is submittable in a <form>
and can be seen in JavaScript as an HTMLInputElement. In the past we have successfully allowed JAWS to read the state of the checkbox without providing any ARIA information on the container, and works fine with other tech, e.g. NVDA. I couldn't say in which version of JAWS it came to be in its current state, as we usually only do re-testing when the source code for a component has changed.