Chromium implements <input type="color"> using a native Mac color well, so it's important to support this role.
Created attachment 182509 [details] Patch
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?
Created attachment 182599 [details] Patch
(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.
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
(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?
(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.
Comment on attachment 182599 [details] Patch Clearing flags on attachment: 182599 Committed r139663: <http://trac.webkit.org/changeset/139663>
All reviewed patches have been landed. Closing bug.