Closed Bug 1629078 Opened 2 months ago Closed 1 month ago

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

Categories

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

76 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla77
Tracking Status
firefox77 --- verified

People

(Reporter: faulkner.steve, Assigned: Jamie)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

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

Flags: needinfo?(mzehe)

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

Flags: needinfo?(mzehe) → needinfo?(jteh)

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

Also note as per

Component: Disability Access → Disability Access APIs
Flags: needinfo?(jteh)
Priority: -- → P1
Product: Firefox → Core

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".

Assignee: nobody → jteh

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).

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

Attachment #9142592 - Attachment description: Bug 1629078 part 2: Make IsWidget() return true for date and time inputs. → Bug 1629078 part 2: Make date/time inputs labellable by an ancestor HTML label and expose text-input-type attribute.
Pushed by mzehe@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

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

Status: RESOLVED → VERIFIED
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.