NVDA should more accurately report the types of form fields

[tiago-casal]

Is your feature request related to a problem? Please describe.

There are form fields that NVDA still doesn't report the type correctly (at least until the stable version at the time this case is being published, 2021.3.1), reporting the field type correctly minimizes the user's chance of incorrectly filling forms in webpages, especially forms with unlabeled fields.

List of 5 fields that NVDA does not identify well in all web browsers:

• \<input type\=\"search\">
• \<input type\=\"tel\">
• \<input type\=\"email\">
• \<input type\=\"url\">
• There is the type of natural submit button that is well identified, the other type, image, that serves to submit and that has an associated image could perhaps be reported as \"submit graphic button\": \<input type\=\"image\">

Particular situations in each browser:

• Chrome version 98 and Edge version 98, in addition to the observations previously placed that apply to them, have a good behavior in other fields not mentioned so far;
• In Firefox version 97, the two fields, \<input type\=\"month\"> and \<input type\=\"week\"> aren't correctly identified, NVDA treats them as an edit field, in addition to them the \<input type\=\"color\"> field isn't correctly identified, being called button only;
• In Firefox ESR version 91, also the three fields mentioned above have the same behavior and the \<input type\=\"datetime-local\"> field isn't correctly identified, NVDA treats it as an edit field;
• In Internet Explorer 11 it is worse, the four fields mentioned above have practically the same behavior (exception is the color field which is treated as an edit field instead of a button), in it three more are added to the list of those treated as a edit field, \<input type\=\"date\">, \<input type\=\"time\"> and \<input type\=\"number\">.

Here's a link to a page containing a test form with the mentioned fields (the form's language is set to Brazilian Portuguese): https://codepen.io/reinaldoferraz/full/rNywYyy

Note 1: On the indicated webpage, the search field is not genuine, it is \<input type\=\"search\" role\=\"search\">, because of role\=\"search\" it is not possible to test such field, in Browse mode using up/down arrows the field is not identified, without role\=\"search\" it would be identified as an edit field;

Note 2: On the indicated webpage, the \<input type\=\"image\"> field in Internet Explorer is identified as an unavailable button, it may be something related only to IE.

Describe the solution you'd like

It would be interesting if the field types are reported more appropriately (here are some suggestions until better ones be contributed):

• type\=\"search\" be reported as \"search box edit\" or \"search edit\";
• type\=\"tel\" be reported as \"telephone edit\";
• type\=\"email\" be reported as \"e-mail address edit\" or \"e-mail edit\";
• type\=\"url\" be reported as \"URL address edit\" or \"URL edit\";
• type\=\"image\" be reported as \"submit graphic button\";
• And that the conditions of the other fields if not specific problem of Firefox are improved in NVDA: type\=\"month\", type\=\"week\", type\=\"color\" and type\=\"datetime-local\".

Describe alternatives you've considered

The Narrator screen reader in Windows 10 21H2 in web browsers has the same behavior as NVDA, worse in the password field because it does not inform that it is a password or protected field, while in the Edge browser Narrator has a better behavior than NVDA identifying the search field (he calls it the search box), only in Edge does Narrator also identify 3 more fields that NVDA doesn't identify, tel, email and url.

Additional context

This type of problem was raised by a Brazilian in an article comparing the behavior of some screen readers in web forms, published in May 2021, link to more information in Brazilian Portuguese: https://reinaldoferraz.com.br/como-leitores-de-tela-interpretam-os-tipos-de-campos-de-formulario/

[Adriani90]

Thank you very much for this good analysis and your tests. I think this might be interesting for some developers here to have a look into. I can still reproduce the same issues in NVDA 2022.4, Firefox 109, Chrome 110 and Edge 110. However, in Edge 110 it seems some of the fields are not included in the tab order when using focus mode.

I guess this is very related to the browser itself. For example edge included all the date pickers in the tab order in version 109, but not so in version 110.

I think many web developers might be tempted to use these types instead of labeling their fields manually. I can see the efficiency point behind this. However, NVDA does not report most of the types in browse mode, so it seems none of the browsers pass this to the virtual buffer. It works only in focus mode.

But in practice I see more often websites that have such form field types implemented.

Is it possible to add these to NVDA's virtual document as well?

cc: @michaelDCurran, @jcsteh, @aleventhal, @ObjectInSpace,

[jcsteh]

IMO, it's unclear as to whether this would add value. It is an accessibility requirement that fields are labelled regardless of their types. As I understand it, there's no visual distinction between these controls either, with the exception of password fields where the characters are masked, which NVDA reports as protected. Much of the benefit of these different types is to provide automatic input validation, rather than them being fundamentally different semantically.

Firefox does expose this information via the text-input-type object attribute, so if it was decided that NVDA should report this, it's already possible to implement it for Firefox.

[tiago-casal]

Hello! @Adriani90, thank you very much for verifying the issue! @jcsteh, the implementation would be useful especially when we users are in poorly made forms, without good labels in the fields, knowing their role helps us to infer what to type.

[jcsteh]

If the forms are poorly authored such that they aren't labelled, it's unlikely that the type information will be any better. That is, poor authoring in one area is very likely to be correlated with poor authoring in other areas.

[tiago-casal]

Hello @jcsteh, you are right; thanks! There are situations that are not so extreme but that additional information would help: forms in which the fields are not labeled in the correct way, having texts that should be as field labels but are not and are loose, and when in the same form these texts sometimes appear in a position (for example, before the field) sometimes in another position (after the field) it is very easy for the user to type in the wrong field, in this type of situation filling in using a smartphone is less bad, because indirectly it is possible to know some types of fields, when it is e-mail field the atsign on some keyboards appears next to the space bar and when the field is common the atsign does not appear, when it is only numeric field, the keyboard changes to numbers only, etc. Ideally, NVDA should speak all types of fields and controls on a form, even better if this was available as an optional function in the settings, the person would enable it when needed.