NVDA reports inputs of type="number" in Firefox as unlabeled in the 'forms' elements list
#9675
Comments
36degrees
changed the title
type="number" as unlabeled in the 'forms' elements listtype="number" in Firefox as unlabeled in the 'forms' elements list
|
I can reproduce this. It's not just a bug in the elements list, but also when the field has focus. In NVDA's object navigation I see the field as a spin button which has an edit field and two buttons inside. Those buttons are unlabeled, but decrease/increase the value. When tabbing to the field NVDA reads the label correctly, since it reads the label of the parent control (the spin button) as well. However, when pressing nvda+tab it just reports the unlabeled edit field. |
|
CC @jcsteh |
36degrees
added a commit
to alphagov/govuk-frontend
that referenced
this issue
Jan 20, 2020
Within the date input component the individual inputs look like this: ``` <input […] type="number" pattern="[0-9]*"> ``` We set the input to `type="number"` so that Android browsers display a numeric keypad keyboard when the input is focussed. iOS uses the full alphanumeric keyboard for `type="number"`, so we add `pattern="[0-9]*"` which triggers the numeric keypad there too [1]. This is technically invalid HTML, as the pattern attribute only applies to inputs of type `text`, `search`, `url`, `tel` and `email` [2], but is not known to cause any real-world issues. However, there are a number of known issues with inputs of `type="number"`: - they silently discard non-numeric input in Chrome [3] (except the letter 'e') - users can accidentally increment or decrement the number using the arrow keys without realising [4] - users can accidentally increment or decrement the number using the scroll wheel on the mouse or the scroll gesture on their trackpad [5] - they appear as unlabeled in NVDA's element list [6] - in NVDA's object navigation they are seen as a spin button which has an edit field and two buttons inside. Those buttons are unlabeled, but decrease/increase the value [7] - when tabbing to the field NVDA using pressing nvda+tab they are reported as unlabeled edit fields [7] - users of Dragon Naturally Speaking cannot dictate into them as expected [8] (Bugs have been filed where appropriate) In testing, using `<input […] type="text" inputmode="numeric" pattern="[0-9]*">` mitigates these issues, with some minor drawbacks: - Between iOS 12.2 and 13.0, the numeric keypad with punctuation is displayed instead of the numeric keypad. Versions prior to 12.2 do not support `inputmode`, thus fallback to the `pattern` attribute, and continue to show the full numeric keypad. iOS 13 updates inputmode="numeric" to use the numeric keypad without punctuation. - Firefox, UC Browser (and older versions of other browsers) on android support neither `inputmode` nor `pattern`, and so will use the full alphanumeric keypad until those browsers introduce support for `inputmode`. (Note: neither Firefox nor UC browser on Android are listed in our own browser support matrix [9] nor the service manual [10]) --- [1]: http://bradfrost.com/blog/post/better-numerical-inputs-for-mobile-forms/ [2]: https://html.spec.whatwg.org/multipage/input.html#input-type-attr-summary [3]: #1449 (comment) [4]: #1449 (comment) [5]: http://bradfrost.com/blog/post/you-probably-dont-need-input-typenumber/ [6]: alphagov/reported-bugs#41 [7]: nvaccess/nvda#9675 (comment) [8]: alphagov/reported-bugs#34 [9]: https://github.com/alphagov/govuk-frontend#browser-and-assistive-technology-support [10]: https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices#browsers-to-test-in Co-authored-by: Colin Oakley <colin@htmlandbacon.com>
36degrees
added a commit
to alphagov/govuk-frontend
that referenced
this issue
Jan 20, 2020
Within the date input component the individual inputs look like this: ``` <input […] type="number" pattern="[0-9]*"> ``` We set the input to `type="number"` so that Android browsers display a numeric keypad keyboard when the input is focussed. iOS uses the full alphanumeric keyboard for `type="number"`, so we add `pattern="[0-9]*"` which triggers the numeric keypad there too [1]. This is technically invalid HTML, as the pattern attribute only applies to inputs of type `text`, `search`, `url`, `tel` and `email` [2], but is not known to cause any real-world issues. However, there are a number of known issues with inputs of `type="number"`: - they silently discard non-numeric input in Chrome [3] (except the letter 'e') - users can accidentally increment or decrement the number using the arrow keys without realising [4] - users can accidentally increment or decrement the number using the scroll wheel on the mouse or the scroll gesture on their trackpad [5] - they appear as unlabeled in NVDA's element list [6] - in NVDA's object navigation they are seen as a spin button which has an edit field and two buttons inside. Those buttons are unlabeled, but decrease/increase the value [7] - when tabbing to the field NVDA using pressing nvda+tab they are reported as unlabeled edit fields [7] - users of Dragon Naturally Speaking cannot dictate into them as expected [8] (Bugs have been filed where appropriate) In testing, using `<input […] type="text" inputmode="numeric" pattern="[0-9]*">` mitigates these issues, with some minor drawbacks: - Between iOS 12.2 and 13.0, the numeric keypad with punctuation is displayed instead of the numeric keypad. Versions prior to 12.2 do not support `inputmode`, thus fallback to the `pattern` attribute, and continue to show the full numeric keypad. iOS 13 updates inputmode="numeric" to use the numeric keypad without punctuation. - Firefox, UC Browser (and older versions of other browsers) on android support neither `inputmode` nor `pattern`, and so will use the full alphanumeric keypad until those browsers introduce support for `inputmode`. (Note: neither Firefox nor UC browser on Android are listed in our own browser support matrix [9] nor the service manual [10]) --- [1]: http://bradfrost.com/blog/post/better-numerical-inputs-for-mobile-forms/ [2]: https://html.spec.whatwg.org/multipage/input.html#input-type-attr-summary [3]: #1449 (comment) [4]: #1449 (comment) [5]: http://bradfrost.com/blog/post/you-probably-dont-need-input-typenumber/ [6]: alphagov/reported-bugs#41 [7]: nvaccess/nvda#9675 (comment) [8]: alphagov/reported-bugs#34 [9]: https://github.com/alphagov/govuk-frontend#browser-and-assistive-technology-support [10]: https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices#browsers-to-test-in Co-authored-by: Colin Oakley <colin@htmlandbacon.com>
|
Can someone test if this is fixed with Firefox 74 ( https://beta.mozilla.org/ ) ? The implementation of |
|
This is definitely fixed as part of https://bugzilla.mozilla.org/show_bug.cgi?id=981248 . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce:
In Firefox, with an HTML document containing the following markup, open the elements list using NVDA + F7 and select the 'Form fields' type.
(View in Codepen)
Actual behavior:
The elements list does not include the text from the label associated with the number field; instead reporting it as 'unlabeled':
Note that the label text is read correctly when the form input is focused.
Expected behavior:
The elements list should include both fields with the text from the associated label:
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2019.1.1
Windows version:
Windows 10; Version 1607; Build 14393. (VirtualBox VM)
Name and version of other software in use when reproducing the issue:
Firefox 67.0.1
Other information about your system:
N/A
Other questions
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
N/A
The text was updated successfully, but these errors were encountered: