Ashley Sheridan​.co.uk

Tags:

Chrome has recently announced its intention to prevent cross-origin iframes from triggering the alert(), prompt(), and 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.

These types of modals have been part of Javascript for decades and have seen their fair share of abuse and subsequent alteration over the years, and it appears that Google is making this move as a continuation of that. Indeed, their main reason in the original request for deprecation trial notice says this:

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.
• Modals halt the execution of Javascript, meaning things aren't continually running in the background updating the page and triggering DOM updates.

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.

Halting the execution of all Javascript is impossible though. You can have some degree of control over your own code, but it will require a lot more work wrapping calls in asynchronous methods. Third party code is outside of your control, and there's very little you may be able to do at all to prevent unwanted script execution causing side effects.

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.

Education Problems

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 alert() and 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 alert() call is now several dozen lines of Javascript and HTML markup, future students and beginning developers will opt for the easiest route available to them. This route will almost certainly not be catering to accessibility needs, which are often seen as an afterthought on the web.

Final Deprecation

Chrome has looked at the feedback, and have now postponed the move until January 2022, a whole 5 months away at time of writing! While the web does move a lot faster than it did 20 years ago, I don't expect a consensus from other browser developers on this whole situation in that time frame. In order to replace these keystones of Javascript developers will need a viable alternative that works in any situation and offers the full feature set that the current suite of modals does. At the very least this will need an API, which might be years away.

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.