Disable overlay in standard profile

As a developer use the minimal profile that is who it there for! Standard profile is designed for users.

+1 And yes, regarding #2 let's have a discussion here. Setting this as closed (won't fix) isn't productive.

@marcingy if you do not want to spend your time on such a thing, that is fine, but I find the response in #2 a discredit to anyone who has ever struggled with Overlay (including myself) when developing in Drupal.

The minimal profile does not necessarily solve the issue. I'm also wondering if we have any real usability studies to back up overlay.

yes please..i disable it *every* time i install drupal.
And now with inline editing i think its useless.if we are not going to remove it, this is a nice solution

triggering bot

Also see: http://drush.ws/examples/example.drushrc.php (line 85)

As far as I know we have had several 300+ comment discussions about this, the most notable one being #659488: Properly test the overlay to determine if it belongs in core or contrib to continue in #685046: Test Plan for the Overlay

I don't see any reason to open a new issue about this, it has been validated with users and argumented dozen of times. There is nothing to review here, I suggest reading those two issues before claiming we don't consider your comments.

Okay so an issue about Overlay usability testing exists at #685046: Test Plan for the Overlay but really you might also want to look at http://drupal.org/node/1175694

Under "What Tested Well"...

Toggle between the administrative overlay and site: All but one participant had a clear understanding of how to toggle between the overlay and the site. Participants understood when they were performing administrative activities and frequently used the overlay's "close" button to return to their previous location or before preparing to start a new task.

This tells us that 1 in 8 site-builder type users does not understand what overlay is trying to do. The study concludes that most people probably find that it is communicating the right idea. I think we all can agree that a basic user of the site will find overlay useful. However, developers working on Drupal often turn it off straight away.

I don't see any reason to open a new issue about this, it has been validated with users and argumented dozen of times. There is nothing to review here...

Let's get after what this issue is really about - comments about validating usability will lead to bikeshedding: This issue is about the install system. Specifically, Overlay being enabled as a part of the 'Standard' profile.

What's to be reviewed is a patch that removes Overlay from that profile.

Is the 'Standard' profile for end users? If an end user is someone who logs in and does basic admin tasks (ie: does not architect and build Drupal websites) then when does an end user install Drupal? (I would seriously like to know.)

The current 'Minimal' vs 'Standard' seems to be a very all or nothing approach. The Overlay can be turned on when delivering the site to these end users.

...I suggest reading those two issues before claiming we don't consider your comments.

I can empathize with frustration about #659488: Properly test the overlay to determine if it belongs in core or contrib going for over 300 comments and being unresolved. But there's nothing in this thread stating that comments are unconsidered...

Also issues linked in #7 are quite old..lets see how we feel about overlay after one release

@brantwynn Sure, just trying to point to earlier communication. You are questioning the role of "Standard", which is largely undefined - I am not sure how "overlay" is really quessential to that role discussion though. There has been no data to proof that it has been a mistake UX wise. There is a good amount of discomfort by developers with it, which I understand.

For the goals stated in the issue, you can use minimal. For the reasons outlined in all the other issues, we enable all UX "improvements" for standard profile.

@brantwynn as a developer of drupal I always simply use the minimal install profile and then enable the modules that I need. You have to consider that a vast number of drupal users are not developers and hence expect the best core experience available from a UX prospective out of the box. The best experience includes all UX enhances being enabled rather than them having to go and read a list on the modules page and work out how to get the overlay, toolbar etc enabled on the site they have just installed.

In case it helps, #775084-86: Allow users to opt-out of the overlay during installation for accessibility is the last time this was discussed. (I actually thought there was another issue too, but can't find it.)

Tagging

Can't we just collect the option in the config settings?
If the tick box is ticked, leave it enabled for user 1, else turn it off (apologies if someone has already said this)
Everyone's happy then

I agree with #17 @larowlan

Aside from the obvious developer experience issue. I personally have found the overlay to be a hinderance of sorts using a screen reader and a screen magnifier.

