Bug 79095 – HTML5 input type="number" role mapping incorrect

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Accessibility

[Steve Faulkner]

The HTML5 input type="number" currently is mapped to AXTextField. As it is implemented in webkit as an Incrementor control it is suggested that the accessibility mapping should be:

AXRole:  "AXIncrementor"
 AXSubrole:  "AXTextField"
 AXRoleDescription:  "stepper text field"

The above is suggested as the primary method to interact with the control for keyboard users is via the up/down arrow keys (as it is a stepper control), but it also allows free text entry.

[chris fleizach]

The main role is a text field because you can type into it. 

An AXIncrementor is only used for the tiny little buttons that do the stepping. 

The roles are a very defined set because VoiceOver would not be able to recognize or handle the elements correctly without customization to handle those roles. So changing the roles doesn't work.

Potentially we could change the role description, but I'd rather let VoiceOver decide how it wants to output this element, which it can do by observing there is a stepper inside the text field

[Steve Faulkner]

(In reply to comment #1)
> The main role is a text field because you can type into it. 
> 
> An AXIncrementor is only used for the tiny little buttons that do the stepping. 
> 
> The roles are a very defined set because VoiceOver would not be able to recognize or handle the elements correctly without customization to handle those roles. So changing the roles doesn't work.
> 
> Potentially we could change the role description, but I'd rather let VoiceOver decide how it wants to output this element, which it can do by observing there is a stepper inside the text field

thanks for the explanation, I did notice that the incrementor buttons are mapped with the incrementor role and associated actions, but found that VoiceOver didn't pick this up.

It would also appear that the while you can type into the field it has a defined set of values that are selectable by using the stepper interaction.

As the ARIA spinbutton role is often added to an input type=text (example http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html)Is this going to be a problem for VoiceOver as you indicate above?

On a related bug https://bugs.webkit.org/show_bug.cgi?id=77298 the ARIA spinbutton role is currently mapped to 'progress indicator'

[chris fleizach]

(In reply to comment #2)
> (In reply to comment #1)
> > The main role is a text field because you can type into it. 
> > 
> > An AXIncrementor is only used for the tiny little buttons that do the stepping. 
> > 
> > The roles are a very defined set because VoiceOver would not be able to recognize or handle the elements correctly without customization to handle those roles. So changing the roles doesn't work.
> > 
> > Potentially we could change the role description, but I'd rather let VoiceOver decide how it wants to output this element, which it can do by observing there is a stepper inside the text field
> 
> thanks for the explanation, I did notice that the incrementor buttons are mapped with the incrementor role and associated actions, but found that VoiceOver didn't pick this up.
> 

VoiceOver needs to be updated to account for this new paradigm, which does not exist in OSX in any other form.

> It would also appear that the while you can type into the field it has a defined set of values that are selectable by using the stepper interaction.
> 
> As the ARIA spinbutton role is often added to an input type=text (example http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html)Is this going to be a problem for VoiceOver as you indicate above?
> 

If that's done, then the element won't appear as a textfield, but since it responds to keyboard commands and other things, it shouldn't in the end matter as much. I think it's something we'll need to test in VoiceOver as well.

> On a related bug https://bugs.webkit.org/show_bug.cgi?id=77298 the ARIA spinbutton role is currently mapped to 'progress indicator'

Yes aware of that issue as well. need to fix