[1][2][3] On the Web, they often show images in detail, such as those implemented by Lightbox library, or are used for hover ads.
[10] Unexpected alert dialogs are particular culprits of mode errors[1] with potentially severe consequences.
One proposed approach is to design every input element as a self-contained, task-oriented interaction, guided by its own specific requirements rather than by the global state of the entire application.
Modal windows are commonly implemented in ways that block the possibility to move, minimize, iconify, or push that window back, and they grab input focus, which often prevents use of a system's cut, copy, and paste facilities.
For users using virtual work areas larger than their actual screens, modal windows can cause further undesirable behavior, including creating the modal on a portion of the virtual screen not currently on the display, or abruptly switching the display from what the user was working on to an entirely different section.
Further, modals usually interpret actuation of the enter key (or in rare cases the presence of a newline in pasted input) as a cue to accept the input and process it—or, in rare cases, may intercept a mouse click intended for a different application that has suddenly been covered.
Such interception, called focus stealing (or stealing focus) can compromise privacy and security practices, as well as capture inappropriate, out-of-context input that can cause undefined, arbitrary results in the program that generated the modal window.
A semi-transparent background can be made less intrusive by having the whole background area function as a close button: this is standard on most mobile operating systems, avoids making the user feel trapped, and makes modal windows feel less like malicious pop-ups.
Mac OS X uses modal sheets with affirmative action buttons being the right-most command.