![\"\"](\"https:\/\/blogs.igalia.com\/jaragunde\/files\/2021\/04\/bubble-cloud.png\")
<\/a><\/p>\n<\/p>\n
JavaScript prompt dialogs<\/h3>\n
Several JavaScript things cause dialogs to be shown: Things like Once this was fixed, we took also care of some speech duplication caused by several items having the same accessible name, reported as #1185092<\/a>.<\/p>\n But browser interfaces themselves also use dialogs to create (hopefully) helpful interfaces for their users to do things like offering to save sensitive information like save a password or credit card information. Sadly, neither the save password or credit card dialogs were announced (#1079320<\/a>, #1119367<\/a>, #1125118<\/a>). A previous attempt to enforce announcing “save password” (of which I talked in a previous post) caused it to be announced twice when using the toolbar icon to open it (#1132318<\/a>).<\/p>\n These dialogs are particular because they have two behaviors: they can be explicitly opened using a toolbar icon, in which case they get focus immediately and must use the standard dialog role, or can be opened when a password is submitted. In the latter case, they don’t get focus and so they need to be announced as alerts. We fixed the problem by making sure we use one or the other role depending on how they are triggered, which enforces the correct code paths to produce alert event only when necessary.<\/p>\n Another useful things browsers offer to do is translate a page. This problem also affected the translate page dialog (#1119734<\/a>). It shares code and behavior with the aforementioned ones and was fixed at the same time.<\/p>\n Accounts and sync, the avatar icon in the toolbar, looks and behaves more similarly to a menu but it’s implemented with dialog (bubble) code. There were, unfortunately, some problems with it: it was not announced when opened (#1098304<\/a>) and contents that were informative and not focusable were not announced (#1078580<\/a> and #1161166<\/a>). We used a variety of techniques to fix the problem:<\/p>\n Extension management also involves a lot of dialogs (install, manage, remove, confirmation). We detected and fixed the issue #1123107<\/a>: the “add extension” dialog was not properly announced on Linux.<\/p>\n Browsers also launch system dialogs (open, save, print, etc). In the issue #1042864<\/a>, keystroke events were not being produced in these cases.. This was quite a complex one! I wrote two<\/a> posts<\/a> dedicated to just this problem and its solution.<\/p>\n If your browser crashes, a dialog asking the user if they’d like to restore the tabs that were open before the crash is show. This dialog was not being announced (#1023822<\/a>) and could not be focused with the Alt+Shift+A and F6 hotkeys (#1042010<\/a>). These were the first issues I worked on, and wrote a specific post<\/a> about them as well.<\/p>\n Dialogs are also used in browsers to ask for their explicit permissions to access powerful features. We briefly mentioned how these were fixed in a previous post<\/a> and we fixed their announcement (#1052675<\/a>) and their ability to be focused with hotkeys (#1052676<\/a>). In this process, I wrote the required code to emit alert events in the Linux accessibility backend, which was still missing at that point.<\/p>\n Additionally, I added more tests and cleaned up things a bit, refactoring code and removing some redundant events. It’s been quite a trip, building and testing on all the desktop platforms, taking into account platform-specific behavior and AT quirks… I still plan to keep working on this area, hardening automated testing if possible to prevent regressions, which should reduce the amount of effort in the long run.<\/p>\n Thanks for reading, and happy hacking!<\/p>\n","protected":false},"excerpt":{"rendered":" It’s been a bit more than a year since I started working on Chromium accessibility. Although I’ve worked on several kinds of issues, a lot of them had to do with UI dialogs of some kind. Browser interfaces present many … Continue reading alert()<\/code>, prompt()<\/code> or even in certain cases the window.beforeunload<\/code> event (if it is a function which returns a string, this is presented in a dialog before unload happens). These were reported in #779501<\/a>, #1164927<\/a> and #1166370<\/a>. On Windows ATs, these dialogs were not reading the actual content of the dialog when announced, thus defeating their purpose. This was fixed by removing some workarounds in the MessageBoxView class, a reusable component found inside these dialogs which used to implement alert-like behavior. This confused some ATs, which saw an alert inside a dialog; now it’s the parent dialog who might behave like an alert if needed.<\/p>\n<\/a><\/p>\nSave password and credit card dialogs<\/h3>\n
<\/a><\/p>\nAccounts and sync menu<\/h3>\n
\n
<\/a><\/p>\nExtension-related dialogs<\/h3>\n
<\/a><\/p>\nSystem dialogs<\/h3>\n
<\/a><\/p>\nRestore after crash dialog<\/h3>\n
<\/a><\/p>\nSite permission dialogs<\/h3>\n
<\/a><\/p>\n