The average screen reader user would be confused at first while using Drupal, either as an administrator or a user, it would take them some time to get used to the fact that there is the overlay as the 'active window' (which isn't obvious to a screen reader user).
Also for screen magnifier users, the usability issue is in having to zoom in and out, as well as scroll up and down within the overlay, since the magnifier user can only see a portion of the screen at any one time, they may expect the entire page to scroll, instead of the overlay contents.
I'm using a Mac at 2560x1440 resolution and still need to scroll in the overlay.
On top of this, the spacing between each element is rather wide and for a magnifier user, the best analogy I can think of for this is like chasing an ant with a handheld magnifying glass on a large sheet of paper with one eye closed (I'm being perfectly serious, no humour intended).

One resolution for the spacing of the elements is of course to decrease the resolution - but a user shouldn't be forced to do this.
Another method would be to use the browser's zoom controls, but this can do one of two things

• Zoom the entire page, therefore the user would have to scroll both horizontally and vertically, causing unnecessary discomfort.
• Zoom the text only, this would also force the user to scroll vertically even more, possibly both in the overlay and the page itself.

I have provided two screenshots while using the Zoom in Mac OS X (currently at 1600x900 to reduce file size)

• One file shows zoomed in while in Appearance
• The other file shows the same screen with the browser's text increased almost full

Note: Admittedly, having a 27" screen in an advantage in my case, however, as well all know, not everybody has a large screen or the higher resolution capability, in essence, the smaller the screen and resolution the stronger the issue in terms of usability/accessibility.

Even the average person who may just simply have myopia (short-sightedness) may use text enlargement, so it's not all about visually impaired/blind users here.

Based on @caecus' first-hand experiences does someone want to have a go at rolling a patch as per #17?

I don't really understand, many of the problems you identified are because of zooming. Those problems are not really related to the overlay, but the seven theme in general.

Who is this average screen reader (I thought there is a big distribution in screenreader software/hardware)? Do they semantically have trouble understanding there is an active window? The concept itself is known, its just like a modal, are our modals also hard to use for screen readers? Why is there a semantic difference between the two? Can we solve this, or is it part of just using a modal?

@Bojhan: our modal dialogs are really more accessible than the overlay. In fact, there have been a lot of issues asking for overlay accessibility improvements. But, reality showed us that currently making the overlay accessible is challenging. Until we find a good solution to improve the overlay accessibility, huge +1 from me for disabling it by default.

On a side note: during sprints at Drupalcon Portland I noticed that a lot of people disable the overlay. :-)

Just curious, and this might be for another issue (if it doesn't already exist). Is another option using our modal dialog instead of iframe for overlay?

Yhea I agree with @webchick here. I never understood why seemingly the same concepts, have such differentiating implementations - especially if that solves accessibility.

@webchick: We tried doing it in another issue:
#890288: Improve Overlay accessibility by using modal dialogs
a while ago, but it was closed as "won't fix".

@Jessebeach tried converting the overlay to modal dialogs, but she came to the conclusion that this is almost impossible due to theming-related reasons (the overlay uses iFrames for these theming-related reasons, I suppose). So she filed:
#1964894: Apply the same (or near the same) ARIA attributes to the Overlay that jQuery UI Dialogs use
and other issues to significantly improve the overlay accessibility. However, they have not been fixed yet; I'm not sure that we will be able to fix them before D8 is released.

On a side note: keeping the overlay enabled, as a screen reader user, is simply a nightmare. And it really prevents you from using anything in Drupal.

@falcon03 I am not really following this, is this a critical a11y issue? If it is, then we should fix it. Disabling is not a fix, that's a work around you still have something in core that has significant accessibility issues. I'd like to keep this issue to the concept, if there is a bug, like this one - we should fix it. A bug shouldn't be the reason for disabling.

Back when the overlay was introduced - Everett decided we could keep it in, as long as we had an easy way to disable it (you can just by tabbing to the disable option) because its performance with different screen readers is hard to optimize for. This was the result of a very lengthy discussion between me, everett and several other members of the a11y team.

Techniques like ARIA available now, weren't implemented wildly at the time - so we couldn't benefit from them. However they seem to be more widely implemented now. If adding those roles to the overlay would fix the accessibility, we should. I still don't fully understand why it can't be a modal, essentially it's just a bigger modal - but jesse probably has a set of good rationale for that.

Techniques like ARIA available now, weren't implemented wildly at the time - so we couldn't benefit from them. However they seem to be more widely implemented now. If adding those roles to the overlay would fix the accessibility, we should. I still don't fully understand why it can't be a modal, essentially it's just a bigger modal - but jesse probably has a set of good rationale for that.

As far as I understand, when we turn something into a modal or dialog with ARIA, it essentially puts that wrapper into application mode. In this mode, the standard action key mappings of the screen reader are disabled -- all key bindings are released. And the developer is responsible for creating mappings. We don't want to be in this situation because we would want the screen reader user to navigate the content of the overlay in the same way they navigate a page normally.

My opinion about this is, the Overlay adds no benefit to non-sighted users. I think it adds small and dubious benefit to sighted users. We can spend a lot of time improving the accessibility of the Overlay and the experience will only ever approach acceptable; the experience will never be great as far as I can tell. Or, we can turn off the overlay by default or make it a per-user configuration perhaps.

#2088121: Remove Overlay

We talked about this on IRC, and I believe we agreed to do this.

Postponing on #1889150: Simplify overlay look, *only use for contextual operations* since that eliminates 99.9% of the complaints with Overlay.

If that doesn't get done by release, then we'll revisit this one.

Hm. Actually, I think this might be won't fix. We should either fix the overlay or remove it, not do this middle-ground, IMO.

Updated issue summary.

Due to #2088121: Remove Overlay this is now obsolete.

The "revisit before beta" tag no longer looks relevant here... removing it.