Input type "number" is not exposed in Acc layer

Input type "number" is not exposed in Acc layer

According to latest editor's draft http://rawgit.com/w3c/html-api-map/master/index.html
input type number should have MSAA+IA2 Role as ROLE_SYSTEM_SPINBUTTON and AXRole as AXIncrementor and AXRoleDescription as "stepper".

This CL depends on https://codereview.chromium.org/718403002/ and https://codereview.chromium.org/718433002/

BUG=385014

[shreeramk, 2014-11-27 05:31:49]

shreeram.k@samsung.com changed reviewers:
+ aboxhall@chromium.org, dmazzoni@chromium.org

[shreeramk, 2014-11-27 05:31:50]

Please review.

Thanks!!

[dmazzoni, 2014-11-27 07:33:41]

The AX trees for input type=number aren't right. Can you check what Firefox
does?

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
File content/test/data/accessibility/input-number-android-expected.txt (right):

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
content/test/data/accessibility/input-number-android-expected.txt:3:
android.widget.EditText editable_text focusable input_type=2
Delete this file, right? I think only input-number-expected-android.txt matters,
not input-number-android-expected.txt

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
File content/test/data/accessibility/input-number-expected-mac.txt (right):

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
content/test/data/accessibility/input-number-expected-mac.txt:4: AXIncrementor
AXRoleDescription='stepper' AXValue='0'
This is really confusing to have an AXIncrementor inside of an AXIncrementor,
and similarly on other platforms.

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
content/test/data/accessibility/input-number-expected-mac.txt:5: AXButton
AXRoleDescription='button'
These buttons probably need labels, like "increment" and "decrement"

[shreeramk, 2014-11-27 07:57:07]

AViewer:

Chrome:

- document
  - body
    - spin box
      - spin box
        - push button
        - push button

Firefox:

- document
    - spin box
      - editable text
      - push button
      - push buttom

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
File content/test/data/accessibility/input-number-android-expected.txt (right):

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
content/test/data/accessibility/input-number-android-expected.txt:3:
android.widget.EditText editable_text focusable input_type=2
On 2014/11/27 07:33:40, dmazzoni wrote:
> Delete this file, right? I think only input-number-expected-android.txt
matters,
> not input-number-android-expected.txt

Sorry about that. I ll delete in next patchset.

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
File content/test/data/accessibility/input-number-expected-mac.txt (right):

https://codereview.chromium.org/738733005/diff/80001/content/test/data/access...
content/test/data/accessibility/input-number-expected-mac.txt:4: AXIncrementor
AXRoleDescription='stepper' AXValue='0'
On 2014/11/27 07:33:41, dmazzoni wrote:
> This is really confusing to have an AXIncrementor inside of an AXIncrementor,
> and similarly on other platforms.

Correct. But may be this is how input type number has been implemented in blink.
I think accessibility can't control that.

[dmazzoni, 2014-11-27 08:13:34]

On Wed, Nov 26, 2014 at 11:57 PM, <shreeram.k@samsung.com> wrote:

> Firefox:
>
> - document
>     - spin box
>       - editable text
>       - push button
>       - push buttom


OK, that makes sense.

https://codereview.chromium.org/738733005/diff/80001/content/test/data/
> accessibility/input-number-expected-mac.txt#newcode4
> content/test/data/accessibility/input-number-expected-mac.txt:4:
> AXIncrementor AXRoleDescription='stepper' AXValue='0'
> On 2014/11/27 07:33:41, dmazzoni wrote:
>
>> This is really confusing to have an AXIncrementor inside of an
>>
> AXIncrementor,
>
>> and similarly on other platforms.
>>
>
> Correct. But may be this is how input type number has been implemented
> in blink. I think accessibility can't control that.
>

We should fix this in Blink accessibility first, before landing this.

I think what's going on here is that there are multiple RenderObjects that
correspond to one Node, and that's why the logic is going wrong. There's a
RenderObject represending the SpinButton as a whole, and it has children
representing the editable text, the increment button, and the decrement
button. However, if you ask the "editable text" RenderObject for its node,
it returns the same HTML element as when you ask the SpinButton
RenderObject. Does that make sense? The code in AXRenderObject.cpp that
currently returns the spin button role needs to distinguish between those.

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

[shreeramk, 2015-01-07 05:22:12]

I got the reason why the child is having spinbuttonrole.

void AXRenderObject::addTextFieldChildren()
{
    Node* node = this->node();
    if (!isHTMLInputElement(node))
        return;

    HTMLInputElement& input = toHTMLInputElement(*node);
    Element* spinButtonElement =
input.userAgentShadowRoot()->getElementById(ShadowElementNames::spinButton());
    if (!spinButtonElement || !spinButtonElement->isSpinButtonElement())
        return;

    AXSpinButton* axSpinButton =
toAXSpinButton(axObjectCache()->getOrCreate(SpinButtonRole));
    axSpinButton->setSpinButtonElement(toSpinButtonElement(spinButtonElement));
    axSpinButton->setParent(this);
    m_children.append(axSpinButton);
}

[dmazzoni, 2015-01-07 19:21:58]

OK, I just checked it out in Safari, and the spec is wrong. Could you file a
spec bug?

On Mac, we should have an AXTextField with a child of AXIncrementor. That's what
Safari does, and it doesn't function if you try to make the text field an
AXIncrementor.

I think we need two (internal) roles - one for the spin control (maps to
ROLE_SYSTEM_SPINBUTTON on Windows and AXTextField on Mac) and one for the spin
button (maps to ROLE_SYSTEM_BUTTON on Windows and AXIncrementor on Mac).

