Issue metadata
Sign in to add a comment
|
[Orca] Use "application" and "frame" roles instead of "embedded" and "window" in browser chrome |
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3501.0 Safari/537.36 Steps to reproduce the problem: 1. Launch Chrome/Chromium * export ACCESSIBILITY_ENABLED=1, and * launch with --force-renderer-accessibility 2. Launch Accerciser 3. Use Accerciser's tree of accessibles to examine the role of Chrome/Chromium's top-level objects. What is the expected behavior? The top-level object would have role "application" and its child windows would have role "frame" (just like all of the other applications listed). What went wrong? The top-level object has role "embedded" and its children have role "window". Did this work before? N/A Chrome version: 70.0.3501.0 Channel: n/a OS Version: Flash Version: Compare to: Firefox (with accessibility enabled), Epiphany, any Gtk+ app Impact: While not a critical issue, consistency within the desktop environment is helpful both in terms of implementing support and in terms of a consistent presentation to the end user regardless of what application is being used.
,
Jul 25
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7fdc16fb641d2b8b3557fec089eef78f48098b05 commit 7fdc16fb641d2b8b3557fec089eef78f48098b05 Author: Martin Robinson <mrobinson@igalia.com> Date: Wed Jul 25 16:23:28 2018 Use ATK_ROLE_APPLICATION for toplevel applications The accessibility code for Aura on Linux was using the ATK_ROLE_EMBEDDED role for elements with the role ax::mojom::Role::kApplication so that it would not apply to ARIA applications. To be consistent with other applications, ATK_ROLE_APPLICATION is more appropriate. We only use this when the element is the root of the accessibility tree. TEST=accessibility_unittests --gtest_filter=AXPlatformNodeAuraLinuxTest.* Bug: 867006 Change-Id: I6c64b142cf3307c906f73235ed8247e828cd2394 Reviewed-on: https://chromium-review.googlesource.com/1148397 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#577920} [modify] https://crrev.com/7fdc16fb641d2b8b3557fec089eef78f48098b05/ui/accessibility/platform/ax_platform_node_auralinux.cc [modify] https://crrev.com/7fdc16fb641d2b8b3557fec089eef78f48098b05/ui/accessibility/platform/ax_platform_node_auralinux_unittest.cc
,
Jul 26
,
Jul 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/84dd920dda7148d5f1dd72d2144d1538dffc9b98 commit 84dd920dda7148d5f1dd72d2144d1538dffc9b98 Author: Martin Robinson <mrobinson@igalia.com> Date: Fri Jul 27 16:23:05 2018 Convert Window role to ATK_ROLE_FRAME for Aura Linux Instead of using ATK_ROLE_WINDOW by default for the internal Window accessibility role, use ATK_ROLE_FRAME. ATK_ROLE_FRAME is used for windows that have titlebars and buttons, while ATK_ROLE_WINDOW is reserved for those that don't. Since most windows have buttons and a titlebar in Chromium, ATK_ROLE_FRAME is probably a better default. TEST=accessibility_unittests --gtest_filter=AXPlatformNodeAuraLinuxTest.* Bug: 867006 Change-Id: Ia0366f7088465f123f00e250c4cc6f7393c0c64e Reviewed-on: https://chromium-review.googlesource.com/1148445 Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#578665} [modify] https://crrev.com/84dd920dda7148d5f1dd72d2144d1538dffc9b98/ui/accessibility/platform/ax_platform_node_auralinux.cc [modify] https://crrev.com/84dd920dda7148d5f1dd72d2144d1538dffc9b98/ui/accessibility/platform/ax_platform_node_auralinux_unittest.cc
,
Sep 11
Closing as fixed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Jul 25