[Webkit-unassigned] [Bug 73819] [Gtk] Dojo toggle buttons should expose ROLE_TOGGLE_BUTTON not ROLE_PUSH_BUTTON

[bugzilla-daemon at webkit.org]

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





--- Comment #19 from chris fleizach <cfleizach at apple.com>  2012-08-16 17:11:37 PST ---
(In reply to comment #18)
> (In reply to comment #17)
> > (From update of attachment 158769 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=158769&action=review
> > 
> > after thinking about this patch more, I think we want to add a new WebCore accessibility role, and then just change the GTK mapping so the ToggleButtonRole (WebCore) maps to ATK_ROLE_TOGGLE_BUTTON
> > On the other platforms, it should still map to native button role. 
> 
> I'm not sure if I follow this "On the other platforms" sentence. What AccessibilityObject::roleValue should return in the case of being a toggle button (so the value of m_role computed at determineAccessibilityNode)?  If it always returns the new ToggleButtonRole, it will affect the other platforms.

You will need to add mappings on the other platforms so they map ToggleButton to whatever ButtonRole points to


> 
> One option would be use some #if PLATFORM(GTK) on determineAccessibilityRole, in order to return ToggleButtonRole only on gtk platform. But in that case I don't see the need to add a new role.
> 
> > This will allow other platforms to identify toggle buttons in the same manner if they need to, without realizing they need to check if something is a toggleButton() after the fact
> 
> See my previous questions. I fear that suddenly returning ToggleButtonRole for all platforms will somehow break those platforms, as they would be expecting a ButtonRole and suddenly they will receive a ToggleButtonRole
> 
> > 
> > Similarly, I feel like these likes that I see in the AXWrapperAtk.cpp class can be removed and you can rely on atkRole to return the right thing, because PasswordField should be a WebCore role
> > 
> > if (coreObject->isPasswordField())
> > 539539        return ATK_ROLE_PASSWORD_TEXT;
> 
> Well, IMHO, it shouldn't. On ATK we plan to stop to represent password fields with roles, and use instead states. The summary is that we found that text entries are not the only case that would require a "password mode". And after all being a password entry is just a custom state, where the entry are not showing their content (custom type of visibility). More info on this bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=668025#c1
> 
> > > LayoutTests/ChangeLog:8
> > > +        Added a extra rule on the mapping of WebCore accessibility roles
> > 
> > Comment should say
> > 
> > "Added a test to verify that when aria-pressed is present, buttons will have the appropriate role"
> 
> Ok
> 
> > > LayoutTests/platform/gtk/accessibility/aria-toggle-button-role.html:17
> > > +    obj2 = accessibilityController.focusedElement;
> > 
> > You should also test the case when aria-pressed is empty here.
> > 
> > and you should test the case when aria-pressed is on an non-button role
> 
> Ok
> 
> > > Source/WebCore/ChangeLog:10
> > > +        ATK_ROLE_TOGGLE_BUTTON when required.
> > 
> > Comment should say:
> > "Added an extra rule to the ATK accessibility role mappings based on whether aria-pressed is present.
> > http://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed"
> 
> Ok
> 
> > > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:493
> > > +    // From http://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed
> > 
> > Comment should say
> > 
> > "If aria-pressed is present, then it should be exposed as a toggle button.
> > http://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed"
> 
> Ok

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.