[shreeramk, 2015-01-08 05:40:45]

On 2015/01/07 19:21:58, dmazzoni wrote:
> OK, I just checked it out in Safari, and the spec is wrong. Could you file a
> spec bug?

This is the latest spec http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
where input type number has been mapped with ARIA spinbutton role.
So, I think the latest spec is correct.
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-spinbutton

MSAA+IA2 - ROLE_SYSTEM_SPINBUTTON

AXRole: AXIncrementor
AXSubrole: <nil>
AXRoleDescription: 'stepper'

> On Mac, we should have an AXTextField with a child of AXIncrementor. That's
what
> Safari does, and it doesn't function if you try to make the text field an
> AXIncrementor.

Is below AX tree coming on SAFARI??

AXWebArea AXRoleDescription='HTML content'
    AXGroup AXRoleDescription='group'
        AXIncrementor AXRoleDescription='stepper' AXValue='0'
            AXTextField
                AXButton AXRoleDescription='button'
                AXButton AXRoleDescription='button'

> I think we need two (internal) roles - one for the spin control (maps to
> ROLE_SYSTEM_SPINBUTTON on Windows and AXTextField on Mac) and one for the spin
> button (maps to ROLE_SYSTEM_BUTTON on Windows and AXIncrementor on Mac).

I know spinbuttons, but what is spin control??

[dmazzoni, 2015-01-08 17:15:18]

>
> This is the latest spec http://rawgit.com/w3c/aria/
> master/html-aam/html-aam.html
> where input type number has been mapped with ARIA spinbutton role.
> So, I think the latest spec is correct.
>

No, definitely wrong.

Is below AX tree coming on SAFARI??
>
> AXWebArea AXRoleDescription='HTML content'
>     AXGroup AXRoleDescription='group'
>         AXIncrementor AXRoleDescription='stepper' AXValue='0'
>             AXTextField
>                 AXButton AXRoleDescription='button'
>                 AXButton AXRoleDescription='button'


No, on Safari it looks like this:

AXWebArea AXRoleDescription='HTML content'
>     AXGroup AXRoleDescription='group'
>         AXTextField AXValue='0'

            AXIncrementor AXRoleDescription='stepper'
>                 AXButton AXRoleDescription='button'
>                 AXButton AXRoleDescription='button'



I think we need two (internal) roles - one for the spin control (maps to
>> ROLE_SYSTEM_SPINBUTTON on Windows and AXTextField on Mac) and one for the
>> spin
>> button (maps to ROLE_SYSTEM_BUTTON on Windows and AXIncrementor on Mac).
>>
>
> I know spinbuttons, but what is spin control??


A "spin control" is a combination of a text field plus buttons to increase
or decrease the value. A "spin button" is just the increment/decrement
buttons.




>
>
> https://codereview.chromium.org/738733005/
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
>

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

[shreeramk, 2015-01-08 18:58:49]

> On Mac, we should have an AXTextField with a child of AXIncrementor.

I think I got confused with this statement. I referred it in the opposite sense
because of the word 'of' in above statement.

But, as you said in last comment

> A "spin control" is a combination of a text field plus buttons to increase
> or decrease the value. A "spin button" is just the increment/decrement
> buttons

Then the AX tree/heirarchy would be something like this. Isn't?

spincontrol
  - text field
  - button
  - button

ROLE_SYSTEM_SPIN_BUTTON
    ROLE_SYSTEM_TEXT
    ROLE_SYSTEM_PUSHBUTTON
    ROLE_SYSTEM_PUSHBUTTON



FF follows this(aviewer)

- spin box
      - editable text
      - push button
      - push buttom

[dmazzoni, 2015-01-08 19:18:34]

On Thu, Jan 8, 2015 at 10:58 AM, <shreeram.k@samsung.com> wrote:

> On Mac, we should have an AXTextField with a child of AXIncrementor.
>>
>
> I think I got confused with this statement. I referred it in the opposite
> sense
> because of the word 'of' in above statement.
>

Sorry. To be more clear, what Mac wants is a AXTextField, and that text
field has a child AXIncrementor - not the other way around.

On Mac, an AXIncrementor is just a pair of buttons, it's not a text field.


> But, as you said in last comment
>
>  A "spin control" is a combination of a text field plus buttons to increase
>> or decrease the value. A "spin button" is just the increment/decrement
>> buttons
>>
>
> Then the AX tree/heirarchy would be something like this. Isn't?
>
> spincontrol
>   - text field
>   - button
>   - button
>
> ROLE_SYSTEM_SPIN_BUTTON
>     ROLE_SYSTEM_TEXT
>     ROLE_SYSTEM_PUSHBUTTON
>     ROLE_SYSTEM_PUSHBUTTON
>
>
>
> FF follows this(aviewer)
>
> - spin box
>       - editable text
>       - push button
>       - push buttom


Yes, it's confusing because on Windows, ROLE_SYSTEM_SPINBUTTON is a valid
role for the whole "spin control", but on Mac, there's no equivalent role,
but there's a role of AXIncrementor that refers to just the buttons, not
the whole control.

We could try to do something similar to Firefox, but that'd require Blink
changes too.



>
>
>
> https://codereview.chromium.org/738733005/
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
>

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

[aboxhall, 2017-03-13 05:45:08]

aboxhall@chromium.org changed reviewers:
- aboxhall@chromium.org