Unauthenticated users cannot disable Overlay

Marking this down to normal, this would be very uncommon.

Ok, so let's pretend that I need to use Overlay specifically for some functionality that is available to both anonymous & authorized users. If it was just for anonymous users you could do it with jQuery, but you want it to be the same in this space for both authorized & anonymous users. Maybe it's an exposed content type or something like that.

So we'd be developing a module that called overlay.. Is there anything at this point that would stop me for building in some cookie based system to disable it?

It would require some thought for most to think beyond their immediate needs & look at accessibility for their users. However, I'm trying to figure out if core is getting in the way of something or just not providing something that most developers aren't even aware they'd need.

We have to see how Drupal 7 starts to get implemented.

I'm trying to find a use case where a developer may want to set up a page for an anonymous using overlay.

I can't at this point see any way that core's per/user approach would block implementing a cookie based solution if this were needed for a contrib module.

A fair amount of speculation it's true.

This is a feature request. And sorry folks, but it's really *really* too late for this.

Core cannot (and should not) tackle every possible use cases itself. The overlay was designed as an administration tool, and as a consequence a tool for only authenticated users.

This works as designed. Changing the base assumptions of the design is called a feature request. And we are *way* past this now.

Given that everyone at this point wants Drupal 7 out of the door, my speculation is that the overlay will *never* be truly accessible. It is not as much a concern as it seems. People that want to certify sites against WCAG will be able to either (1) disable the overlay and leave it out of scope of the certification or (2) improve the overlay solution (in contrib) and disable the one provided by core.

If this is the case, then surely we should not allow the overlay to be enabled for anonymous users, then. Preferably we should do this in a way that would be easy for a contrib module to override. Or at least give a warning in the permissions that anonymous users may not be able to utilize the full feature set.

Yep, I fully agree with Damien here. Someone who wants to expose administrative pages for anonymous users is bending the system far beyond where it was meant to go. It'd be nice flexibility to allow for this (for example, in D8 adding something like http://drupal.org/project/session_api to deal with the general problem of "how do I support X for anonymous users?") but for D7 I think someone would need to tackle this in contrib with an Overlay module alternative.

If we ever implemented a 4chan-like site in Drupal, the use case of overlay and the unauthenticated user would go from marginal to critical, since 4chan does not require authentication.

subscribing

Can this be brought into D7 using the Accessible Helper Module?

Ultimately it's a matter of seeing if there is a need for this in the community mind you. Will all depend how Overlay type approaches are received I expect.

Just as an FYI, #896364-293: Screen reader users and some keyboard only users need a clear, quick way to disable the overlay is an RTBC patch for a D7 critical issue, and it includes a link to this issue from the PHPDoc of a new function it adds. This doesn't change anything discussed above, just letting people who are likely to be working on this issue for D8 core or D7 contrib know about that other one.

Could this be done simply by utilizing "skip_nav" links?

If some user clicks the "skip to content", there could be a way to jump only to the overlay or alternatively close the overlay and use the non-overlay version of a given page.

I can also see the following non-admin use case happening:
- website provides forms for users to fill in.
- There exists a module that provides an overlay for forms only, recycling the overlay api.
- when a link is clicked on, such that the link would load a form, the overlay pops up with that form content.
- In this way, the overlay is provided to public users for non-administrative purposes.

Another use case is with the editing_overlay module that I wrote.
It provides an overlay for the edit page of a node in a similar manner to the above, but for logged in non-admin users.

This would be tough. If the accessible helper module enabled the anonymous user to turn off the overlay, whatever intention the site implementer or contrib module had for it might break. Its a house of cards overriding something like this outside of core; either in the theming layer or via some hook. It needs to be done in core.

Dropping priority down as this is a hypothetical use case.

This is an edge case so bumping to D9 for now.