Handles conversion rule for TimeRole and updates InputTimeRole.

Handles conversion rule for TimeRole and updates InputTimeRole.

This patch replaces WebAXRoleTime with WebAXInputRoleTime to handle for
input element with time type and uses WebAXRoleTime for Time element.
It's mapped to ROLE_SYSTEM_TEXT, IA2_ROLE_TEXT_FRAME and
NSAccessibilityGroupRole as described from
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-time.

It also updates the role for Input Time type with ROLE_SYSTEM_GROUPING.

BUG=480861
Committed: https://crrev.com/a84659a4eafb7b548f47aac86f7d6c7dd0e05cdb
Cr-Commit-Position: refs/heads/master@{#331509}

[dmazzoni, 2015-05-10 06:33:07]

dmazzoni@chromium.org changed reviewers:
+ dmazzoni@chromium.org

[dmazzoni, 2015-05-10 06:33:07]

https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
content/browser/accessibility/browser_accessibility_win.cc:4074: ia_role =
ROLE_SYSTEM_SPINBUTTON;
This probably isn't right anymore. Back when I added it, <input type=time> was a
standard text field with s spinner, but now that element is just a wrapper for
several other elements. It should probably be a grouping element, or maybe
something like IA2_ROLE_DATE_EDITOR.

[je_julie(Not used), 2015-05-21 02:25:17]

Hi Dominic, PTAL.

https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
content/browser/accessibility/browser_accessibility_win.cc:4074: ia_role =
ROLE_SYSTEM_SPINBUTTON;
On 2015/05/10 06:33:07, dmazzoni wrote:
> This probably isn't right anymore. Back when I added it, <input type=time> was
a
> standard text field with s spinner, but now that element is just a wrapper for
> several other elements. It should probably be a grouping element, or maybe
> something like IA2_ROLE_DATE_EDITOR.

Thanks for your comment.
I found it's mapped to ROLE_SYSTEM_SPINBUTTON from
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-input-time
So, I think we'd better follow what spec says. WDTY?

[dmazzoni, 2015-05-21 17:11:25]

On 2015/05/21 02:25:17, je_julie wrote:
> Hi Dominic, PTAL.
> 
>
https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
> File content/browser/accessibility/browser_accessibility_win.cc (right):
> 
>
https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
> content/browser/accessibility/browser_accessibility_win.cc:4074: ia_role =
> ROLE_SYSTEM_SPINBUTTON;
> On 2015/05/10 06:33:07, dmazzoni wrote:
> > This probably isn't right anymore. Back when I added it, <input type=time>
was
> a
> > standard text field with s spinner, but now that element is just a wrapper
for
> > several other elements. It should probably be a grouping element, or maybe
> > something like IA2_ROLE_DATE_EDITOR.
> 
> Thanks for your comment.
> I found it's mapped to ROLE_SYSTEM_SPINBUTTON from
> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-input-time
> So, I think we'd better follow what spec says. WDTY?

The problem here is that the HTML spec doesn't say exactly how the browser is
supposed to implement a time control. For example, on some Android versions it's
a pushbutton with a drop-down arrow, and when you tap on it, it brings up a
dialog that looks like a circular clock.

I don't think the accessibility spec should mandate ROLE_SYSTEM_SPINBUTTON and
we should file a bug against the spec asking them to change it.

The most important issue is that it has to work for users.

Try this: create a webpage with <input type="time"> in it, then open Chrome
Developer Tools. Click on the "Settings" button (Gear icon), then check the box
labeled "Show user agent shadow DOM". Now inspect the time control and you'll
see something like this:

<input type="time">
  #shadow-root (user-agent)
    <div pseudo="-webkit-datetime-edit" id="date-time-edit" datetimeformat="h:mm
a">
      <div pseudo="-webkit-datetime-edit-fields-wrapper">
        <span role="spinbutton" aria-valuetext="11" aria-valuemin="1"
aria-valuemax="12" aria-help="Hours" pseudo="-webkit-datetime-edit-hour-field"
aria-valuenow="11">11</span>
        <div pseudo="-webkit-datetime-edit-text">:</div>
        <span role="spinbutton" aria-valuetext="59" aria-valuemin="0"
aria-valuemax="59" aria-help="Minutes"
pseudo="-webkit-datetime-edit-minute-field" aria-valuenow="59">59</span>
        <div pseudo="-webkit-datetime-edit-text"> </div>
        <span role="spinbutton" aria-valuetext="AM" aria-valuemin="1"
aria-valuemax="2" aria-help="AM/PM" pseudo="-webkit-datetime-edit-ampm-field"
aria-valuenow="1">AM</span>
      </div>
    </div>
    <div pseudo="-webkit-clear-button" id="clear" style=""></div>
    <div pseudo="-webkit-inner-spin-button" id="spin"></div>    

This is what's actually seen in the layout tree and accessibility tree. Though
the web author only added one DOM element to the page, we actually end up with 4
separate controls:

* An hour picker (spin button)
* A minute picker (spin button)
* An AM / PM picker (spin button)
* A clear button (button, not currently accessible but probably should be)

From the point of view of assistive technology, there should be four separate
controls on the page. They're all related and they're all grouped, but they're
separate.

Mapping <input type=time> to ROLE_SYSTEM_SPINBUTTON basically says that the root
of this subtree of elements should be a spin button - but it's not. It's a
wrapper that has other elements inside.

Does this make sense?

Now, the slightly trickier part is that the exact format of the time control is
a bit different depending on your operating system and your locale - for example
it can be 24-hour time instead of AM/PM. I think that's the reason we don't have
a test for this, because the test needs to handle those different
configurations.

[je_julie(Not used), 2015-05-22 05:08:18]

On 2015/05/21 17:11:25, dmazzoni wrote:
> On 2015/05/21 02:25:17, je_julie wrote:
> > Hi Dominic, PTAL.
> > 
> >
>
https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
> > File content/browser/accessibility/browser_accessibility_win.cc (right):
> > 
> >
>
https://codereview.chromium.org/1132963002/diff/1/content/browser/accessibili...
> > content/browser/accessibility/browser_accessibility_win.cc:4074: ia_role =
> > ROLE_SYSTEM_SPINBUTTON;
> > On 2015/05/10 06:33:07, dmazzoni wrote:
> > > This probably isn't right anymore. Back when I added it, <input type=time>
> was
> > a
> > > standard text field with s spinner, but now that element is just a wrapper
> for
> > > several other elements. It should probably be a grouping element, or maybe
> > > something like IA2_ROLE_DATE_EDITOR.
> > 
> > Thanks for your comment.
> > I found it's mapped to ROLE_SYSTEM_SPINBUTTON from
> > http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-input-time
> > So, I think we'd better follow what spec says. WDTY?
> 
> The problem here is that the HTML spec doesn't say exactly how the browser is
> supposed to implement a time control. For example, on some Android versions
it's
> a pushbutton with a drop-down arrow, and when you tap on it, it brings up a
> dialog that looks like a circular clock.
> 
> I don't think the accessibility spec should mandate ROLE_SYSTEM_SPINBUTTON and
> we should file a bug against the spec asking them to change it.
Can I file a bug for this at w3c bugzilla,
if you don't have other plan to discuss it on w3c?

> The most important issue is that it has to work for users.
> 
> Try this: create a webpage with <input type="time"> in it, then open Chrome
> Developer Tools. Click on the "Settings" button (Gear icon), then check the
box
> labeled "Show user agent shadow DOM". Now inspect the time control and you'll
> see something like this:
> 
> <input type="time">
>   #shadow-root (user-agent)
>     <div pseudo="-webkit-datetime-edit" id="date-time-edit"
datetimeformat="h:mm
> a">
>       <div pseudo="-webkit-datetime-edit-fields-wrapper">
>         <span role="spinbutton" aria-valuetext="11" aria-valuemin="1"
> aria-valuemax="12" aria-help="Hours" pseudo="-webkit-datetime-edit-hour-field"
> aria-valuenow="11">11</span>
>         <div pseudo="-webkit-datetime-edit-text">:</div>
>         <span role="spinbutton" aria-valuetext="59" aria-valuemin="0"
> aria-valuemax="59" aria-help="Minutes"
> pseudo="-webkit-datetime-edit-minute-field" aria-valuenow="59">59</span>
>         <div pseudo="-webkit-datetime-edit-text"> </div>
>         <span role="spinbutton" aria-valuetext="AM" aria-valuemin="1"
> aria-valuemax="2" aria-help="AM/PM" pseudo="-webkit-datetime-edit-ampm-field"
> aria-valuenow="1">AM</span>
>       </div>
>     </div>
>     <div pseudo="-webkit-clear-button" id="clear" style=""></div>
>     <div pseudo="-webkit-inner-spin-button" id="spin"></div>    
> 
> This is what's actually seen in the layout tree and accessibility tree. Though
> the web author only added one DOM element to the page, we actually end up with
4
> separate controls:
> 
> * An hour picker (spin button)
> * A minute picker (spin button)
> * An AM / PM picker (spin button)
> * A clear button (button, not currently accessible but probably should be)
> 
> From the point of view of assistive technology, there should be four separate
> controls on the page. They're all related and they're all grouped, but they're
> separate.
> 
> Mapping <input type=time> to ROLE_SYSTEM_SPINBUTTON basically says that the
root
> of this subtree of elements should be a spin button - but it's not. It's a
> wrapper that has other elements inside.
> 
> Does this make sense?
> 
Thanks a lot for enlightening me! I totally agree with you.
Generally I think it's fit to group role but IA2_ROLE_DATE_EDITOR is also good
for Input-time.
As considering it is an Input tag, I think IA2_ROLE_DATE_EDITOR is more proper.
However, after I look into the links below at mozilla,
https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/IA2/Roles,
https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/Gecko/Role...,
I can't not say that we have to choose IA2_ROLE_DATE_EDITOR
becuase UA: NSAccessibilityUnknownRole doesn't seem proper.
Or, we could choose the mixed one like IA2: IA2_ROLE_DATE_EDITOR and UA:
NSAccessibilityGroupRole.
I have no strong opinion for that. Which one do you prefer?

> Now, the slightly trickier part is that the exact format of the time control
is
> a bit different depending on your operating system and your locale - for
example
> it can be 24-hour time instead of AM/PM. I think that's the reason we don't
have
> a test for this, because the test needs to handle those different
> configurations.
You're right. I understand.

[dmazzoni, 2015-05-22 21:42:41]

On Thu, May 21, 2015 at 10:08 PM, <je_julie.kim@samsung.com> wrote:

> Can I file a bug for this at w3c bugzilla,
> if you don't have other plan to discuss it on w3c?


Yes, that would be great, thanks!

Does this make sense?
>>
>
> Thanks a lot for enlightening me! I totally agree with you.
> Generally I think it's fit to group role but IA2_ROLE_DATE_EDITOR is also
> good
> for Input-time.
> As considering it is an Input tag, I think IA2_ROLE_DATE_EDITOR is more
> proper.
> However, after I look into the links below at mozilla,
>
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/IA2/Roles
> ,
>
>
https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/Gecko/Role...
> ,
> I can't not say that we have to choose IA2_ROLE_DATE_EDITOR
> becuase UA: NSAccessibilityUnknownRole doesn't seem proper.
>

That seems okay. That documentation says that internally Mozilla has a role
called "date editor", and they map it to IA2_ROLE_DATE_EDITOR  on Windows,
but nothing on Mac. Note that Mozilla's Windows accessibility support is
ahead of Chrome (though not necessarily for input type=time), but they're
behind on Mac, Firefox doesn't work well with VoiceOver yet - so I wouldn't
trust their Mac role mappings but I would trust their Windows mappings most
of the time.

Or, we could choose the mixed one like IA2: IA2_ROLE_DATE_EDITOR and UA:
> NSAccessibilityGroupRole.
>

Yes, I like mapping it to IA2_ROLE_DATE_EDITOR on Windows and
NSAccessibilityGroupRole on Mac.

Now, the slightly trickier part is that the exact format of the time control
>>
> is
>
>> a bit different depending on your operating system and your locale - for
>>
> example
>
>> it can be 24-hour time instead of AM/PM. I think that's the reason we
>> don't
>>
> have
>
>> a test for this, because the test needs to handle those different
>> configurations.
>>
> You're right. I understand.


It would be great if you'd like to try to write a test for this. Maybe we
could write the test but then just exclude it on some platforms or force
the locale to be U.S. English, or something like that. I don't remember the
exact issue but I seem to recall that the test failed on Windows 8 trybots
for some reason. Maybe the default locale for Windows 8 is slightly
different, or maybe it was a coincidence.

Not a huge priority, but it would be great if you want to try to figure
that out.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[je_julie(Not used), 2015-05-26 15:26:04]

Hi Dominic,
I updated role mapping according to the updated spec.

On 2015/05/22 21:42:41, dmazzoni wrote:
> On Thu, May 21, 2015 at 10:08 PM, <mailto:je_julie.kim@samsung.com> wrote:
> 
> Yes, I like mapping it to IA2_ROLE_DATE_EDITOR on Windows and
> NSAccessibilityGroupRole on Mac.
After I filed a bug on W3C, Role mapping for Input Time type is with Grouping
role.
So, I follows the current updated version.
For Windows, ROLE_SYSTEM_GROUPING will be assigned to Input Time Type.
For Mac, AXTimeField will be assigned.
 
> It would be great if you'd like to try to write a test for this. Maybe we
> could write the test but then just exclude it on some platforms or force
> the locale to be U.S. English, or something like that. I don't remember the
> exact issue but I seem to recall that the test failed on Windows 8 trybots
> for some reason. Maybe the default locale for Windows 8 is slightly
> different, or maybe it was a coincidence.
> 
> Not a huge priority, but it would be great if you want to try to figure
> that out.
Please let me look into it.

[dmazzoni, 2015-05-26 15:30:47]

lgtm

[je_julie(Not used), 2015-05-26 23:20:51]

The CQ bit was checked by je_julie.kim@samsung.com

[commit-bot: I haz the power, 2015-05-26 23:21:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1132963002/40001

[commit-bot: I haz the power, 2015-05-27 01:34:52]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-05-27 01:35:48]

Patchset 3 (id:??) landed as
https://crrev.com/a84659a4eafb7b548f47aac86f7d6c7dd0e05cdb
Cr-Commit-Position: refs/heads/master@{#331509}