Open Bug 559762 Opened 10 years ago Updated 9 months ago

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

Categories

(Core :: Disability Access APIs, defect)

defect
Not set

Tracking

()

People

(Reporter: surkov, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: access)

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

nsIAccessibleValue is not applicable.
It's possible to point list of predefined options, should be covered by bug 559766.
Depends on: 559766
Depends on: 825294
Blocks: 956711
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?
(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?
Flags: needinfo?(jteh)
(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.
Flags: needinfo?(jteh)
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?
(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.
(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?
Blocks: 1507732
You need to log in before you can comment on or make changes to this bug.