Bug 95644

Created attachment 161826 [details] Patch

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

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?

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

(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.

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.

(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?

(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*.

(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!

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

Comment on attachment 161826 [details] Patch Clearing flags on attachment: 161826 Committed r127825: <http://trac.webkit.org/changeset/127825>

All reviewed patches have been landed. Closing bug.