559762 - make <input type="date"> and other date controls accessible

Status: RESOLVED DUPLICATE of bug 1676068

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

Should be exposed as ROLE_DATE_EDITOR role. We need to make sure associated calendar widget is accessible as well.

nsIAccessibleValue is not applicable.

Comment 1

[alexander :surkov (:asurkov)]

It's possible to point list of predefined options, should be covered by bug 559766.

Comment 2

[alexander :surkov (:asurkov)]

here's related HTML-AAM issue - https://github.com/w3c/html-aam/issues/49.

Jamie, do you have thoughts on implementation? What relations should be used to connect a textbox and date/time picker?

Comment 3

[alexander :surkov (:asurkov)]

(In reply to alexander :surkov from comment #2)
> here's related HTML-AAM issue - https://github.com/w3c/html-aam/issues/49.
> 
> Jamie, do you have thoughts on implementation? What relations should be used
> to connect a textbox and date/time picker?

should we go with ROLE_DATE_EDITOR for a popup and ControllerFor/ControlledBy relations between a text field and a popup?

Comment 4

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #3)
> should we go with ROLE_DATE_EDITOR for a popup and
> ControllerFor/ControlledBy relations between a text field and a popup?

If we have a text field and a pop-up, I'd say the text field should "control" (aria-controls) the pop-up.

However, I'm a little concerned about this date editor role... and I don't think Gecko *has* a single text field. Right now, it has three spin buttons with a date editor as parent.

The problem with the date editor role is similar to Joanie's concern about the colour picker role. What kind of "editor" is it? It could be just a text box... or it could be a group of spin buttons... or it could be a calendar. The way the user interacts with it is completely implementation dependent. It is just too generic.

With Gecko's current implementation, I'd be inclined to just give the parent a role of grouping. If the pop-up is a calendar, I'd prefer to give it a role of "calendar", but it doesn't seem there is a calendar role in MSAA/IA2. Ug.

Comment 5

[alexander :surkov (:asurkov)]

I have always perceived ROLE_DATE_EDITOR as a special kind of dialogs, same as IA2_ROLE_COLOR_CHOOSER and other CHOOSERs, not sure though if I have good grounds for that.

Do you think we should have ROLE_CALENDAR to make it clear and mark ROLE_DATE_EDITOR as deprecated?

Comment 6

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #5)
> Do you think we should have ROLE_CALENDAR to make it clear and mark
> ROLE_DATE_EDITOR as deprecated?

That depends. If the calendar is a single object (also a single tab stop) with a completely new interaction mechanism, perhaps a calendar role is necessary... but we'd also need to define how the information is exposed. If it's just an existing control or combination of existing controls (e.g. a grid), which I think is far more likely, I'd be inclined to just give the container a role of dialog.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #6)
> (In reply to alexander :surkov from comment #5)
> > Do you think we should have ROLE_CALENDAR to make it clear and mark
> > ROLE_DATE_EDITOR as deprecated?
> 
> That depends. If the calendar is a single object (also a single tab stop)
> with a completely new interaction mechanism, perhaps a calendar role is
> necessary... but we'd also need to define how the information is exposed. If
> it's just an existing control or combination of existing controls (e.g. a
> grid), which I think is far more likely, I'd be inclined to just give the
> container a role of dialog.

Implementations may vary. So Firefox always keep a focus inside a text entry(s) - year, month, day - all are separate - the arrowing change the text entries values. Chrome allows you navigate a calendar itself by arrow keys. In both cases I bet this is a combination of existing controls like grid, buttons, etc. The question is how the AT will determine the user deals with a calendar widget and report that back to the user? Will it be xml-roles or input-type object attributes on HTML:input accessible, or a special role for a dialog itself. Also it might be not allowed by HTML, but from the UI perspective the calendar widget may be used on its own. What widget implementation requirements would be in case, when we don't have calendar role?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:Jamie, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 9

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 10

[James Teh [:Jamie]]

The date input itself has been accessible for a while now. The date picker is being made accessible in bug 1676068.