This is a report from nektar@ while Canary is on Google Chrome 67.0.3372.1 (Official Build) canary (64-bit) (cohort: Clang-64)
The accessible name of the dialog object has its own name in the accessibility tree and since it is different from the title bar, screen readers might read both or have trouble with determining which one to read. This can create inconsistent behavior across software.
However, the testing department is unable to provide repro steps or a verification for the following reasons:
- when you load a modal dialog from something like https://permission.site you are by definition unable to go to chrome://accessibility to check the a11y tree
- Screen readers do not give indication of what it is reading - accessible name or title bar, etc.
Therefore, Aaron should investigate this using his tools
This is a report from nektar@ while Canary is on Google Chrome 67.0.3372.1 (Official Build) canary (64-bit) (cohort: Clang-64)
The accessible name of the dialog object has its own name in the accessibility tree and since it is different from the title bar, screen readers might read both or have trouble with determining which one to read. This can create inconsistent behavior across software.
However, the testing department is unable to provide repro steps or a verification for the following reasons:
- when you load a modal dialog from something like https://permission.site you are by definition unable to go to chrome://accessibility to check the a11y tree
- Screen readers do not give indication of what it is reading - accessible name or title bar, etc.
Therefore, Aaron should investigate this using his tools
@nektar, can you tell me a little more about this bug? Does it overlap with issue 775680 ? I added some functionality that lets us change the BrowserView's accessible title if it has children with certain conditions met (right now, just focused visible tab-modal dialogs).
There's also a change to chrome://accessibility that will show the accessibility tree for the native UI for multiple windows, after a specified delay. So a workaround for some of these issues could be:
- in chrome://accessibility, request show native AX tree after 10 seconds
- open a new browser window and open a dialog
- wait the 10 seconds and return to the internals page
Comment 1 by leberly@chromium.org
, Mar 17 2018