NVDA reports inputs of type="number" as unlabeled in the 'forms' elements list
#41
Labels
Projects
Comments
2 tasks
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>
|
It looks like this issue is fixed as of Firefox 74, according to nvaccess/nvda#9675 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Upstream bug: nvaccess/nvda#9675
Date: 2019-06-05
Reported by: Oliver Byford
Related to: alphagov/govuk-frontend#1408
Steps to reproduce:
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':
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: