Follow-up to #716612: Overlay is not accessible to screen reader users.

In #659480: Per-user setting for the Overlay an option was added to user profiles to allow individual users to disable the Overlay for their account. This option requires the user to be authenticated. There is no option for an unauthenticated user to disable Overlay.

Although it is unlikely that an unauthenticated user will encounter Overlay it is possible for a D7 site to be configured in a way that makes this possible, therefore we need a mechanism to allow unauthenticated users to disable the Overlay for their session.


Everett Zufelt’s picture

Issue tags:+accessibility


Bojhan’s picture

Priority:Major» Normal

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

mgifford’s picture

Priority:Normal» Major

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.

Everett Zufelt’s picture

There is no reason that The Overlay module itself cannot handle being disabled by anonymous users with a cookie. Are you suggesting that Overlay may be "required" for certain contrib modules to work?

mgifford’s picture

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.

Damien Tournoud’s picture

Version:7.x-dev» 8.x-dev
Category:bug» feature

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

Everett Zufelt’s picture

Version:8.x-dev» 7.x-dev
Category:feature» bug

Accessibility "bugs" are not feature requests. I do not see why this could not be dealt with after beta. I would have * never * spun this issue off if I thought that it would then be dealt with with less concern.

If a site is configured so that unauthenticated users may have to unteract with Overlay then those users need a method to disable overlay if they are not able to work with it. This is a bug. It might not be major or critical, but it is not a feature, it is a current feature that will not function for all users.

Damien Tournoud’s picture

Version:7.x-dev» 8.x-dev
Category:bug» feature

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.

cwgordon7’s picture

Priority:Major» Normal

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.

webchick’s picture

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 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.

shunting’s picture

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.

attiks’s picture


mgifford’s picture

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.

effulgentsia’s picture

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.

thekevinday’s picture

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.

johnbarclay’s picture

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.

mgifford’s picture

Priority:Normal» Minor

Dropping priority down as this is a hypothetical use case.

mgifford’s picture

Version:8.x-dev» 9.x-dev

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

mgifford’s picture

Version:9.x-dev» 7.x-dev
Issue summary:View changes
Status:Active» Postponed