Chrome has recently announced its intention to prevent cross-origin iframes from triggering the
confirm() . These modals will still function for the top-level web page, and iframes within the same domain. Websites spanning multiple subdomains on the same domain will not allow these modals.
The current UX is confusing, and has previously led to spoofs where sites pretend the message comes from Chrome or a different website.
This change is expected in Chrome 92 Stable which will begin blocking these modals in cross-origin contexts by default. They do offer a method to (temporarily) disable this blocking for your domain, via their Trial for Disable Different Origin Subframe Dialog Suppression form which will take you through a process to allow this again. Alternatively users can re-enable the full behaviour again via the SuppressDifferentOriginSubframeDialogs policy (although this policy is being removed in Chrome 95).
Why is this an Accessibility Problem?
These three modals do a lot that a developer would otherwise need to manually handle with dozens of lines of code to give an equivalent experience to users:
- Modals by their nature prevent access to the content beneath until the modal is closed, either by accepting or cancelling.
- Focus is moved to the modal, and back again when the modal is dismissed.
- Modals announce themselves to assistive technology as modal dialogs.
Handling these first three cases can be done (mostly), but requires a lot of extra code to:
- Prevent clicking outside the modal to the content behind.
- Prevent tabbing (and other keyboard navigation such as screen reader shortcut keys) from moving outside of the modal.
- Move focus to the modal when it's displayed.
- Move focus back to the previous element (or another appropriate one if the previous one no longer exists) when the modal is closed.
- Extra Aria attributes to identify the type of dialog and how it should be presented to screen readers.
- Extra Aria attributes to identify the main regions of the modal and associate these labels with the modal in the correct manner.
Part of the problem is that too often developers aren't fully aware of these behaviours. Some are aware of a subset, and only develop for those scenarios, such as only blocking mouse clicks to content below. This creates situations where a person relying on assistive technology, such as a screen reader, is unwittingly performing actions on the page that the original developer hadn't necessarily catered for. The end result is a mix of errors and unwanted behaviour.
Marco Zehe, an accessibility engineer at Mozilla, points out the direction he believes this will end up taking the web:
Not to mention the accessibility implications. Between autocompletes on the one hand, and clickable divs that should be buttons or links on the other, this is yet another move that will create huge accessibility regressions. I am so f*cking tired. And I’m outa here. https://t.co/X4buEJd5qA
— Marco Zehe (@MarcoInEnglish)
August 5, 2021
This isn't a wild and unlikely prediction, it's a sentiment mirrored by developers all over. We've all seen badly implemented interactive components across the web. I'd argue that we've all been guilty of creating them at one point in time. But when developers are faced with having to replace the built in modals with their own custom implementations, we will see shortcuts and naïve creations that don't offer feature parity. This is especially likely considering that accessibility is not something that features much (or at all) in web development courses and education.
On the matter of education, Chrome's change has broken many educational workflows. The request for deprecation trial notice has many comments from disgruntled developers who use things like
prompt() within their course material, often pulling in other websites in an iframe from places like CodePen to run the code.
If the alternative to a simple
Chrome has become the new Internet Explorer; no really, bear with me! It has reached a dominant position, forced many other browsers to close shop or become a Chrome clone. And then, in a pattern of behaviour that should be familiar to developers who had to work in the IE 5+ era, Google is making some ill thought calls that will affect the entire industry.
This market dominance encourages developers to take the route of developing for Chrome specifically without putting much or any focus on other browsers. It is something I predicted a few years ago, and this latest move from Google has not done much to prove me wrong. I'm not saying their latest move is entirely incorrect, but it's definitely poorly timed. Before removing these modals, a viable alternative needs to exist to transition to. Without that, most developers will always pick the easiest route, not necessarily the best, and that will mean more people left with user interfaces they can't navigate. If security is an issue, then they could move to the heart of that issue instead. Perhaps those modals could block only that iframe, to make it more obvious, or if the modal is triggered from a different origin, make this extremely clear to the user. But just removing the feature, and in a way that the majority of people won't understand or even know about, is going to create a confused, broken experience across the web.