input type=number does not work (Firefox, IE)

JAWS-test commented 4 years ago

Summary

Go https://codepen.io/jaws-test/pen/WNQgPOe
read with arrow keys
change the value of the first input with arrow keys (in forms mode)
check the element overview with INS+F5

Expected result

output as spinbutton
value change with arrow keys is possible
Buttons for changing the value are not output

Actual result

IE 11: no output as spinbutton. The automatic deletion of incorrect entries is not noticeable with JAWS
Chrome, Firefox, Edge, IE: no output as spinbutton in element overview (INS+F5)
Firefox: value change with arrow keys is not possible, because JAWS does not remain in forms mode. This problem only occurs with JAWS 2019, not with JAWS 2020. The problem does not occur when using role=spinbutton
Firefox: the two buttons for changing values are output as unlabeled buttons (the problem occurs in JAWS 2019 and JAWS 2020)

Additional Information

JAWS version and build number

JAWS 2019.1912.1 JAWS 2020.2003.13

Operating System and version

Windows 10

Browser and version:

current versions of Chrome, Edge, Firefox ESR and IE 11

scottaohara commented 4 years ago

Confirmed: form elements dialog exposes type=number / spinbuttons as "edit" fields. This happens for other text entry fields as well. e.g., type=search / role=searchbox. It would be better if the exact roles were exposed here.

Regarding other assertions:

IE11 doesn't have support for number input, so this is not a valid test.
Arrow key usage with Firefox and JAWS 2020 confirmed as working. So this is resolved.
Unlabelled buttons for native number inputs is not a bug with JAWS. If the native components are not labelled, then JAWS announcing them as having no name is correct. Rather, this is a bug that should be filed with the browser(s).

JAWS-test commented 4 years ago

IE11 doesn't have support for number input, so this is not a valid test.

There is some support: Text entries are rejected. But this is not noticeable with JAWS

scottaohara commented 4 years ago

IE11 exposes a type=number as a standard text field. Browser implementation issues are not JAWS bugs, nor an NVDA bug for that matter.

JAWS-test commented 4 years ago

Arrow key usage with Firefox and JAWS 2020 confirmed as working. So this is resolved.

Does this mean that JAWS 2019 will no longer be supported and reported issues will not be fixed?

JAWS-test commented 4 years ago

IE11 exposes a type=number as a standard text field. Browser implementation issues are not JAWS bugs, nor an NVDA bug for that matter.

This also applies to Firefox, as an examination with F12 or inspect.exe shows. The question is why the input field is output as a spinbutton in Firefox and not in IE 11, although both have the same role (edit) in UIA. The question is also whether JAWS in IE 11 should evaluate the DOM in addition to UIA to output the correct role

scottaohara commented 4 years ago

Does this mean that JAWS 2019 will no longer be supported and reported issues will not be fixed?

New releases of JAWS are where bugs are fixed. The "years" do not represent different products, but are rather part of the version numbering. As one wouldn't look for bugs to be fixed in Firefox 65 when 75 is the current release, one should also not look to JAWS 2019 when 2020+ is the current release.

This also applies to Firefox, as an examination with F12 or inspect.exe shows. The question is why the input field is output as a spinbutton in Firefox and not in IE 11, although both have the same role (edit) in UIA.

Firefox does not use UIA, but rather IA2, and has implemented the mapping for input with type=number. IE11 did not fully implement input type=number, which is why it is only exposed as a standard text edit mapping. In reviewing (again) with inspect and aViewer, Firefox and IE both show the mappings as I've indicated. I can't comment as to why you're seeing something that doesn't match actual implementation. But as far as we should be concerned, this question has been answered sufficiently.

scottaohara commented 4 years ago

@BenKeyFSI could you please file an internal bug regarding the form elements dialog exposes type=number / spinbuttons as "edit" fields. This happens for other text entry fields as well. e.g., type=search / role=searchbox. The actual roles for these controls should be exposed, and not just 'edit'.

thank you

FreedomScientific / standards-support