Native date field control not understood (Web)

[james2432]

Steps to reproduce:

1. Open firefox
2. Open web page with editable date control (see attached html example)
3. Browse through the table until you land into the native date control
4. Listen to "Clickable ?pastable? button "yyyy", Clickable ?pastable? button "mm", Clickable ?pastable? button "dd"

Please also remember to attach a zip of any files required to reproduce the issue.

Example webpage: datecontrol.txt

Expected behavior:

Says that it's a date control or at least says the aria-label that is assigned to the controk

Actual behavior:

Tells us about the internal buttons and their labels in the date control

System configuration:

NVDA version: windows 2018.1.1

NVDA Installed or portable: Installed

Other information:

Example: Running in a VM

Windows version: Win 7 (v6.1 Build 7601 SP1)

Name and version of other software in use when reproducing the issue: Latest firefox version (60.0.2)

Other questions:

Does the issue still occur after restarting your PC? Yes

[Adriani90]

This is still reproducible I think in NVDA 2019.1.1. cc: @jcsteh

[Adriani90]

@james2432 as far as I understand you want the screen reader to report something like "date control" on the date picker spin button? Actually this is not really needed. The label "day", "month", and "year" already suggest these are date controls and the screen reader user does not have to explicitely hear that these are date picker controls.

Could you please elaborate more on what you exactly expect to hear from NVDA?

[james2432]

The native html5 datepicker should give context to the field?

Like: Date field Year, Month, Day

or something possibly reading the calendar date picker that shows up as well?

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

[Adriani90]

I am ccin @jcsteh, @aleventhal, @dsexton and @SaschaCowley since this issue is broader and affects Firefox and Chromium in different ways. Trying to structure this a bit as follows: For the date field, in focus mode this happens already, NVDA reads "date field for x,y,z" when entering the date field with tab or shift+tab. However, support for input types both in Browse and focus mode need to be completed in NVDA, because NVDA does not announce many of them in browse mode or even in focus mode. This might be one of the reasons why many forms in the wild do not feel fully accessible.

Current status of input types announced by NVDA:

Type	NVDA in Firefox	NVDA in Chromium
Button, checkbox, radio, file, image, reset and submit	announced as expected both in browse and focus mode.	announced as expected both in browse and focus mode.
Email, number, text, password, tel, range, search and URL	no label announced at all in focus and browse mode.	no label announced at all in focus and browse mode.
Color	"color selection" is not announced.	Announces color selection in focus mode only, but role of button is not announced in browse or focus mode.
Date	"date field" announced only in focus mode.	"Date field" announced only in focus mode. In browse mode, no labels are announced at all for the spin buttons.
datetime-local	announced only in focus mode as "date field" instead of expected both focus and browse mode "date and time field".	Announced only in focus mode as "date field" instead of expected both focus and browse mode "date and time field". In browse mode, no labels are announced at all for the spin buttons.
Month and Week	"month field" and "week field" is not announced. Both are announced with an unlabelled edit field role and not as expected spin buttons for "month" and "year" or "week" and "year".	"month field" and "week field" is not announced. In Browse mode, no labels are announced at all for the spin buttons.
Time	"time field" is not announced.	"time field" is not announced. In browse mode, no labels are announced at all for the spin buttons.
Hidden	Is skipped as expected in focus mode, but NVDA announces the URL of the hidden object in browse mode.	Is skipped as expected in focus mode, but NVDA announces the URL of the hidden object in browse mode.

[XLTechie]

@Adriani90 Thank you for this research and very helpful table of status!

What do you think of opening a new summary issue with this list, to make more clear the tracking of all of the solutions needed, and not just the date fields as tracked by this issue?

[jcsteh]

Email, number, text, password, tel, range, search and URL no label announced at all in focus and browse mode.

Can you clarify what you mean by "label" here? If you do: <label>First name: <input type="text"></label> NVDA says: First name: edit has autocomplete as expected.

If you're referring more to the indication of the type, rather than the label, keep in mind that most of these types aren't visually differentiated; e.g. I think email, search, text and url all look the same. The difference is in how they're validated.

NVDA clearly distinguishes password fields by saying "protected".

For number and range, NVDA reports these as spin button and slider, respectively, which is how they appear and behave.

[Adriani90]

NVDA clearly distinguishes password fields by saying "protected". For number and range, NVDA reports these as spin button and slider, respectively, which is how they appear and behave.

I agree, but for an intuitive UX I still think NVDA chould say "password, edit field protected", or "number, spin button" or "range, slider" useful especially for novice computer users or people who are changing from other screen readers to NVDA.

If you're referring more to the indication of the type, rather than the label, keep in mind that most of these types aren't visually differentiated; e.g. I think email, search, text and url all look the same. The difference is in how they're validated.

