Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dragon 13 cannot select or dictate into number fields #34

Open
selfthinker opened this issue Jun 1, 2019 · 3 comments
Open

Dragon 13 cannot select or dictate into number fields #34

selfthinker opened this issue Jun 1, 2019 · 3 comments

Comments

@selfthinker
Copy link

@selfthinker selfthinker commented Jun 1, 2019

Upstream bug: Ref no 170922-000443 (not public!)
Date: 2017-09-20 (?)
Reported by: Anika Henke
Related to: alphagov/govuk-frontend#1101


Overview

The bug report can be accessed with the GDS internal "nuance" google group account and can only be seen when you're logged in with that user.

The content of the bug report is:

You can neither select any number fields (i.e. inputs with the type 'number') nor dictate into them with Dragon 13 in IE 11, or latest Chrome or Firefox.
(The selection obviously works with mouse grid, and the input works with the Dictation Box.)
You can try it out in this reduced test case: http://jsbin.com/munuvub

@selfthinker

This comment has been minimized.

Copy link
Author

@selfthinker selfthinker commented Jun 1, 2019

We only got an automated response from Nuance:

Dear Accessibility Team,

Thank you for providing feedback about your Nuance product.

Your bug report will be reviewed for reproducibility
Bugs reported will be triaged for fixing in a future update or version release of the product
No response will be provided regarding your bug report
If you require a response from Nuance, please open a new question and select a Support category
Support categories include: Error Message, Hardware - Setup/Config, How to use Product, Product - > Problem/Issue, Product - Setup/Config
We appreciate your feedback and help toward improving our products.

Best Regards

Desktop Support & Service
Nuance Communication Inc.

So, it looks like they never give proper feedback to reports and we will never know how and if the status of the report progresses (unless it gets fixed and ends up in their public changelog).

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>
@hannalaakso

This comment has been minimized.

Copy link
Member

@hannalaakso hannalaakso commented Jan 28, 2020

I've just tested this in IE11 and Chrome with Dragon 15 with the reduced test case.

I can replicate the issue in both browsers:

  • IE11: cannot select or dictate number field
  • Chrome 79: can select number field but cannot dictate
@mfairchild365

This comment has been minimized.

Copy link

@mfairchild365 mfairchild365 commented Feb 28, 2020

See also https://a11ysupport.io/tests/tech__html__input__input-number for related test results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.