[Gtk] accessibility/canvas-description-and-role expected results needed

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Joanmarie Diggs]

A new CanvasRole was added to the accessibility code so we have a new layout test in need of expected results.

The thing is, I don't see why the decision was made to not map CanvasRole to ATK_ROLE_CANVAS. I think the mapping is wrong, thus the expected results which will get generated will also be wrong.

Filing this in Tools / Tests largely as a heads-up to gardeners. I'll attach a patch which addresses both issues and leave it to someone else to decide how to proceed with the lack of results.

[Joanmarie Diggs]

Created attachment 161826 [details]
Patch

[Joanmarie Diggs]

Dominic, adding you to the CC here to comment in case CanvasRole really should not be mapped to ATK_ROLE_CANVAS. Thanks!

[Martin Robinson]

Comment on attachment 161826 [details]
Patch

Are the results here the same as for other platforms, thus allowing them to be shared and placed by placing them in a platform-independent results directory?

[Joanmarie Diggs]

They're quite close, but not exact (pasted below for your convenience).

These differences result from two things:
1. Different ports have different output "just 'cuz" (AXCanvas versus canvas).
2. Different ports have different roles.

The former we should try to resolve (though that is a bug bigger than what I have filed here). The latter is a bit tougher. Especially when in certain cases what is being tested requires more of the accessible hierarchy than this particular example because those hierarchies tend to diverge pretty quickly amongst ports.

Mac:
        PASS axContainer.childrenCount is 2
        Canvas 1 description: AXDescription: Canvas label
    --> Canvas 1 role: AXRole: AXImage
        Canvas 2 description: AXDescription:
    --> Canvas 2 role: AXRole: AXGroup

Win: 
        FAIL axContainer.childrenCount should be 2. Was 3.
        Canvas 1 description: Description: Canvas label
    --> Canvas 1 role: graphic
        Canvas 2 description:
    --> Canvas 2 role: graphic

Chromium:
        PASS axContainer.childrenCount is 2
        Canvas 1 description: AXDescription: Canvas label
    --> Canvas 1 role: AXRole: AXCanvas
        Canvas 2 description: AXDescription:
    --> Canvas 2 role: AXRole: AXCanvas

Gtk (Proposed):
        PASS axContainer.childrenCount is 2
        Canvas 1 description: AXDescription: Canvas label
    --> Canvas 1 role: AXRole: canvas
        Canvas 2 description: AXDescription: 
    --> Canvas 2 role: AXRole: canvas

[Alejandro Piñeiro]

(In reply to comment #0)
> A new CanvasRole was added to the accessibility code so we have a new layout test in need of expected results.
> 
> The thing is, I don't see why the decision was made to not map CanvasRole to ATK_ROLE_CANVAS. I think the mapping is wrong, thus the expected results which will get generated will also be wrong.

FWIW, I also think that the current WebCore CanvasRole to ATK ATK_ROLE_IMAGE mappping is wrong. ATK_ROLE_CANVAS is the proper mapping.

[Dominic Mazzoni]

Hi -

I'm sorry for not just mapping to ATK_ROLE_CANVAS right away. I didn't know how that might affect Orca, so I tried to just keep the same behavior as before with ATK, rather than make assumptions.

The only potential reason to not always map to ATK_ROLE_CANVAS is if you think it'd make sense to distinguish between an interactive canvas and a static one.

For example:

1. <canvas alt="User image icon" width=100 height=100></canvas>

2. <canvas width=100 height=100 id="monkey_spinner_widget">
     <label>
       Number of flying monkeys
       <input type="range" min=0 max=100>
     </label>
   </canvas>

In the first case, it might make more sense to use ATK_ROLE_IMAGE since the canvas is just static content, and conceptually it's just an image. In the second case, from an accessibility perspective the canvas element is just a container for an interactive widget. It's not conceptually a "graphic" anymore, the canvas element is just a container for interactive content - and the fact that it's displayed in a graphical canvas is only of secondary importance to a screen reader user.

[Joanmarie Diggs]

(In reply to comment #6)
 
> The only potential reason to not always map to ATK_ROLE_CANVAS is if you think it'd make sense to distinguish between an interactive canvas and a static one.
> 
> For example:
> 
> 1. <canvas alt="User image icon" width=100 height=100></canvas>
> 
> 2. <canvas width=100 height=100 id="monkey_spinner_widget">
>      <label>
>        Number of flying monkeys
>        <input type="range" min=0 max=100>
>      </label>
>    </canvas>

The second case is awesome btw. :)

And I do see your point. But in that case it's not really a platform thing, is it? In other words, case 1 is a static image for all users of all platforms. Thus perhaps in that instance, WebCore a11y should determine that it is ImageRole rather than CanvasRole and only declare CanvasRole for those objects which are functionally canvas.

Thoughts?

[Dominic Mazzoni]

(In reply to comment #7)
> And I do see your point. But in that case it's not really a platform thing, is it? In other words, case 1 is a static image for all users of all platforms. Thus perhaps in that instance, WebCore a11y should determine that it is ImageRole rather than CanvasRole and only declare CanvasRole for those objects which are functionally canvas.

I don't have strong feelings either way, but you could argue that approach would "lose information" - if a platform didn't want a static canvas to be an ImageRole, it wouldn't have a way to do that.

I just felt it was the most clear for WebCore to always call a canvas a canvas - but provide platforms with enough information to distinguish between static and dynamic canvases *if they want*.

[Joanmarie Diggs]

(In reply to comment #8)

> I just felt it was the most clear for WebCore to always call a canvas a canvas - but provide platforms with enough information to distinguish between static and dynamic canvases *if they want*.

Gotcha. Sounds good to me.

Martin (or anyone else with reviewer status): Please review so that Gtk maps a WebCore accessible CanvasRole to ATK_ROLE_CANVAS and that we also have expected test results. Thanks!

[Zan Dobersek]

*** Bug 95825 has been marked as a duplicate of this bug. ***

[WebKit Review Bot]

Comment on attachment 161826 [details]
Patch

Clearing flags on attachment: 161826

Committed r127825: <http://trac.webkit.org/changeset/127825>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.