[Webkit-unassigned] [Bug 153696] REGRESSION(r195463): [GTK] accessibility/roles-computedRoleString.html and accessibility/roles-exposed.html failing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=153696

--- Comment #8 from Mario Sanchez Prada <mario at webkit.org> ---
(In reply to comment #5)
> Comment on attachment 270382 [details]
> Patch proposal
> 
> What’s the real concept here? Is the notion of a style format group specific
> to Mac, as opposed to say, iOS? Is the issue really about something
> different from the Mac from every other platform?

The main problem is that Mac (and iOS, I think) uses the role GroupRole and a specific subrole to expose the nature of certain element like <pre> to Assistive technologies but, in contrast, ATK does not have this concept of subrole, and will therefore expose all those elements as ATK_ROLE_PANEL (since that's that GroupRole maps into), which at least for <pre> elements is wrong (they should be exposed as ATK_ROLE_SECTION).

One solution, ATK-specific, is to have the ATK wrapper to check the tagName for GroupRole elements and then decide whether to expose them as ATK_ROLE_PANEL or ATK_ROLE_SECTION, but since the PreRole was still around and Chris's patch seemed to be Mac-specific in a way, I thought that making that distinction (exposing the role of those elements via GroupRole + Subrole) only on the Mac, would make sense, hence the patch.

But if that's unnacceptable, we could certainly rework the patch to make the distinction at the ATK level, that would be another option too.

(In reply to comment #7)
> (In reply to comment #5)
> > Comment on attachment 270382 [details]
> > Patch proposal
> > 
> > What’s the real concept here? Is the notion of a style format group specific
> > to Mac, as opposed to say, iOS? Is the issue really about something
> > different from the Mac from every other platform?
> 
> I think we can expose this on iOS too without problem. 
> 
> I guess GTK does not want this behavior though

As mentioned above, the two key concepts for the GTK port are that (1) we don't have subroles (so we can't expose things using a GrouRole + specific subrole) and that (2) we want to expose <pre> elements with role ATK_ROLE_SECTION (so we still need to distinguish one GroupRole elements from another).

That said, let me know if you prefer an ATK-specific solution and I'll rework the code to have the ATK wrapper check the tag name for GroupRole elements. But in that case, I think we should probably remove all trace of the PreRole definition and usage, since the newly added code basically prevents that role from ever being exposed, I believe. 

(In reply to comment #6)
> Comment on attachment 270382 [details]
> Patch proposal
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=270382&action=review
> 
> > LayoutTests/platform/gtk/accessibility/roles-computedRoleString-expected.txt:51
> > +FAIL: pre -> . Expected: group.
> 
> It's too confusing to have FAIL print in our expected results; we should do
> this less often. Can you try reworking the test to avoid this?

I agree it's definitely confusing, but it's hard to rework since the data-role attribute states GroupRole, which is what correct for the Mac, so you can't really fix it for one platform without screwing things up the other. We could make these platform specific tests, but that would fork/duplicate so many role tests unnecessarily IMHO, so that's why I think that, in this particular case, a single FAIL expectation for the <pre> element does the job well enough.

Maybe Joanie has a different point of view, suggestion, though. Joanie, ideas?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160201/606013d8/attachment.html>