1629078 - label element around input type=time & date = no acc name

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[steve faulkner]

When a label element is wrapped around a labelable element, the labelable elements accessible name should include text within the label element, it does not
for some input elements time/date

example:

<label>
	Label wrapping input
	<input id="input4" type="time">
</label>

In Firefox, this is not the case unlike other browsers.

Note the following for/id method does work:

<label for="input4">
	Label wrapping input
	<input id="input4" type="time">
</label>

test case:
input type=time https://thepaciellogroup.github.io/AT-browser-tests/test-files/input-time.html
input type=date https://thepaciellogroup.github.io/AT-browser-tests/test-files/input-date.html

Comment 1

[Marco Zehe (:MarcoZ)]

Forwarding this NI to Jamie as the module owner for prioritization.

Comment 2

[steve faulkner]

Note that all input types (except hidden) are considered to be labelable elements https://html.spec.whatwg.org/multipage/forms.html#category-label

Comment 3

[steve faulkner]

Also note as per

• https://w3c.github.io/html-aam/#el-input-time expected Object attribute: text-input-type:time not found
• https://w3c.github.io/html-aam/#el-input-date expected Object attribute: text-input-type:date not found

Comment 4

[James Teh [:Jamie]]

I have a patch which exposes the label on the date/time inputs. However, we have another problem with the time input: the label includes the controls inside the time input. For example:

data:text/html,<label>label <input type="time"></label>

With my patch, the name of the time input grouping is "label Hours 50 : Minutes 50 AM/PM --". It should just be "label".

This is due to the change we made in bug 1616851 to ensure descendants of groupings were included when determining the label for another element; e.g. an ancestor list item. Even so, I think this is a bug in eNameIfSubtreeIfReqRule. In this case, we're determining the label for the grouping itself, so it shouldn't include the subtree, even though the label starts from an ancestor. We get the same incorrectness if you do this:

data:text/html,<div id="l">label<div role="group" aria-labelledby="l">abc

I'd expect the label of the grouping to be "label", but it's "label abc".

Comment 5

[James Teh [:Jamie]]

Attachment: Bug 1629078 part 1: For eNameFromSubtreeIfReqRule, don't walk into the descendants of the Accessible for which the text equiv is being calculated.

We already skipped descendants for eNameFromSubtreeIfReqRule when the element wasn't labelled by something else; i.e. when calling GetNameFromSubtree.
However, when such an element is labelled/described by an ancestor, we compute the text equiv for the label using AppendTextEquivFromContent.
Previously, when descending from the ancestor down into the element itself, we would descend into its subtree despite eNameFromSubtreeIfReqRule.
This meant that groupings labelled/described by ancestor would include the content of the grouping itself in its label/description.
This was causing problems for time inputs (once those can accept an ancestor label in the next patch).

Comment 6

[James Teh [:Jamie]]

Attachment: Bug 1629078 part 2: Make date/time inputs labellable by an ancestor HTML label and expose text-input-type attribute.

In order for a form control to be labelled by an ancestor <label>, its Accessible must return true for isWidget().

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/305e91b01211
part 1: For eNameFromSubtreeIfReqRule, don't walk into the descendants of the Accessible for which the text equiv is being calculated. r=MarcoZ
https://hg.mozilla.org/integration/autoland/rev/73607b44ad6b
part 2: Make date/time inputs labellable by an ancestor HTML label and expose text-input-type attribute. r=MarcoZ

Comment 8

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/305e91b01211
https://hg.mozilla.org/mozilla-central/rev/73607b44ad6b

Comment 9

[Marco Zehe (:MarcoZ)]

Verified that this is fixed in Firefox 77.0a1, Build ID 20200423095248.