Bug 255707 - AX: CSS speak-as, AXAccessKey, aria-owns, and URL AX APIs don't work for display:contents elements
Summary: AX: CSS speak-as, AXAccessKey, aria-owns, and URL AX APIs don't work for disp...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tyler Wilcock
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-04-19 23:21 PDT by Tyler Wilcock
Modified: 2023-04-20 17:37 PDT (History)
10 users (show)

See Also:


Attachments
Patch (36.13 KB, patch)
2023-04-19 23:25 PDT, Tyler Wilcock
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (36.19 KB, patch)
2023-04-19 23:31 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff
Patch (36.21 KB, patch)
2023-04-19 23:55 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff
Patch (37.68 KB, patch)
2023-04-20 10:33 PDT, Tyler Wilcock
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tyler Wilcock 2023-04-19 23:21:22 PDT
...
Comment 1 Radar WebKit Bug Importer 2023-04-19 23:21:36 PDT
<rdar://problem/108301432>
Comment 2 Tyler Wilcock 2023-04-19 23:25:02 PDT
Created attachment 465999 [details]
Patch
Comment 3 Tyler Wilcock 2023-04-19 23:31:55 PDT
Created attachment 466001 [details]
Patch
Comment 4 Tyler Wilcock 2023-04-19 23:55:50 PDT
Created attachment 466002 [details]
Patch
Comment 5 Andres Gonzalez 2023-04-20 07:07:13 PDT
(In reply to Tyler Wilcock from comment #4)
> Created attachment 466002 [details]
> Patch

--- a/Source/WebCore/accessibility/AccessibilityObject.cpp
+++ b/Source/WebCore/accessibility/AccessibilityObject.cpp

+String AccessibilityObject::accessKey() const
+{
+    auto* element = this->element();
+    return element ? element->attributeWithoutSynchronization(accesskeyAttr) : String();
+}

As we re-org the code, shouldn't this one that requires an Element be in AXNodeObject?

+bool AccessibilityObject::supportsARIAOwns() const
+{
+    return !getAttribute(aria_ownsAttr).isEmpty();
+}

Same here.


diff --git a/LayoutTests/accessibility/display-contents-aria-owns.html b/LayoutTests/accessibility/display-contents-aria-owns.html
new file mode 100644
index 000000000000..4fcf823664ca
--- /dev/null
+++ b/LayoutTests/accessibility/display-contents-aria-owns.html

If we are going to have many tests named display-contents-*, maybe it makes sense to put them under a display-contents dir. On the other hand, it makes me wonder if we should add the display:contents test cases as part of the existing test, i.e., added to the aria-owns tests, like you did for the accesskey and the other tests.

--- a/LayoutTests/accessibility/mac/accesskey.html
+++ b/LayoutTests/accessibility/mac/accesskey.html

+    var link = window.accessibilityController.accessibleElementById("link");

Almost everywhere else we reference the accessibilityController as a global without window.

+    output += expect("input.allAttributes().indexOf('AXAccessKey: q') !== -1", "true");

Why do we need allAttributes() and not get the accesskey alone?
Comment 6 Tyler Wilcock 2023-04-20 10:32:14 PDT
> +String AccessibilityObject::accessKey() const
> +{
> +    auto* element = this->element();
> +    return element ?
> element->attributeWithoutSynchronization(accesskeyAttr) : String();
> +}
> 
> As we re-org the code, shouldn't this one that requires an Element be in
> AXNodeObject?
> 
> +bool AccessibilityObject::supportsARIAOwns() const
> +{
> +    return !getAttribute(aria_ownsAttr).isEmpty();
> +}
Fixed.

> diff --git a/LayoutTests/accessibility/display-contents-aria-owns.html
> b/LayoutTests/accessibility/display-contents-aria-owns.html
> new file mode 100644
> index 000000000000..4fcf823664ca
> --- /dev/null
> +++ b/LayoutTests/accessibility/display-contents-aria-owns.html
> 
> If we are going to have many tests named display-contents-*, maybe it makes
> sense to put them under a display-contents dir. On the other hand, it makes
> me wonder if we should add the display:contents test cases as part of the
> existing test, i.e., added to the aria-owns tests, like you did for the
> accesskey and the other tests.
I did try to add a display contents case to an existing aria-owns test, but it was a bit clunky so opted to just make a separate one. A separate display-contents folder makes sense -- will consider for a future patch.

> --- a/LayoutTests/accessibility/mac/accesskey.html
> +++ b/LayoutTests/accessibility/mac/accesskey.html
> 
> +    var link = window.accessibilityController.accessibleElementById("link");
> 
> Almost everywhere else we reference the accessibilityController as a global
> without window.
Fixed.

> +    output += expect("input.allAttributes().indexOf('AXAccessKey: q') !==
> -1", "true");
> 
> Why do we need allAttributes() and not get the accesskey alone?
I thought that existing behavior was weird too, but it actually has the advantage of checking that the attribute is supported in addition to having the right value (because allAttributes() only queries for supported attributes).

Further more, there is no existing AccessibilityUIElement functionality for accesskey querying, and this existed before my patch, so let's leave it as-is with all the other display:contents work we have to go.
Comment 7 Tyler Wilcock 2023-04-20 10:33:07 PDT
Created attachment 466017 [details]
Patch
Comment 8 EWS 2023-04-20 17:37:28 PDT
Committed 263205@main (204cc1e1e3a3): <https://commits.webkit.org/263205@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 466017 [details].