Bug 106756 – AX: Need to implement ColorWellRole

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Dominic Mazzoni]

Chromium implements <input type="color"> using a native Mac color well, so it's important to support this role.

[Dominic Mazzoni]

Created attachment 182509 [details]
Patch

[chris fleizach]

Comment on attachment 182509 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=182509&action=review

the AXValue for a color well should return something like

AXValue	rgb 0.76448 1 0.280308 1, so VO can speak the color

> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2466
> +        const AtomicString& type = input->getAttribute(typeAttr);

What case will this not be handled by the same code in AXNodeObject?

[Dominic Mazzoni]

Created attachment 182599 [details]
Patch

[Dominic Mazzoni]

(In reply to comment #2)
> (From update of attachment 182509 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=182509&action=review
> 
> the AXValue for a color well should return something like
> 
> AXValue    rgb 0.76448 1 0.280308 1, so VO can speak the color

OK. I implemented the Mac version but the code won't be used until Safari has color well support. I implemented something similar in Chromium DRT.

> > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2466
> > +        const AtomicString& type = input->getAttribute(typeAttr);
> 
> What case will this not be handled by the same code in AXNodeObject?

Right now, AccessibilityRenderObject::determineAccessibilityRole doesn't call the inherited method. We need to refactor it some more to remove more duplication.

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[chris fleizach]

(In reply to comment #4)
> (In reply to comment #2)
> > (From update of attachment 182509 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=182509&action=review
> > 
> > the AXValue for a color well should return something like
> > 
> > AXValue    rgb 0.76448 1 0.280308 1, so VO can speak the color
> 
> OK. I implemented the Mac version but the code won't be used until Safari has color well support. I implemented something similar in Chromium DRT.
> 
> > > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2466
> > > +        const AtomicString& type = input->getAttribute(typeAttr);
> > 
> > What case will this not be handled by the same code in AXNodeObject?
> 
> Right now, AccessibilityRenderObject::determineAccessibilityRole doesn't call the inherited method. We need to refactor it some more to remove more duplication.

Is there a need to duplicate this logic in AXNodeObject currently then?

[Dominic Mazzoni]

(In reply to comment #6)
> Is there a need to duplicate this logic in AXNodeObject currently then?

I think there are now two relatively obscure places in the code where AXNodeObject is used without AXRenderObject:

1. In canvas fallback content
2. In a subtree with display:none but aria-hidden=false

These are admittedly rare, but I still think it's right to implement this code in AXNodeObject and try to refactor it over time to put most of the logic there and use AXRenderObject only where the information we get from the render tree differs.

[WebKit Review Bot]

Comment on attachment 182599 [details]
Patch

Clearing flags on attachment: 182599

Committed r139663: <http://trac.webkit.org/changeset/139663>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.