For Email, number, text, password, tel, range, search and URL I mean the type indication indeed. Although the text input does not need an announcement because NVDA already says "edit field".

According to the following discussion it seems the input types have different CSS properties, depending where they are rendered. Moreover, in Edge and Chrome, it seems the search input type has an x at the end of the edit field indicating that the typed search string can be deleted (e.g. by pressing escape). This is not the case for input type text. https://stackoverflow.com/questions/11589770/input-type-text-vs-input-type-search-in-html5 and https://austingil.com/build-html-forms-right-styling/

Email and text seem to look differently from a visual perspective as well, depending on the form design framework people use: https://contactform7.com/faq/why-does-my-email-address-input-field-look-different/

So I believe web designers have an incentive to include visual differences between the input types, and they do it in practice, even though the visual properties are not fully given by default in HTML5.

[jcsteh]

I agree, but for an intuitive UX I still think NVDA chould say "password, edit field protected", or "number, spin button" or "range, slider"

1. This would be redundant. Protected is only ever used to indicate password fields. A slider is only ever used to indicate a range. You could argue the role descriptions should be changed, although that may confuse existing users. In particular, I don't know of any screen reader that calls a slider a "range". Regardless, saying both doesn't serve any purpose.
2. If we do this only on the web, it would be inconsistent with everything else. For example, the password field in the Windows logon dialog also says "edit protected". The sliders in the Windows volume mixer say "slider". To be consistent, we'd need to change this everywhere. But would you really want to hear "Volume for NVDA application (has UIAccess), range, slider, 22"?

[aleventhal]

Thanks for doing this research. It would be helpful to know the results with JAWS as well. That can be a very good first cut at guessing whether the problem is in NVDA or in the browsers.

[Adriani90]

@jcsteh wrote:

password field in the Windows logon dialog also says "edit protected".

That field has an explicit "pin" or "password" label associated as far as I understand. In case of password input type, Jaws says "edit field for passwords".

my understanding is further that HTML input types like email, password, tel, search and URL do not have an explicit label associated with them by the web author because they have a visual identity given by their style and so the purpose is communicated rather via css or via functionality indicators.

A slider is only ever used to indicate a range. You could argue the role descriptions should be changed, although that may confuse existing users. In particular, I don't know of any screen reader that calls a slider a "range".

After testing with jaws I agree with you on this one, probably for range and number input types a web author would associate a label with them anyway for contextual purposes.

@aleventhal wrote:

It would be helpful to know the results with JAWS as well. That can be a very good first cut at guessing whether the problem is in NVDA or in the browsers.

It is a combination of both I would say. Here are the results with Jaws in Firefox and Chromium:

• Button, checkbox, radio, file, image, reset and submit: works as expected, same as NVDA
• Email, tel, search and URL: same problems as NVDA
• Password: Jaws announces "edit field for passwords" instead of "edit field protected"
• Color: same problems as NVDA, but in Chromium, unlike NVDA, Jaws announces the role of button.
• Date, datetime-local, month, week and time: basically same problems as NVDA, but Jaws is announcing for all these input types "date and time field" when entering the native input fields in focus mode. For example the date input type is announced as "date and time field" in focus mode, same as the week or the month input type.
  • Expected behavior: There should be a difference in announcement when entering a date input vs, week input vs. month input.
  • In browse mode there are the same problems as NVDA.
• Hidden: Jaws does not render the URL of the hidden object in browse mode.

The input types text, number and range are irelevant as per discussion above.

[jcsteh]

password field in the Windows logon dialog also says "edit protected".

That field has an explicit "pin" or "password" label associated as far as I understand.

That can be (and usually is) done on the web as well. That's another problem with the idea you're proposing here: it would result in even more redundancy if the author does provide a label. Also, the same issue exists in native apps: if the author doesn't provide a label, we'll just say "edit protected".

my understanding is further that HTML input types like email, password, tel, search and URL do not have an explicit label associated with them by the web author because they have a visual identity given by their style and so the purpose is communicated rather via css or via functionality indicators.

I'm fairly sure that is a WCAG violation, but I'm not 100% certain. Aside from anything else, an email or tel field doesn't state what email address or telephone number is being requested. That is particularly relevant on a form where there are multiple email or tel fields, but could even be relevant when there is only one. Also, I don't see how even a sighted user could reliably determine an email field purely from styling without some context or prior knowledge. Just because it is styled differently doesn't mean a user immediately knows what it's for.

In any case, both Firefox and Chrome expose the text-input-type object attribute to allow an AT to differentiate between email, search, tel, text, etc. I'm still not convinced NVDA should actually do this, but it's already possible should it be decided it's the right thing to do.