Screen reader users and some keyboard only users need a clear, quick way to disable the overlay

Damien Tourmond writes:

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.

It would seem, then, that giving the option to disable overlay during installation is really the cleanest solution. And otherwise -- hoping I'm not oversimplifying -- if we force everyone to install it, aren't we placed in the position of telling users with accessibility concerns to disable something through the very interface that is not accessible to them?

@shunting wrote:

Damien Tourmond writes:

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.

This is partly correct. What is missing is a reference to situations where users may be attempting to use a site that was built without accessibility in mind. We are doing our best to ensure that functionality native to Core be natively accessible.

It would seem, then, that giving the option to disable overlay during installation is really the cleanest solution.
And otherwise -- hoping I'm not oversimplifying -- if we force everyone to install it, aren't we placed in the position of telling users with accessibility concerns to disable something through the very interface that is not accessible to them?

I don't think we are doing this.

My recommendation is that the UI to disable the Overlay appear:

1. Only when Overlay is open.
2. At the top of the DOM and at the top of the Overlay segment of the DOM (before the skip link).

This may still cause problems for some screen-reader users, depending on the technology (screen-reader / browser combo) they are using. But, this is the best we can do without disabling the Overlay by default in Core, which is not an option, and which would still not solve the problem for sites where Overlay is enabled.

Clear, quick... can't we add a fasttoggle like menu path? I have already asked this in the per user overlay toggle patch. Don't forget that we are talking of new users. You click on a "disable overlay" link and met with a sea of checkboxes, text fields and whatnot. Awesome UX!

@chx If its technically possible, I think we would always favor that kind of approach. Was under the impression that is hard to do.

Hi, a first stab at the issue. Patch attached. It displays a "disable overlay"-link early in the html and exposes an additional menu path (as suggested by chx above). All the Javascript-ARIA-Stuff from #716612 has been left out. It does not address comment #4's point that the "disable overlay"-link/UI should only appear when the overlay opens; I don't have a JAWS or similar setup (nor experience :) and have only tested this in lynx and FF w/o CSS.

1) The link text should perhaps be a bit more expansive/comprehensible for new users; maybe: "If you are using a screenreader, you might encounter problems using the administrative overlays. Please click here to disable them.".

2) David_Rothstein wrote: "For someone who wants to continue using the overlay it will be annoying to have this on every single page". To address that, we could show the following text/links for screenreaders only until a choice has been made: "If you are using a screenreader, you might encounter problems using the administrative overlays. Link 1: 'It works fine for me, I want to keep the overlays' and Link 2: 'Deactivate the overlays'". Once a choice has been made these links wouldn't be displayed anymore. That is easily implemented.

subcribing

Hrm, that's not CSRF protected. http://drupal.pastebin.com/0cgEAUgX

Updated the patch.
1) Incorporated chx's code (but maintaining 'access arguments' => array('access overlay')).
2) Moved (for the time being) the CSS for the #disable-overlay wrapper into a separate file (overlay.css) because overlay-parent.css is not loaded on pages normally opening in overlays (e.g. /user/1/edit) thus "exposing" the disable link; using class .element-invisible was rejected in #716612 and the only other option seemed to patch all themes (style.css) like in the case of #skip-link. Looking for a more elegant solution - maybe a shared class for #skip-link and #disable-overlay (or all "screenreader" elements?)

There's a patch; marking "needs review".

You can get back to my simpler menu callback IMO. drupal_goto handles $_GET['destination'] I believe. Also, we almost never check the return value of user_save...

Ok, cleaned up overlay_user_disable() as per chx suggestions; kept feedback message and drupal_goto to user edit page / or given destination.

Outstanding points:
1) Finalise wording of the link text (and/or link title) to be more comprehensible for new users (see comment 7 above, point 1)
2) Functionality: display message to screenreaders only until a first choice (keep/disable) has been made? Or show disable link always when overlay active? (see comment 7, point 2)
3) CSS: Can #skip-link and #disable-overlay share a class? Where do we put #disable-overlay-CSS?

ping testbot

+      $page['page_top']['disable_overview'] = array(

should be disable_overlay

+      // @todo: There must be a better way than include a css file for just one line, but overlay-parent.css is *not* included on admin pages
+      // and otherwise we'd have to put #disable-overlay (like #skip-link) in all themes css files.
+      // Using a class "element-invisible" apparently is not ok (@see http://drupal.org/node/716612#comment-3383342).
+      drupal_add_css( drupal_get_path('module', 'overlay') . '/overlay.css' ) ;

we could use .invisible-element if we handle #897638: Make .element-invisible work for focusable elements like links first.

A key binding is an interesting idea. But, since this is likely going to be a one time use thing I'm not sure that it would be that benificial. Also, it is difficult to find a key binding that doesn't conflict with key bindings for the OS / Browser / Assistive technology combos that may be in use.

We're not cluttering up areas such as the installer, the user profile form, etc. for options that only affect the 0.0001% of users out there who are Drupal admins, as opposed to end users on a Drupal site. No.

@design_dolphin

I agree that the user registration form is the wrong place to put this option. It is best, usually, to place a control nearest to the feature that it will deactivate. As a simple user I would have absolutely no idea what I was choosing to enable or disable from the registration form.

Speaking as a person with a disability :)

The distinction webchick makes is that between admins and regular users and content creators, not between people with and without a disability. We´re still working on solving the actual issue, too.

OT:

My experience with other CMSs is limited, but I think that it is safe to say that the Drupal community has put more effort and time into accessibility than any other. Also, since my involvement with Drupal began I have not seen an issue not resolved because the quantity of users affected was marginal. We are doing a great job, the concept of placing the overlay disable link on the user registration form is just a poor design option.

Yes, to be clear, my comment was about the ratio between "number of users reading / commenting on / rating stuff / whatever on site X" to "people on site X who will actually see the Overlay". It makes zero sense to expose options to all people that only apply to a tiny, tiny subset of people who are actually affected.

Putting this option on or near the actual Overlay, though, makes a lot of sense, because then the people actually affected by it can make the decision. AFAIK that's what this patch is doing.

Why redirect to user/X/edit?

@chx

We have two choices. 1. Provide a toggle that turns overlay off and then modifies the setting in the user profile. 2. Direct the user to their profile page to disable it them self.

1. Is more transparent for the user, and faster.

2. Gives * some * context to the user should they wish to enable again.

I'm quite happy with either approach.

Well context is good. I am OK with the patch, then.

chx, is good with the patch if Everett is too all we got to fix is the wording "Disable administrative overlay" - is that what we use on user profile to? I feel its handy to refer in this sentence to the user profile, rather then the action?

@Bojhan

The title of the iframe in which the Overlay content lives is "... dialog" e.g. "People dialog". IMO dialog is more understandable than Overlay (since it maps to desktop applications. I had never heard of an "Overlay" as part of a UI before D7. In another issue I have suggested switching the text for the close button from "Close Overlay" to "Close dialog" to be more consistent with the iframe title.

The problem is that Dialog is likely easier to understand, but Overlay is what we are calling it in D7, and what we call it on the User Profile page.

We also somehow need to communicate that this dialog / overlay thing, that I have the option to disable, is the thing that might be causing me problems accessing administrative tasks on the site.

I'm not sure how to communicate that clearly and concisely.

If nobody comes up with something better:

This site presents administrative pages in a dialog (Overlay), which may not work properly with all assistive technology. Disable the Overlay from your User ProfileDo not show me this message again

The problem with the second link is that a keyboard only user may be confused. Show me what message? Since the message will likely be hidden with .element-invisible

My suggestion would then be:

Administrative pages are shown in an overlay. Disable the overlay if you have problems accessing administrative pages. (Do not remind me again)

I'd loved to reroll the patch according to #13, #28 and #31 but am still a little confused :) and have a suggestion myself, hth.

So just to restate #31 for myself: A) We display the following in an ".element-invisible"-div to logged-in users w/ overlay access permissions:
"This site presents administrative pages in a dialog (Overlay), which may not work properly with all assistive technology"
-> Disable the Overlay on your User profile (->user/{x}/edit)
-> Do not show me this message again (disables this information message and reloads the page)

B) Alternative/My suggestion: display the message above only as long as *no explicit choice* to enable (or disable) it has been made and offer following choices:
-> Disable the Overlay (->disable the overlay ->return to current page and provide "context" in the status message instead: "The overlay has been disabled. You can enable it on your user profile [linked to user/{x}/edit]")
-> Keep the Overlay (->explicitly enable the overlay -> return to current page and provide "context" in the status message: "The overlay has been enabled. You can disable it on your user profile [linked to user/{x}/edit]")

But i am happy to adjust the patch according to A) or B) :)

EDIT: Oops, didnt see #32 - I like the wording; does the link take the user profile or does it directly disable the overlay?

@32 with some tweaks

Administrative pages are currently shown in an overlay. Disable the overlay from your User Profile if you have problems accessing administrative pages. (Do not remind me again)

We still need to address how to show the message. .element-invisible is not acceptable for the links, as they are focusable. Also, the second link still doesn't make sense out of the context of the message (which is what a sighted keyboard only user would get if the links alone are shown on focus). Can we make the entire message invisible by default, but show the entire message if either link has focus using a technique similar to that used for skip links?

@design_dolphin

Does the message in #35 address your concern in #34?

We might even consider having the disable link go directly to the label for the Overlay disable checkbox on the user profile edit page.

@design_dolphin

I agree that it is necessary to be clear that no admin functionality will be lost. I don't think that we necessarily need to refer to assistive technology.

@design_dolphin

I don't really see a problem with linking to the label for the Overlay checkbox on the profile page. Users know they are going to the user profile page (the link says so). Any drawback of not starting at the top of the page is mitigated by the benefit of landing exactly where you need to be to disable the Overlay.

Lets get a patch up that does #35 - we need to show the whole message.

I do not share design_dolphin his concerns, we can't afford to clutter this message. The most important thing is to conceive the thing that might be causing trouble can be disabled on the user profile page. All other things will be adding clutter.

I don't know if we can route it directly to the checkbox, it would need a href?

Lets test that with an updated patch :)

I hope it's not in too bad form to just go ahead and write a patch w/o consensus; had a few minutes at hand to work on patches right now :)

Approach:
A) Single link on top: "Click here if you have problems accessing the administrative pages (opening in Administrative overlays) or you want to dismiss this message" and linking this to B)

B) Page for more details what's happening and why; two links to 1) directly "Disable the overlay" (without *ever* going into an overlay) and 2) "Dismissing the message" (and keeping the overlays on).

Reasoning:
A) keeps the message (relatively) short and avoids another invisible link "appearing" on focus (see #35 above) B) gives more space to flesh out in detail what's going on. Overlays will be possible to disable without opening an overlay (see #45).

Texts certainly need rewriting. I hope this helps :)

Testable patches are a great way to work towards consensus, so thanks for this. Certainly not bad form!

I think we easily could use one user data variable to store user's overlay preference by using some constants.

/**
 * Current user has not yet set his preference regarding the overlay; the overlay will be used, but an hidden, yet accessible, message is presented that allows the user
 * to easily set his preference.
 */
define('OVERLAY_PREFERENCE_INITIAL', 0);

/**
 * Current user prefers to use the overlay for administrative pages.
 */
define('OVERLAY_PREFERENCE_ENABLED', 1);


/**
 * Current user prefers not to use the overlay for administrative pages.
 */
define('OVERLAY_PREFERENCE_DISABLED', 2);

If we store this value into $user->data['overlay'] we don't need $user->data['overlay_message_dismissed'].

Patch incoming in 15min or so.

Sorry it was more like an hour.

I didn't really like all the new pages of previous patch.

Attached patch:
- Direct link to account edit page having the "overlay-exclude" class to prevent opening in the overlay.
- The disable message disappears as soon as the user has set his overlay preferences (We could extend the account edit page to reset overlay preferences so the message becomes visible again).
- Disable message/link becomes visible on focus. Not too sure about its looks; tried to keep close to toolbar/overlay style.

Feel free to post new patches

@Casey

Does your patch render the link before or after the skip to link in the DOM? I am thinking that after is better, so that we can set focus to the skip link and this link will be after.

Also, does your patch add this link both to the top of the Overlay and the underlying document?

After, but only to the parent (underlying) page. You think we need it on both? Thinking about it, you may be right then.

@Casey

Since we can't really predict how the overlay will work for all AT / Browser combos I'd like to see the disable link at the top of the DOM and the top of the Overlay (both times after Skip to ...) This means that if the user lands in the iframe they will have the link, if they land at the top of the page they will have the link.

Based on casey's patch in #54, tries to address issue raised in #58.

Attached patch:
- Uses template_preprocess_overlay() to insert the $disable_overlay_link into overlay.tpl.php (hook_page_alter wouldn't have gotten us to the 'top')
- Adjustes overlay.tpl.php
- overlay-child.css copies CSS from overlay-parent.css and adds a z-index:101 (to lay on top of e.g. #overlay-title-bar)
- Uses NULL/!isset instead of the constant OVERLAY_PREFERENCE_INITIAL introduced in #54

@59: Good point, we would need something that states the context and the functionality, without being too redundant or jargon-heavy. Perhaps something like "Show administrative features on top of the current page" would work?

Can't we put this long text into the attribute title instead of the link text itself and make the link text shorter (a lot shorter)?

We can not trust assisitive technology to reliably use the anchor title since:

1. Most don't and,
2. There is no API stating that this is expected behaviour for AT.

Here's my initial review. Note that I have tried to remain as ignorant as possible as to what's been going on in this issue, so that I can give it a totally fresh set of eyes. Apologies if any of this was already mentioned above; I'll read the issue once I'm done here.

+++ modules/overlay/overlay.module	9 Sep 2010 17:56:03 -0000
@@ -7,6 +7,16 @@
 /**
+ * Current user prefers not to use the overlay.
+ */
+define('OVERLAY_PREFERENCE_DISABLED', 0);
+
+/**
+ * Current user prefers to use the overlay.
+ */
+define('OVERLAY_PREFERENCE_ENABLED', 1);

Please remove those constants. There is no other state, so it can only ever be 0/1, and that's entirely and sufficiently communicated via 0 and 1.

+++ modules/overlay/overlay.module	9 Sep 2010 17:56:03 -0000
@@ -105,8 +115,8 @@ function overlay_init() {
-  $use_overlay = !isset($user->data['overlay']) || $user->data['overlay'];
...
+  $use_overlay = !isset($user->data['overlay']) || $user->data['overlay'] == OVERLAY_PREFERENCE_ENABLED;

This can be reverted, too - without type-agnostic comparison, the old and the new are identical (in PHP).

+++ modules/overlay/overlay.module	9 Sep 2010 17:56:03 -0000
@@ -254,10 +264,32 @@ function overlay_page_alter(&$page) {
-  if (overlay_get_mode() == 'child') {
+  $mode = overlay_get_mode();
+  if ($mode == 'child') {
...
+  elseif ($mode == 'parent') {

Does Overlay implement other modes than 'child' and 'parent'? If it does not, then we can revert to the old if/else condition.

+++ modules/overlay/overlay.module	9 Sep 2010 17:56:03 -0000
@@ -254,10 +264,32 @@ function overlay_page_alter(&$page) {
+    // If the current user can access the overlay but has not expressed a preference regarding the overlay (or saved his/her profile),
+    // display a "disable overlay" link to the user profile for improved accessibility.

(and elsewhere) All comments should wrap at 80 chars. See http://drupal.org/node/1354 for details.

+++ modules/overlay/overlay.module	9 Sep 2010 17:56:03 -0000
@@ -254,10 +264,32 @@ function overlay_page_alter(&$page) {
+        '#title' => t('If you are having problems accessing administrative pages (which are currently opening in an overlay on top of your website) or if you want to dismiss this message, you can set your overlay preferences on your user account page.'),

(and elsewhere) This link text needs to be shortened to the point - to be improved suggestion:

"Click here If you cannot access the overlay. It can permanently disabled in your account settings."

+++ modules/overlay/overlay.module	9 Sep 2010 17:56:03 -0000
@@ -324,9 +356,27 @@ function overlay_preprocess_maintenance_
+  if (!isset($user->data['overlay']) && user_access('access overlay')) {
+    $variables['disable_overlay_link'] = l(
...
+  }
+  else {
+    $variables['disable_overlay_link'] = FALSE;
+  }

+++ modules/overlay/overlay.tpl.php	9 Sep 2010 17:56:03 -0000
@@ -21,6 +21,7 @@
+<?php if ($disable_overlay_link): ?><div id="overlay-disable-link"><?php print $disable_overlay_link; ?></div><?php endif; ?>

Instead of suddenly using l() here, we should use the same renderable array (ideally, even through a helper function), assign it to the template variables, and use render() in the template.

To do that, FALSE has to become array(), I think.

Powered by Dreditor.

"Click here If you cannot access the overlay. It can permanently disabled in your account settings."

Would people have a problem understanding what "the overlay" is? The original text talks about "problems accessing administrative pages" and then explains the reason is due to an overlay , hence why they would want to turn it off?

How about?
"The administrative pages open an overlay over your website. Click here If you cannot access the overlay. It can permanently disabled in your account settings."

"All administrative pages open in an overlay window. Click here If you cannot access them."

After clicking, and only after clicking, we display the following message:

"Disable the overlay permanently in your <a href="@account-url">account settings</a>."

Not sure whether we have a neutral message type anymore. A green/positive status icon would look odd to me, so I'd perhaps go with the 'warning' type.

#67 +1

@Sun

Can you please explain how we are doing the message switch? Are you suggesting that we dynamically change the message, or that we redirect to a page with the second message?

I think that ideally there would be one message that directs the user to their edit profile page.

** that being said wording of this message is not a sticking point for me. I will give a big +1 to anything that reasonably solves the problem of:

1. Communicate that Overlay exists, what it does, and how to disable it.

2. Provides a way to get to the UI to disable Overlay.

@sun - thanks for the review in #65. I rerolled accordingly (see details below).

Finding the right phrasing seems really tricky; I for sure can't come up w/ anything short & decent :)

I don't yet entirely get what intended plan in #67 is. How would you let the "Disable the overlay permanently in your account settings." show up in an *accessible* way - i.e. respecting tab order (and no JS)? I like the idea though, and suggested in #49 to introduce a dedicated page which could keep the link short "Click here if you are having problems ...". The link takes you to a dedicated page with more illustrating text. On that page we show either a dedicated "disable"-link/menu-callback or a link to the user profile (my patch in #49 went in that direction, but i'd do it *way* simpler now).

EDIT: i think i raise a similar question like Everett in #69 :)

Patch (addressing review in #65)
- constants removed
- keeping the elseif ('child', 'parent' and NULL are possible modes; null value occurs when an admin page [that should normally be a "child"=in the overlay] is opened directly via URL)
- re-wrapped comments
- changed link text to: "Click here if you cannot access the overlay. The overlay (and this message) can be permanently disabled in your account settings."
- introduce a helper function for the renderable array (incl. converting l() to renderable array), adjusted overlay.tpl.ph

This should cut it. If we link to the user account edit form (like the previous patch already did), then there's not even a need for a message or any kind of toggle, IMHO.

Copy of markup for link from the DOM:

<div id="overlay-disable-link"><a title="All administrative pages open in an overlay window. Click here If you cannot access them." class="overlay-exclude element-invisible" href="/user/1/edit?destination=admin/structure#edit-overlay-control">Disable administrative overlay</a></div>

1. The title attribute is an unreliable method of presenting information related to accessibility, since most screen-readers, keyboard only usrs, etc., do not have access to an anchor's title.

2. This appears to work as expected: link appears at top of DOM and top of iFrame, link takes user to profile edit page and lands on Overlay option.

Looks like if we can get the wording on the link correct we are good to go.

Asked for wording help http://twitter.com/chx1975/status/24496311046

If you have problems accessing administrative pages in this overlay: click here. You can permanently disable the overlay on your user account page.

So far this is the shortest, by far: You may turn off the administrative overlay and dismiss this message in you account preferences. (based on josiahritchie's , i just changed the "or" to "and")

Mixed in Everett's and yoroy's suggestions.

re #75: There's no message any longer, just a link.

"All administrative pages open in an overlay window. If you cannot access them, disable the administrative overlay in your account settings."

The requirements set by Everett are met?

• Communicate that overlay exists (check)
• What it does (check)
• How to disable it(check)

So RTOTHEBC!

Oh I misunderstood, there's only 1 link to show. 'You may' is unnecessary and I don't think we have to explain that the message will disappear either.

"Turn off the administrative overlay in your account preferences."

Hmm, that's rather blunt.

"You can turn off the administrative overlay in your account preferences."

Do we have to specifiy the destination of the link though? Seems more important to give a hint as to why you'd want to disable it:

"Disable the overlay if you have problems accessing administrative pages."

Seems good. Action first and enough context to decide on whether you want to.

Oops

@yoroy Hah, I think we are cross posting, last patch is ok or not?

Yup, sounds good to me

Looks good!

+++ modules/overlay/overlay.module	14 Sep 2010 18:28:40 -0000
@@ -258,6 +258,42 @@ function overlay_page_alter(&$page) {
+  if ((!isset($user->data['overlay']) || $user->data['overlay']) && user_access('access overlay')) {

I've added the isset() + TRUE condition, because I assumed that an administrator could mistakenly save a user's account, in which case the option would be unintentionally set. To account for both scenarios (no annoying link after configuration), I think we'd have to add a $user->uid == $account->uid check to overlay's hook_user_presave(), so as to not ever save that value in case it wasn't changed by the user himself/herself.

+++ modules/overlay/overlay.module	14 Sep 2010 18:28:40 -0000
@@ -258,6 +258,42 @@ function overlay_page_alter(&$page) {
+          'class' => array('overlay-exclude', 'element-invisible'),

d'oh on the .element-invisible. Looks like it would be a good idea to postpone this issue on the other one then, since duplicating all the CSS that has been added previously really does not make much sense.

Powered by Dreditor.

1. Didn't realize element-invisible was in use, my bad. This needs to appear on focus.

2. There does need to be a way to make the message disappear (but I do not see this as critical, although others might). The message should only be able to be made to disappear with an explicit action by the user of either disabling the Overlay or disabling the message.

@design_dolphin we already decided on the text.

Postponing on
#897638: Make .element-invisible work for focusable elements like links

I completely missed this before @sun pointed me to #897638: Make .element-invisible work for focusable elements like links.

Adding accessibility tag.

+1 for David's suggestion

Administrative pages are configured to open in an overlay window. If you cannot access them, disable the administrative overlay in your account settings

This is what the screenshot looks like in Firefox with the text as per the patch applied in #76 & also the patch I rolled up for #897638: Make .element-invisible work for focusable elements like links but both patches need to be changed if we're changing around the name space to use .element-invisible-focusable

Ok, here's a new patch which goes snugly with #897638: Make .element-invisible work for focusable elements like links and also uses the new text provided by @David_Rothstein.

The attached screen view is in English displayed RTL, so it looks a bit silly.

Still needs to address #85.1

So using something like this instead:

+++ modules/overlay/overlay.module 14 Sep 2010 18:28:40 -0000
@@ -258,6 +258,42 @@ function overlay_page_alter(&$page) {
+  if ((!isset($user->data['overlay']) || $user->data['overlay']) && user_access('access overlay') && $user->uid == $account->uid) {

To check the value in "case it wasn't changed by the user himself/herself."

Since the other issue is going t be committed, can we get a patch up for #84.2? #84.1 is now adressed with the other issue.

Hide message - should be enough, or something like that.

Adjusted patch from #93 to incorporate #85.1 (altering hook_user_presave and conditions in _overlay_disable_link).

If other users' preferences shouldn't be altered by anyone but themselves, the form-element for overlay preferences should not appear for anyone but the user him/herself (or be disabled with an explanatory text), IMHO - hence the adjustments in overlay_form_user_profile_form_alter().

Re: #96 - just to clarify, comments #84.2 and #85.1 aren't 100% the same thing: there is no "dismiss"-functionality intended. All hinges on the overlay preference being set - the message disappears thereafter. Consensus seemed (to me) that having two invisible-focussable-accessible links (edit your profile AND dismiss message) is unnecessary and difficult to accomplish in a way that is accessible, "non-confusing" and efficient.

So how do peopel dimiss the message? I am confused, if it can only be done by disabling the overlay you are creating an issue for those it is accesible.

Hi Bojhan, the message is dismissed after the user chooses (i.e. saving your profile w/ "Use the overlay for administrative pages." checked) to keep the overlay activated as well as after the user chooses to disable the overlay - i.e. the message is only shown until a choice has explicitly been made (i.e. the user profile saved by the user him/herself).

I think its obvious thats not what we want? A user having to save his profile, keeping the checbox checked is total magic that will make the message dissapear.

Since we know that JS is available when this message appears (since the Overlay is loaded), can we use some jQuery goodness to show both links when either has focus?

The first link what we have now, the second link to dismiss the message.

bojhan, just to be clear: the message will disappear no matter what you choose as your preference - as soon as you save your profile the message will disappear/be dismissed - and only then. It seemed to me to be the emergent consensus (after #54) that an anchored link to the user profile should suffice.

Personally, I'd prefer for this: A) one short link on top ("Having problems accessing administrative pages or want to dismiss this message?") taking you to B) an explanatory page with some text and C) links or a form for enabling/disabling overlay (and/or dismissing the message). Am happy to roll a patch for that (improving on my patch #49 and incorporating some #54 etc.) - but i'm a new to this and certainly don't want to step on anyone's toes/push my approach :)

Briefly why injecting a second "dismissing"-link is, IMHO, is not really a good solution: assuming e.g. a keyboard-only-user - the second link ("Dismiss this message") would become only "visible" once you tab out of the first link ("'Administrative pages are configured to open in an overlay window. If you cannot access them, disable the administrative overlay in your account settings") breaking the "context" of what the user is really dismissing. If that is no concern, we can just add a callback "dismissing" the message - happy to provide a patch for that, too :)

EDIT: @Everett: the link (or links) is also be displayed in the "parent" page not just in the "overlay" therefore we cannot assume JS to be available for a solutions, IMHO.

I will leave this up for Everett to decide a direction on.

@frega

Why are we showing the links when JS (and therefore Overlay) are not present? That isn't a major problem, but really makes no sense to me.

My suggestion:

1. Only show the links when Overlay is actually present.

2. Show the link in current patch, and a second dismiss message link.

3. Show both links when either link has focus.

Any technical limitations or usability issues with this approach?

If we want the links only to show when JS is enabled, we'll have to move stuff to overlay.js. The issue started off in CPH with such an approach, but @seutje mentioned some issues with this approach ("it seems to cause the link to be rly late in the tab order") which drove the solution "server-side". Can have a look at that again tho ... keeping both links visible shouldn't be v. hard w/ jquery (and maybe a bit of css) ...

@frega

Thanks for the explanation. Would everyone be content with this solution:

1. Links are generated server-side (like they are now).

2. Links are not hidden by default.

3. Links are hidden with jQuery / CSS before page is displayed in browser.

4. Focus on either link displays both links.

5. Only users without JS enabled would see the links without the links receiving focus. This only until they click "dismiss". Of course these users will be confused, since for them admin pages never load in Overlay.

I think that this is optimal, satisfies all requirements, only drawback is (5).

Won't (5) effect all mobile users without propper JS?

I want the bot to test #97.

@bojhan

I think the answer to your question is yes. So, we need to decide if this is an acceptable trade-off.

I've been able to successfully inject the links via JS in the "parent"-pages; they respect tab order and both links are visible when either is focussed which would solve #104 points 1-3. I've successfully tested keyboard accessibility ("tabbing") in FF3.6 & Chrome5 on Linux, but I'd need help&feedback on other platforms/setups ... i'll post a patch in a few minutes.

Thanks for #97, @frega! That's exactly what I had in mind.

We have a .js-hide class, but we don't have a .js-show or .no-js-hide class.

- There should be just one link to the user account edit page. To dismiss the note/link, a user simply saves the user account.

- We should not use JavaScript to inject this note/link, nor to hide it. It slows down page rendering performance for sighted users. Ideally, we'd use a .js-show class, but that's fairly hard to implement, especially in combination with the .element-hidden and .element-invisible classes. If at all, then the only acceptable approach for me would be to render the note/link with .element-hidden by default and use overlay-parent.js to change .element-hidden into .element-invisible.

I clearly understand why @bojhan is unhappy with the UX with just one link in #100. On the other hand, having toiled to get the JS-injection and the focus magic working (or working at least in my setup :) I have to agree w/ @sun, that the complexity and performance tradeoff is probably not negligible and maybe not worth it (albeit the sighted users will incur this slow down only until the first time they save their profile) ...

Well, new patch expands/builds on #97 but uses JS to inject links into the "parent" pages. To avoid patching the system-behaviours.css-patch (from #897638: Make .element-invisible work for focusable elements like links) in this patch, I have duplicated some css in overlay-parent.css and overlay-child.css (could be moved to system-behaviours.css in due course). You need to apply that CSS-patch. Hope this helps, otherwise jsut ignore it :)

Patch:
- Adds a second link: "Dismiss message".
- Adds new menu callback (overlay/set/%/%) - enables/disables the overlay directly; please clear menu cache
- Injects the links into the top of the page w/ JS
- Makes both links visible when one of them is focussed w/ JS

Todo:
- Decide: is this worth the hassle?
- Proper accessibility test (keyboard accessibility/tabbing works in my setup FF3.6, Chrome5 - Linux)
- If we do keep two links: Should they not read "Disable overlay, if you have problems with accessing administrative pages" (link to /overlay/set/0/...), "No, I am fine, dismiss this message" (/overlay/set/1/...)
- Provide better "URLs" - overlay/enable overlay/disable and overlay/dismiss instead of a "cryptic" /overlay/set/ and according feedback "You have now enabled the overlay" etc.

Thanks for working on it. I'm opposed to introduce a giant new page callback that does the same as saving the user account does. We definitely need more custom user settings, and an easy way to toggle every single of them, but implementing this properly is D8 material at this point. We need CSRF protection for such quick toggles. Which leads us directly into the working space of #755584: Built-in support for csrf tokens in links and menu router, which is definitely NOT D7 material anymore.

I don't know what the technical issues here are or what is D8 stuff. Sun states "To dismiss the note/link, a user simply saves the user account." - I have no idea how a user would know that?

As @Bojhan is pointing to, the current text has no call to action for users that find the overlay usable:

Administrative pages are configured to open in an overlay window. If you cannot access them, disable the administrative overlay in your account settings.

Instead, the only call to action is for a very small subset of users to disable the overlay. Everyone else, should they follow exactly what the message states, would never get rid of the message. That's less than ideal. I think most users are going to expect a "dismiss this message" link when confronted with a system message they can't resolve.

If it's really impossible to add the second link, the current copy needs to be reworded to something like:

Administrative pages are configured to open in an overlay window. You can confirm or disable this functionality in your account settings.

Having not tested the patch, I have to agree with @bojhan, some performance trade-off (only until the user selects the dismiss link) seems reasonable to me to improve usability.

However, 99% of all users will likely never know that these two (4 really 2 x 2) links exist. So, that kind of throws a wrench in the situation.

I think this would be a good time to sum up where we are and where we need to be. Please provide comment. Particularly, provide comment on what problems exist with proposed solutions.

Summary of problem:

1. Overlay is broken for some users (it is in no way our fault).

2. We cannot detect those who need Overlay disabled, it will have to be disabled by user action.

Requirements for solution:

1. Users must not have to 'find' how to fix the problem that Overlay is creating for them.

2. Clearly communicate that Overlay exists, what it does (how it relates to Administrative pages), and how to disable it.

3. Provide a method to disable Overlay, and a method to permanently dismiss information in 2.

4. Limit interference in user experience for those for whom Overlay causes no problems.

Proposed solutions:

1. Where to generate links?

1.1. Generate two links on server to disable Overlay, and dismiss message about Overlay.

1.2. Generate two links through Javascript to disable Overlay, and dismiss message about Overlay.

2. What action do links perform?

2.1 Links activate menu callback to save user Overlay preferences (enabled or disabled).

2.2 Links take user to profile page where they manually set and save preferences.

3. To whom are links visible?

3.1 Show message to all users by default.

3.2 Hide message (only showing to screen-reader users and when links receive focus).

Hi Everett, thanks for summarizing the issue. My comments:

#97: falls short of your stated requisites (e.g. two links) and gives little "call to action" or guidance; but is a clean and simple patch.

#113: fullfils your requisites (2 links), but is relatively complex (still needs testing for full accessibility) and duplicates some functionality by introducing a user setting toggle menu callback for the overlay.

We could cut the injection of links via JS from #113, but without an additional menu-callback, we could not and should not have a second link to dismiss the message.

A compromise approach (incorporating #97 and short of #113):
1) Have one slightly longer link: "Administrative pages open in an overlay. If you are having problems opening these pages, want to learn more about the overlays or want to disable this message click here.".
2) The single link goes to admin/help/overlay#acessibility
3) overlay_help is expanded to include a section explaining the accessibility problems and state clearly: "If you want to dismiss the message regarding the overlay or need to disable the overlay, please go to the overlay preference in your [user profile], check or uncheck the overlay preference and press save".

The compromise avoids an additional callback and at the same time allows for a better "call to action" than a single link at the top of every page could; but no "one-click" dismissing or disabling.

Rolling a patch like that is a question of minutes - but i don't want to flood this issue w/ another alternate patch :)

@frega

I would be happy with what you have proposed. I think the question for some others will be that there are several clicks required to dismiss the link / message.

Help module is optional and not guaranteed to be enabled. Instead of linking to a help page and from there to the user account edit page, why don't you simply link directly to the user account edit page, also using a fragment/jump target, and put the help text below the checkbox?

I like @Sun's suggestion. Again, some others might want a menu callback so that the message can be dismissed in one click. I, for what it's worth, do not care if multiple clicks are required to disable overlay, as long as the path is short and clear.

FYI: update in class name for .element-invisible (focusable) class.

http://drupal.org/node/897638#comment-3468306

Liked @sun's suggestion and adjusted #97 accordingly; rerolled the patch to reflect change in #897638: Make .element-invisible work for focusable elements like links (apply this new patch); small wording changes to link at the top:

Administrative pages currently open in overlay windows. If you cannot access them or want to dismiss this message, click here to set your overlay preference.

Patch extends description of the overlay option in the account settings *only* for users that haven't set their preference with this:

Accessibility notice: If you have problems accessing administrative pages opening in overlays, disable the overlays by unchecking this option and saving your profile. To dismiss the message shown at the top of pages to screen reader users, leave the option checked and save your profile.

Please advise on wording; maybe we should always show the first sentence of the accessibility notice and only append the last sentence (dismssising the message) to users that haven't set their preference as they are the only ones seeing it?

@Bojhan and @Everett - is this still too subtle or do you think this will be sufficient?

Can you upload a proper .patch?

sorry - proper.patch now attached.

Thanks!

+++ modules/overlay/overlay.module	20 Sep 2010 18:46:25 -0000
@@ -62,8 +62,11 @@ function overlay_theme() {
+    // Display overlay preference fieldset only if current user can access the
+    // overlay and only on current user's own profile.

"Display Overlay preferences only if the current user can access the overlay and when a user edits the own profile."

+++ modules/overlay/overlay.module	20 Sep 2010 18:46:25 -0000
@@ -62,8 +62,11 @@ function overlay_theme() {
+    if (user_access('access overlay', $account) && $account->uid == $user->uid) {

The faster condition should always come first; i.e., let's flip the conditions.

+++ modules/overlay/overlay.module	20 Sep 2010 18:46:25 -0000
@@ -62,8 +62,11 @@ function overlay_theme() {
         '#type' => 'fieldset',
         '#title' => t('Administrative overlay'),

btw, this fieldset violates UX guidelines - there's only one form element in it.

+++ modules/overlay/overlay.module	20 Sep 2010 18:46:25 -0000
@@ -77,6 +80,14 @@ function overlay_form_user_profile_form_
+      // Provide an extended description for users that have not yet set their
+      // overlay preference explaining how to disable the overlay and how to
+      // dismiss the message shown to screen reader users.
+      if (!isset($user->data['overlay'])) {

I think we should always display this help in the regular description.

+++ modules/overlay/overlay.module	20 Sep 2010 18:46:25 -0000
@@ -77,6 +80,14 @@ function overlay_form_user_profile_form_
+        $form['overlay_control']['overlay']['#description'] .= '<p>' . t('<strong>Accessibility notice:</strong> If you have problems accessing administrative pages opening in overlays, disable the overlays by unchecking this option and saving your profile. To dismiss the message shown at the top of pages to screen reader users, leave the option checked and save your profile.') . '</p>';

1) No paragraphs.

2) We can skip the "Accessibility note" prefix.

3) When appending to the regular description, this can be shortened:

"Disable this option, if you have problems accessing the overlay. Save your profile to dismiss the accessibility message shown at the top of every page."

+++ modules/overlay/overlay.module	20 Sep 2010 18:46:25 -0000
@@ -85,7 +96,9 @@ function overlay_form_user_profile_form_
+  // Only allow user's own overlay preference to be set.

"Prevent someone else from setting the overlay preference for a user."

Powered by Dreditor.

Good review too, sun. Omit Needless Words. :-)

"Disable this option, if you have problems accessing the overlay. Save your profile to dismiss the accessibility message shown at the top of every page."

Confusing, since most people will never see the message.

Hi sun, thanks for the swift review. I'll rectify the points in the next patch; just to clarify regarding the wording - can we maybe drop the first sentence and alter the '#title' of the checkbox to the following instead:

"Use the overlay to show administrative pages on top of the page you started from."

Description for users not having set preference would be shorter and read then:

"Disable this option, if you have problems accessing the overlay. Save your profile to dismiss the accessibility message shown at the top of every page."

Description for users having set the preference (i.e. having disabled the message shown to screen reader users)

"Disable this option, if you have problems accessing the overlay."

I think the language from #130/#131 needs to be reworked:

• The wording of the #title should match the wording of the notice:

  Use the overlay to display administrative pages.

  The word overlay means to lay above: there's no need to be redundant.

• The current wording of the description is pretty awkward: the action most users should take should come first and it reads like Yoda-speak. I propose this instead:
  

  To dismiss the accessibility message shown on the top of every page, leave this option enabled and save your profile. If you have problems accessing the overlay, disable this option.

  and
  

  If you have problems accessing the overlay, disable this option.

Let me try to move this issue a bit, I think we are very close - and we shouldn't worry to much about copy writing. My suggestions

Top title "All administrative pages open in an overlay window. If you cannot access them or want to dismiss this message, see your account settings."

Option description "Disable this option, if you have problems accessing the overlay. Save your profile to dismiss the message shown at the top of every page."

Lets recognize this though :

• We have two actions in 1 link = usability issue
• You have to save an unchanged form to disable a message = usability issue
• The overlay has a wierd presense on the account settings (one fieldset)

Fairly sure we can't fix all those issues, especially the wierd workflow we introduce by having one link just sucks. But we have to get this solved soon and maybe these trade offs are oke? Anyway, I only really wanted to comment on the copywriting.

Indeed this seems like some pretty heavy trade-offs.

@Mart Trapp & Bojhan - the word "overlay" can be a noun, but is most commonly used as a verb. As a noun it refers to a veneer or an ornamental covering. As a transitive verb is means to superimpose. The module name "Overlay" is a Drualism and cannot be understood as a proper noun outside the Drupalsphere. I really wish we would stop using the word "overlay", its "Overlay". Its usage as a common noun is wrong and very confusing to native English speakers unfamiliar with Drupal.

"overlay window" is not bad, but "a superimposed window" is far more comprehensible.

I think Mark Trapp's version is actually better...

To dismiss the accessibility message shown on the top of every page, leave this option enabled and save your profile. If you have problems accessing the overlay, disable this option.

...however, we must really think twice about using the word "overlay" as a common noun - we're all far to close to this be fully objective about it.

@133 - totally agree, there are some major usability trade-offs here. We really need to try and solve some of these - not least of which the rather strange option to save my user profile to dismiss a message I cannot see.

I understand that "Overlay" is a druplism, but quite honestly "a superimposed window" sounds horrible and I do not understand why you see it more comprehensible.

The overlay is a concept relatively new on the web, unless we represent it as some kind of giant modal dialog I do not see us coming to an easy solution on this one. Lets not forget the bigger picture, its to get people to simply move on - administrative pages that open in "something" that you can disable if it's not accessible. Untill we test it, it will be hard to know what the word overlay conceives, going with "Overlay" is somewhat oke - as long as its preseeded by administrative pages open in ...

Well, "superimposed window" was just a silly example, however its more comprehensible because they are familiar words used correctly. I'm certinaly not saying we shold use it!

I think I wasn't clear enough - I really think we should use "the Overlay", so at the very least we have correct grammar. Its better to coin this as a proper noun and run with it everywhere.

Hah, darn issue queue communication. Oke,

If it's capitalized on the assumption that—at the point the the word is used—the user doesn't know what it is, it seems like the word should be defined at the time of usage. "The Overlay" is no better than "overlay" or "overlay window" if the user has no idea what "the Overlay" refers to.

But the proper way to reference the window seems like a weird thing to be discussing this late in the development cycle.

My original point was based on the assumption that "overlay" is clearly defined already (either by convention or earlier documentation) by the time the user encounters it in an actionable item, and that trying to sneak in a half-hearted definition of it in the title of an option on the user profile page, after the user has acted on a message that doesn't define what "overlay" refers to, makes for an awkward piece of copy.

I like Bojhan's copy for the notice to disable or dismiss; the title of the option could be changed to match that new notice:

Open all administrative pages in an overlay window.

with a slightly-modified description I originally suggested:

To dismiss the accessibility message shown on the top of every page, leave this option enabled and save your profile. If you have problems accessing the overlay window, disable this option.

The problem is that the description describes a set of actions that is not the same as what the option is for. Ideally, the description should be used to clearly explain what the overlay is, not how the checkbox and saving the form is connected to seemingly unrelated tasks (dismissing the accessibility message or making Drupal accessible).

But the core issue is that it's really awkward that the only way to dismiss the notice is to perform an unrelated task.

If were are so unhappy with the placement of the overlay preferences on the account settings page (@bojhan: "weird placement", @sun: "violates UX guidelines"), can we move it a separate tab (MENU_LOCAL_TASK) like e.g. the shortcut-module?

This would certainly give us more freedom with the form ... i'll roll a small patch if that seems reasonable and productive to anyone but me :)

@frega: Absolutely not. A fieldset containing a single form element is already bad, so an entire new page containing a single form element can only be worse.

Let's incorporate Bojhan's suggestions from #133 and be done with this, please.

Yeah I definitely think saving an unchanged form in order to make a message (that you can't see..?) go away is very very strange. Especially because a user could easily save their profile for a completely different reason altogether (change their email, contact settings, etc), and that action would disable the message unintentionally. Maybe make it radios..?

* Display administrative pages in an Overlay window
* Disable administrative Overlay windows

And have neither selected by default..?

Also, I realize that the lingo has been a bikeshed-fest, but I'd like to just point out that specifically mentioning accessibility concerns in any of the messages isn't necessary is it? Plenty of people will want to disable them even if they're not experiencing accessibility problems.

edit: Also, there's a typo in the last patch:

+    // Display Overlay preferences only if the current user can access the
+    // overlay and when a user edits the own profile.

Should be "edits their own profile."

All administrative pages open in an overlay window. If you cannot access them or want to dismiss this message, see your account settings.

Remove the comma in the second sentence, this will read better if its allowed to run on, i.e.:

All administrative pages open in an overlay window. If you cannot access them or want to dismiss this message see your account settings.

Disable this option, if you have problems accessing the overlay. Save your profile to dismiss the message shown at the top of every page.

If the intention is for the 2nd and 3rd phrases to be a description they should be in brackets, else remove the comma and allow this to run on, its does not read correctly (it's grammatically wrong, there should not be a pause here), i.e.:

"Disable this option (if you have problems accessing the overlay). Save your profile to dismiss the message shown at the top of every page."

or...

"Disable this option if you have problems accessing the overlay. Save your profile to dismiss the message shown at the top of every page."

I think we are all waiting for a patch, mine or jeffs suggestions in #142 will be fine!

1. I would agree that two links are better than one, but I can go either way.

2. I am quite happy with everything that David has suggested above.

3. #897638: Make .element-invisible work for focusable elements like links has been committed in case anyone didn't notice.

@David There is no time, to endlessly discuss and build consensus. Unless you have a patch up its unlikely to get comments on the code direction.

In the last patch (#131) when I check the option to use the Overlay I am not redirected back into the Overlay when I save my profile. I have to go back to another non-overlay page to re-enter it.

This is assuming I have unchecked the option, then changed my mind and want to re-enable it.

In agreement with David. We need to come to consensus on the solution. I was hoping that my issue summary in #118 would help us get there, but it has only in part.

I discussed this issue with Bojhan on IRC this morning. We have agreed on the following implementation.

1. Two links.
   1. "Disable the Overlay on your profile page if you have problems accessing administrative pages"
   2. "Dismiss this message"
2. Links to appear only when Overlay is present (when Overlay parent and / or Overlay child are loaded
3. Both links to be visible when either receives focus.
4. Links to be preceeded by invisible heading "Options for administrative Overlay", we can work on copy.
5. Disable link to go to Overlay section of profile edit page.
6. Dismiss link to dismiss message and store setting so that message is not displayed again for user.
7. Message display setting should be separate from Overlay state setting, so that message is not unintentionally dismissed by saving profile page (as one would do when resetting a password, changing e-mail address).

I have spoken to Everett about this and I think his sum up is pretty complete. I hope this will bring the discussion out of its stall, its mostly a technical discussion really.

Is there a show stopping reason why the "Disable Overlay link" cannot be a fast toggle so users never need to deal with their profile page.

- any performance reason why not?
- am I thinking like a sighted person - would this be in fact more problematic for the visually impaired?

The only real problem I see with #150 is that the only users likely to disable this message are the visually impaired - I haven't read the implementations at all in the this thread so I do not know if these links are being added server side or client side - if they are client side this seems like a performance hit to end users who can use the Overlay, server side probably not so bad.

@Jeff

Nothing show stopping about making the disable link a callback. However, it is nice to give the context of sending the user to the profile page so that they know where the option is should they wish to re-enable.

As far as performance, it is a hit, not sure how much. I'm not too particular, I suppose they cold be in parent and child tpl.php files.

One note I forget to add above, and I will add here for completeness is that the links should appear at the top of bothe the parent and child frames, so that it is more likely that they will be found.

As agreed w/ bojhan in IRC this mornign, a patch implementing 6 out of 7 points from #150 (building on #113 and some #131) attached.

Approach taken in point 7 of #150 ("Message display setting should be separate from Overlay state setting") had little support earlier and would - in the vast majority of cases - lead to the message *never* being dismissed, as few sighted users will ever encounter the "Dismiss" message (as pointed out in #152).

Patch introduces a toggle-callback (that i know @sun has been opposed to ...) but i hope this helps to move the issue along nonetheless.

TODO:
- Markup and wording for "invisible heading"
- Wording of status message after dismissing message.

@Frega

Haven't registered a user account on D7 recently, however, isn't the first step in the workflow, after getting registration email, to set and save a password for the account? This means that virtually all users will unintentionally dismiss the message after logging in for the first time. This isn't going to work.

Let me know if I'm just completely wrong, or if we can think of a better method of implementing this.

Thanks again for rerolling.

I agree with Everett, its not fool-proof enough, even if the user does not have access to the Overlay initially, they might escalate their privileges later on and acquire access, in which case they are immediately stuck.

Note: A patch is RTBC that removes the ARIA roles from Overlay. Discussion of the patch should be had in the other issue.

http://drupal.org/node/716612#comment-3494762

You might want to apply this patch before rerolling again so that the patch you write is more likely to apply when the other is committed.

Everett, you're right: unblocking a (new) user (with 'access overlay' permission) has the user save the profile (implicitly the overlay preferences); this would dismiss the message before the user properly realises what's up.

Rerolled the patch using a separate flag and a dismiss callback. #150 should now be covered. Markup and wording for "invisible heading" still needs work. Includes applied patch from 716612 as advised in #158.

Overall not very happy with this: a) another flag and b) the accessibility message adds but for most users this message will be "unknownable" (if relatively light) bloat on admin pages; I added a dismiss-link to the checkbox description on the profile for sighted users (but who'll use that).

Maybe this calls for a different approach - will find you/bojhan in IRC to discuss it :)

rerolled #159 (to heed #158, sorry).

1. I'd look into re-using the styling for the 'back to the blocks page' link that is shown on the blocks demonstration page

2. sounds like a 'needs work' :)

re: 3. The text doesn't have to explain what the overlay is. It's function is:
"Go look for the Przwalski button over there if you have trouble getting to stuf in here."

We don't need to explain the finer details of the *cause* of the problem. We only need to provide the name of the*fix* that can be obtained elsewhere. Basically: "Go look for this word on that page and flick its switch". That's all.

Please avoid working on 3, for now - lets focus on getting all those technicalities out of the way.

What about something like:

@jeff Why not go with yoroy's suggestion of using the back to blocks page styling, rather than creating a new one?

Its not new, its the Skip Nav styling which David suggested in #163. The left aligned/blue background of the blocks page styling doesn't work very well because the Skip Nav appears first, then this message, so its visually jarring to go from one to the other (it actually looks really bad), its much better visual flow if its centered (the colors could change of course, but its still quite visually jarring - which could be a good thing?).

@Jeff

Can you please provide a description of overlay-disable-message.png?

Thanks

@jeff I agree that doesn't work very well. Not sure if creating such a intrusive element is favorable - but I'd generally be oke with it, since its a hacky element anyway.

@Everett:

The links are contained in a box which is very dark gray, which contrasts with both the overlay modal background (semi transparent black) and the overlay page (which is white) - it needs to do this because it can overlap both. The box is centered and has width of 36em, so it can grow if the text size is increased.

There is no border or any other "width adding" styles applied to this box, we can't add any width or height to it or it will show all the time. Instead the links have some padding and margin.

The links are white, to contrast with the dark gray of the containing box and are underlined on focus. Both links are set to display block, so they are not inline, the Dismiss message is therefor on a new line at the bottom.

OK, for the wording: Let's lead with the "if" phrase. If it includes me, I get more interested as I keep reading. If it excludes me, I know I can skip the rest of the sentence and find something that does matter. Basic good technical communication.

Following that approach:

If you cannot operate this interface:

1. Go to [link]your profile[/link].
2. Find "Overlay."
3. Disable it.

[link]Close this window[/link].

With this approach, all I need to know about overlay is what I've just read: it's the setting to look for on my profile page and disable if this interface is giving me trouble.

Just read the thread, plus the ancestor. Quick summary to save others the time: summary in #118, agreed approach in #150, active (and nearly there) patch in #163. 3 outstanding issues listed in #163.

I have tested the patch:
- It works.
- It matches all the requirements in #150 except #150.4 (see below).
- The workflow is not too annoying, although I haven't tested it with a screenreader.
- Only problem is 163.2: we fall out of the overlay after dismissing the message.

Outstanding issues:

163.1 - visual styling. no comment.

163.2 - odd redirects after you click to dismiss the message. This is what happens:
- Dismiss link goes to http://example/overlay/dismiss-message?destination=admin&token=blahblah
- Redirects to http://example/#overlay=admin (with the message saying "You can change your overlay settings at any time by visiting your profile page.") but outside the overlay.
- Redirects to http://example/admin (without the message) again outside the overlay.

This needs to stay within the overlay after the message is dismissed, and the second redirect needs to be stopped.

163.3 - text needs some work. 150.4 stipulated 'Links to be preceeded by invisible heading "Options for administrative Overlay", we can work on copy.' I think this would help. Specifically, it should say: "Accessibility Options..." or "Screenreader options..." The current text, without the accessibility context, makes it sound like there's a problem with drupal/that we've shipped something buggy (I accept there's an argument there, but let's not have it in the UI).

[EDITED to correct what I said about 163.2).

@willmoy, on your comment on 163.3, I proposed "If you cannot operate this interface…" because it addresses the accessibility issue directly. Although other patches address the issue of whether people using screen readers can operate the interface, that's not the only accessibility issue. As one example of another accessibility issue, people with attention deficits might find the interface distracting. To work efficiently, they might have to turn overlay off. I'm sure I could think of others; even if I can't that doesn't mean there aren't others.

At the same time, people who don't know what accessibility is won't be wondering what that is, whether it affects them, and how changing a profile setting could improve the situation. (Yes, those people are out there — a friend recently encountered a web developer who said, "How could my site not be accessible? It's online!")

And as for trying to avoid implying "that we've shipped something buggy," I don't think we are implying that. Many people might assume that the problem is that noncompliant browsers won't render the interface properly — and, in fact, that is part of the problem. Briefly stated, this interface has three problems:

• The standards we're relying on aren't mature.
• Not all browsers support our techniques. (Older browsers especially have problems.)
• Not all forms of assistive technology support our techniques. (Older versions especially have problems.)

But even that brief explanation is too much to put on the page. And even if we did state those facts, someone could still infer that the problems resulted from something we did wrong, not from the constantly evolving nature of Web coding and design.

163.2 - redirects.

AFAICT, redirecting the entire page from the overlay (as now) won't do, because it loses anything the user may be doing in the underlying page, which is hard to justify. I'm not sure if it's possible to do the redirects in the overlay but the most elegant solution from the user perspective is probably to call overlay_user_dismiss_message() via AJAX, like overlay_ajax_render_region().

...which I don't have time for right now, sorry.

-        '#description' => t('Show administrative pages on top of the page you started from.'),
+        '#description' => t('Show administrative pages on top of the page you started from. Disable this option if you have problems accessing the overlay.'),

I don't think this should change. While mentioning accessibility concerns within the .element-invisible section makes sense because it's designed for screen-readers, the checkbox on the user account page is for everyone, and many people will want to disable the Overlay even if it is perfectly accessible.

There's also a grammatical error here, ending the sentence with a preposition. Should be "Show administrative pages on top of the page from which you started." although I admit that might sound confusing.

That's my only input, I can't actually test the patch ATM. I just wanted to throw this out there again, because while Overlay accessibility is a big part of all this, this particular issue isn't necessarily specific to that user-group. Screen-readers need a direct correlation between the Overlay itself and where to disable it yes, but ALL USERS need a clear way to disable the Overlay.

@David_Rothstein: Sorry, I didn't mean to imply that you had added that extra sentence to the description, in fact I was aware that it had been added much earlier. Glad we're in agreement on that point though, I had mentioned it earlier in the issue but it got glossed over.

As for the grammar, I'll cede to you on that point though I didn't see anything in particular when browsing through some of the results of that Google search. I'll leave it alone though, as this issue has been about verbage for far too long. :-P

I'm uploading a screencast of the different workflows associated with this patch: http://vimeo.com/15544526.

Here's a rough transcript. This is from a freshly installed HEAD with the patch from #176 applied:

- Go to the config page because we want to do some administration
- Tab once for the skip to content, Tab twice for the message this patch introduces.
- The message consists of two parts: 1 link to go to the place where you can disable the overlay. And 2: a link to do nothing but simply hide the message itself

Now lets click that first link, because we really want to disable this overlay thing:

- click
- look for the setting, oh quite nicely jumps to the right position in the page
- lets uncheck that box then and save
- Voila, back at the page where we started from, but now without the overlay. beautiful
- lets tab to double check…
… So far so good.

Now lets check the case of wanting to enable the overlay again via this route:

- Lets say I remember that this setting lives on my profile page, so lets go there
- Check the box to start using the overlay again and save.
- We stay on the profile page, which is ok
- But now: let's directly click a toolbar link for an admin page
- None of them opens in the overlay
- Lets visit another page in the front end first, and then go for an admin page:
- The overlay is used as intended.

So:
- dismiss link works as intended
- workflow for disabling the overlay works well
- the interactoin for re-enabling the overlay is not ideal yet.

Using the same styling as for the skip-link makes perfect sense (would have been nice to make these and the 'blocks demo back link' consistent with eachother but lets pretend I didn't say that and work on the actual critical ;-)

Needs work for:
- add styling
- what's up with the "I'm not opening in the overlay before you hit another page in the front end first" scenario?
- maaaaaybe tweak the wording a bit, but lets not go there yet.

Oh, and another thing: I made the screencast using Chrome. I tried Firefox but tabbing there never got me to show the skip-link nor the overlay message. Instead, the search box in the underlying Bartik page gets focus. This is on a Mac, would be good for someone to double check this: when in overlay, hit the tab key. do you get focus on elements in the overlay or on elements in the underlying page?

Yoroy suggested using the blocks page message style so I tested with this and its pretty nice actually, I changed the skip link to match so its all consistent.

I am adding a screenshot and a patch for Seven only - we probably should make up some default style to go in Overlay module also, for now I just styled Seven - I also made a short video to show tabbing between the skip link and the disable messages (FF on Win7) - http://bit.ly/cAdV6M

The patch just adds styles - you need the patch in #176.

Following on from what yoroy says about FF in Mac, I have many issues tabbing in IE7 also. For example, when the link is totally unstyled (link in yoroys video) in IE7 when I focus it I can see the background page being pushed down - which is very strange - both the skip link and disable messages appear to be in the wrong layer - no amount of positioning and z-indexing will pull them up above the Overlay background (they are always below the translucent layer and thus pretty borked in IE7).

Agreed! #931730: Enabling 'use overlay' setting on profile page does not immediately use overlay for admin pages I suspect this is more general than this specific checkbox, but there you go :)

I am very wary of this direction, it is very intrusive and even more so with this patch. Is this really what we want? To me this message should not render the underlaying contents unusable - which the proposed does, this because its overlaying the actual content. Another point is that the styling and shape of this element is not found anywhere else in core, the blue color is - but using a "modal" with a bottom bar for dismissal is not a common element.

I would highly favor if we go for something far less intrusive, for example the "back to blocks admin" styling and shape we have on the blocks demo page. I see the patch already tries to use the blue, but the position and shape is the most important part.

@Bojhan -I'll keep playing around with it, it quite tricky to position this element correctly and account for toolbar/shortcuts draw states + font size - if we apply positioning to this we'll need to thoroughly test that out in case it gets hidden behind the toolbar etc etc under certain circumstances.

A visualization to my idea

I recenlty installed d7-dev for a looksee. I think I would have been confused by the message "Disable the overlay on your profile page if you have problems accessing administrative pages."

From a first encounter frame of reference, I might be mumbling these questions. What is an overlay? Where is the overlay? Is this interface I'm looking at the overlay? Everytime I click on a link, I get this interface... Does that mean I'm having problems accessing the administrative pages? Is there something on the administrative pages I need that I am not getting in this interface which is going to cause me problems?

Its longer, but I think this would be more instructive.

"For alternative access to the administration pages, disable this administrative overlay on your profile page."

This might work.

"For alternative access to the administration pages, disable this overlay on your profile page."

I think "profile page" needs to be a link to the profile page.

I like the look of #187. I'm wondering how desirable and how difficult it would be to have the message appear above the administrative menu until dismissed?

Working on a new design patch now - #187 is mostly doable but I need to know if we want this to push the content down or live in its own layer, I think it actually looks better if the content is pushed down. The radius styles are not doable because the dismiss message can wrap when the browser width is narrow (also when the font size is very large).

IE7 nightmare report - this is a separate issue altogether - right now when you start tabbing the underlying page gets focus in IE7 (maybe IE8 also, have not tested), this is very serious issue because if you "click" (hit enter) on the skip link you will be taken to the main-content of the underlying page not the overlay page. This is an extremely bad ass situation and can someone else confirm/deny, would be so good if this is an artifact of my system.

Adding two screenshots to show it on one line and wrapping, + a pretty rough patch just for testing. I have removed the full stop on the dismiss message in these screenshots and my font-size is quite large (text re-sized up a few notches in my browser).

Note: this question of whether to push the content down or not is curcial to how this can be styled, its gets somewhat harder to achieve the "all on one line and centered" style if we want it to overlay the page.

Jeff: I reported something similar in #181: In firefox when I tab, the searchbox in the underlying bartik page gets focus :(

yoroy - found this issue, seems to be appropriate: #841184: "Skip to main content" link doesn't work correctly in the overlay

Am I right to assume this is totally blocked by #841184 ?

yep, let's figure out what we can do about #841184: "Skip to main content" link doesn't work correctly in the overlay first. That has to work reliably before we can use the same approach for disabling the overlay. Better figure out if that is fixable at all over there before we continue here.

Let's continue work here if possible. The skip link problem is nontrivial -- I've spent several hours on it and gotten nowhere -- but it absolutely has to be fixed. And whatever we come up with for that issue should fix the ordering problem here too. So let's get the toggle links working and styled correctly, and worry about tab order in the other issue.

Bojhan: Are you 100% sure you hate the styling in #182? Remember this only appears if you're tabbing through the page and the focus is on that link. The second you click or tab outside the links, it disappears again. So it shouldn't render anything unusable at all, which AFAICT is your main concern with it.

The reason I'm leaning toward the style in #182 is that it seems a lot easier to stick in the overlay module and have it apply generically to all themes. And IMO that generic styling is more important than the seven-specific styles. Users will see this message on every page view - not just when overlay is open - so it needs to look good no matter what the theme is.

The #182 CSS is a lot less fragile than later iterations because it does not rely on being positioned as accurately, its just "near the top" so to speak. Later styles rely on being positioned near pixel perfect to pull off the rounded corner "reverse tab" look, and this could be fragile.

@ksenzee I am 100% sure its too intrusive. Which is why I favor #189.

Isn't the whole point to be intrusive at this juncture in a users journey? Whats your proposal, that we be diminutive and hope they don't miss it :P Personally I am not a huge fan of the dialog look an dprefer the reverse tab, it stands out a hell of lot in any regard.

What about pushing content down vs overlaying the content. To me it makes more sense to push it down, this feels more clean and does not obscure anything.

I think the blue is enough to make it stand out, its quite a unique element in terms of position, color but more importantly in terms of occurrence - it only occurs on the blocks page - making it something you rarely see thus stand out. It has to be important but not necessarily intrusive, its a small nuance but it creates a very different setting to what we design.

I am not sure I follow your last suggestion Jeff? Perhaps an example? I would love to know if the code is good to go, I am not sure why we are holding back the critical on styling.

Try the patch in #189, that should give you pretty much what you are looking at in 189 screenshots - instead of overlaying the overlay like a dialog would, the message will take up space and thus push the entire page content down to make room for itself.

I'll test the patch in #176 for functionality tonight.

As for the style, "nothing matters very much, and very few things matter at all," or to put it another way, I don't think think the issue should stay critical just for that.

Why would you not try the last patch?

Because the patch in #176 is the last one that actually works. The rest are add-ons for styling only.

/me shuts up

Lol! Bogged down, but will get there in <6 hours.

On wording, OK with David Rothstein's wording in #176, except flip the "if" statement in front in the first bullet:

This site displays administrative pages on top of the page you started from.

-If you have problems accessing administrative pages, [link]disable the overlay[/link] on your profile page.
-[link]Dismiss this message[/link].

Trust me — it's clearer with the "if" before the "do." If you need more background, look for Ginny Redish's book on Writing for the Web.

And a preposition is a fine word to end a sentence with. If you think otherwise, look for and read through John McIntyre's blog for many, many screeds against that deeply ingrained grammatical falsehood.

Just one thing - its much easier to style this is the entire sentence is a link - so the whole thing is focusable, we can't add any width/height to the containing DIV and can only do this on the anchors when they come into focus.

Score 1: it installs against HEAD.

On IE6, Win XP: register a new user (and new users having the right permissions to see the overlay and toolbar).

- The message appears when I tab

Good news: dismiss works—
- Go to the edit my account page in main window, and change the email address slightly (but without saving)
- Click configuration on the toolbar and that loads in the overlay
- Tab through to dismiss this message
- Something happens (screen flickers, possibly reloaded) and I'm back on the overlay on the config screen, with the message saying it's been dismissed and I can change settings on the overlay page
- The message no longer appears on tabbing through
- Close the configuration page on the overlay and I'm taken back to the view my account page. The edit page is closed and the half-done change are gone. But this is what happens even if I just load the overlay and then close it again, so isn't a bug with this patch.

Good news: disable the overlay works—
- Go to the edit my account page in main window, and change the email address slightly (but without saving)
- Click configuration on the toolbar and that loads in the overlay
- Tab through to 'Disable the overlay...' and press enter
- Taken in the main window to my edit account screen. This is reloaded so that my unsaved change is lost.
- Untick the box and press save.
- Returned to the configuration page outside the overlay. There is a message saying "The changes have been saved."
- Click Home
- Click Configuration on the toolbar, and it loads outside the overlay.

Bad news: turning the overlay back on doesn't have immediate effect—
- After switching off, go into account | edit
- Select use the overlay, save
- Message saying saved
- Click configuation, opens in main window
- Click a few others, stays in main
- Click home, click account | edit, opens in overlay (I could swear it didn't used to, as the notes above say*)
- Close that and configuration opens in the overlay

* So I tried a fresh install with the patch and edit account opened in the overlay. Human error, probably?

Other questions:
1- When you are redirected to the edit account page to unclick the overlay box, whatever the underlying page was is lost. Does that matter? It would annoy me if I were, for example, halfway through editing a node. It's not critical because it's so unusual but it's certainly inelegant.
2- Small thing, but might it be a good idea to modify the account editing page to add a more specific message when it's saved so that the overlay is being disabled, saying that administration pages will no longer appear in the main window?

Other than fixing it so that turning the overlay back on works immediately I think this functionality is ok but it would be good if someone else could think about those two questions.

I haven't looked at the code at all yet.

People are welcome to create users at http://overlay2.fullfact.org/ to test for themselves. Would be good to follow the steps above in other browsers and esp. with a screen reader for usability.

It would annoy me if I were, for example, halfway through editing a node...

Is there actually a way to do that (am I missing something here), if the Overlay is enabled then it gets used for adding/editing content always doesn't it?

I just spent a couple hours reading some of this issue's history, and referenced issues. I will spend some time next week trying to help keep this moving.

@David_Rothstein: since #176 is your patch, and from what I can tell, the latest functional one, do you want to re-roll it to include feedback since then, or do you feel that's still the important one to be reviewing?

I think Jeff and me agreed upon #189 just need to clean up some bugs that accompany such style.

I'm happy with 189, be good if someone else wants to drive that forward, I am very busy the next few weeks.

Thanks. I'll re-roll #213 with #189, and post a new summary of the issue (building on the excellent summaries already here, like #150).

Question: Why is it necessary/desired for the message/link to become visible on focus? As I understand the issue, the message/link is for screen reader users using legacy/lame screen readers that are unable to handle any kind of modal dialog. Does the message benefit anyone who is able to see the screen? Sure, people who can see might want to disable the overlay just because they don't like it, and they can do that by disabling the module or by going to their account profile. That's not what this issue is about though. This issue is about addressing the problem that people using some screen readers cannot do that, since both of those steps involve using the overlay by default, so it's a catch-22. The message/link is there to:

1. Notify someone that there might be content that's not being read to them.
2. Give someone a way to edit their account settings outside of the overlay.

So, again, this message must be audible, but why does it ever need to become visible? Just wondering what the motivation is for figuring out how to style it.

@effulgentsia

The only thing I would add to David's explanation is that there * may * be some keyboard oly users who for some reason (user agent) might not be able to properly use Overlay. This will provided the added benefit to them of an easy path to disable for their account.

I can't necessarily point to users or UAs that might result in this being a problem, but since there has been practically no usability testing of this UI component with keyboard only users it is likely better to err on the side of caution.

This is just a straight combo of #213 and #189. Review coming in next comment.

Overall, I think the patch has come a long way. It feels like we're getting close to consensus, and a genuine solution to the accessibility problem without sacrificing usability. Here's some problems I found in my testing:

• If "access overlay" permission is available to the anonymous role, then the links are still shown, but they don't make any sense, because they try to update the user record. Is it the case that we need to force "access overlay" to be disabled for anonymous, or do we want an alternate link that disables the overlay for the session only?
• If the user has JS disabled, the links are still there and focusable (and I'm guessing a screen reader would read them). But if JS is disabled, there won't be an overlay. So, should we add a display:none for no js? If so, what's the best practice way of doing that? We have a html.js selector, but no html.no-js selector.

Also:

+++ modules/overlay/overlay-child.js	18 Oct 2010 23:07:29 -0000
@@ -57,6 +57,15 @@ Drupal.behaviors.overlayChild = {
+    ¶
+    // Show all focusable links if focus is inside the accessibility wrapper.
+    $('#overlay-disable-message', context)
+      .focusin(function () {
+        $('a.element-focusable', this).removeClass('element-invisible');
+      })
+      .focusout(function () {
+        $('a.element-focusable', this).addClass('element-invisible');
+      });

I don't understand the code comment. What's an "accessibility wrapper" and why do I want to show all focusable links in it? Perhaps something like: "There are two links within the message that informs people about the overlay and how to disable it. Make sure both links are visible when either one has focus."

+++ modules/overlay/overlay-parent.js	18 Oct 2010 23:07:29 -0000
@@ -25,6 +25,15 @@ Drupal.behaviors.overlayParent = {
+    // Show all focusable links if focus is inside the accessibility wrapper.

See above.

Finally, the changes to Seven's style.css look pretty extensive. But all site pages (including the home page) can be an overlay parent. So that means Bartik, Garland, and all contrib themes are gonna have to do something similar? Yikes! See also #639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes, where I'm worried about that same problem existing for the "Skip to main content" link. Is there any way to put more into core CSS files, and require less theme-specific rules to make a "visible on focus" link visible and legible?

Thanks for the review. I don't have answers but I can tell this needs work :)

This includes code to address my concerns from #220 regarding anonymous and no-js access. I don't know if the CSS code added to overlay-parent.css is any good, so please feel free to change that.

Regarding the last paragraph in #220, I escalated #639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes to critical.

See #213 about remaining todos regarding bike-shedding the text. On the one hand, perhaps that's not critical. On the other hand, we need to freeze strings in RC1, so maybe it is.

I dont think we need to change the text anymore its good + people stop calling it bikeshedding.

One minor suggested improvement to the text (despite #223):

If you have problems accessing administrative pages on this site, disable the overlay from your profile page.

The previous text was ambiguous in that it could be interpreted that the overlay was "on your profile page" when in fact it was the control to disable it that was on that page... Using "from" instead of "on" eliminates this minor potential confusion and does not lose any of the previously intended meaning.

The CSS introduces loss of spacing above the page title:

Before:

After:

Testing in Safari 5 I have focus in underlying Bartik when in overlay. I do get to the message in overlay in Seven eventually, but that's 21 tabs for skip to content and 22 for this dismissal.

Chrome works immediately. Nice. The overal workflow feels pretty good.

Actually dismissing the message works fine in both browsers.

I can't tab through anything in Firefox, but that may well be me.

FF, Safari, Chroe all show the missing top margin for the page title.

We're not changing the text at this point.

@todo:

- Needs CSS review and work on the title margin
- Needs review of functionality in Firefox and Safari (and IE!)

Effulgentsia in #222 asks for someone else to improve the CSS part of the patch: needs work for that

Whatever helps to get the right folks in here :)

Nice CSS simplification was achieved for #skip-link in #639460-60: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes. It would be awesome if someone could see whether something similar could be done for the CSS in this patch, as well as also implement the necessary CSS for Bartik and Garland (#222 contains only CSS for Seven, but all themes can contain the new links added by this issue). Again, we need to make sure to not overwhelm contrib theme developers with an "OMG: I need to implement several dozen lines of complicated CSS, or else my theme isn't accessible" first impression of Drupal 7. To the extent that theme CSS in #222 is just about making it look good, we're fine. But to the extent there's rules that are required for it to be accessible, let's make sure we move those to system files.

Also #841184: "Skip to main content" link doesn't work correctly in the overlay is now RTBC, so we're really quite close on this.

Yes, I think this should definitely work out of the box (be usable) without themers having to do any work at all - and right now a lot of the usability is tied up in the CSS for Seven (because this was prototyping, but it should not get committed like that).

I tried pulling the CSS out of Seven and into overlay-parent.css, and I was totally unsuccessful. So we could use a CSS wiz here.

@ksenzee The hide overlay link that you see when you first tab is the one rendered inside the overlay. So overlay-child.css is the file that the styles should go into. overlay-parent.css stylings don't pass through the iframe insulation to the contained.

I'm going to take a stab at this and should have a patch up shortly.

James, don't we need to style the hide overlay link on the parent page as well? (Of course, that one can be below the toolbar... blech.)

I think a relevant question here for the UX team is - do we consider this a type of "core message", in which case it may be legitimate to apply heavy styling like other core messages.

We can go two ways on this - minimal styles in core, just enough to make it usable i.e. probably just a link color, (e.g. white) + hover/focus style (probably underlined), OR treat like a core message and give it everything so in effect themers would do nothing.

Given a choice, as a themer, I'd punt for the latter and treat it like a core message - I just don't want to theme admin stuff anymore in my themes unless I am specifically building an admin theme (in which case I can still override it if I feel the need to, which I doubt I would anyway).

Here is my patch. I think I've addressed all the remaining issues. Any concerns about the specifics to how I handled the core themes should probably be filed as bugs against those themes and outside the scope of this critical issue.

1. I solved the issue in #225 where the -20px top margin was pulling the page content up
2. I moved the layout styling from Seven's style.css to overlay-child.css like ksenzee was trying to do in #230
3. I checked on ksenzee's comment in #232 and found that no hide overlay link is added to the parent frame, so there was no need to style it.
4. I added default styling for each of the core themes for the disable overlay link. I tried to match the styling of the skip to content link in each theme. For Garland I matched the styling of the RTBC patch here http://drupal.org/node/639460#comment-3640256.
5. For Jeff Burnz concerns in #235, I've only added layout based CSS properties to overlay-child.css. The global CSS has the bare minimum of styles in it. Color, borders, border radius, and backgrounds are all defined in the themes.

I've not done any cross browser testing other than Chrome, FF 3.6, and IE9 that I always have open on my dev system. So testing is still required.

This looks super to me, but I defer to the CSS experts. I would love to get Jacine's input on whether there should be some default styling in core. I tend to agree with Jeff that this should be styled by default. If you don't use the keyboard you might not even know these links exist, let alone be moved to style them. But since we're trying to do as little default styling in core as possible, it would be great to hear from more themers.

And I'm still really confused about James's #3. If you just go to the homepage (while logged in as an admin) and start tabbing, you should see these two toggle links appear right after you leave the skip link - even when the overlay isn't open yet. Don't we need to style that as well?

This is my DOM structure on the home page

http://www.screencast.com/users/james.elliott/folders/Jing/media/906dcb3...

There is no disable overlay link there. Am I trying to work off an outdated patch?

The patch no longer applies, probably since #639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes was committed. I think I managed to apply it correctly though.

I would love to get Jacine's input on whether there should be some default styling in core. I tend to agree with Jeff that this should be styled by default. If you don't use the keyboard you might not even know these links exist, let alone be moved to style them. But since we're trying to do as little default styling in core as possible, it would be great to hear from more themers.

Okay, you asked :)

I was expecting to actually see a message, not for it to be hidden. Once I saw it, I was surprised because it looks really messy in general. I'm really not a fan of this as hidden text. We are literally scattering easter eggs throughout Drupal. I don't understand why we are going out of our way to hide this, instead of just making it a regular message, but 236 comments into the issue, I'll just say that once and move on to what I was called here for (sorry, had to say it).

I absolutely agree 100% this needs to be styled. I don't think it needs to be heavily styled though, and it should not try to mimic a skip-link because it's purpose is completely different. Why are we not just letting this <div> just stack underneath the toolbar (or at the top of the page when there is no toolbar), and setting a background and foreground color? I think we are really overcomplicating this.

Here's a review of the latest patch:

+++ modules/overlay/overlay-child.js	29 Oct 2010 20:55:22 -0000
@@ -57,6 +57,17 @@ Drupal.behaviors.overlayChild = {
+    ¶

whitespace.

+++ modules/overlay/overlay-parent.css	29 Oct 2010 20:55:22 -0000
@@ -37,6 +37,18 @@ html.overlay-open .displace-bottom {
+ * Hide the message about disabling the overlay from users and screen readers

Both are users. How about: "Hide the message about displaying the overlay from all users..."

+++ themes/bartik/css/style.css	29 Oct 2010 20:55:24 -0000
@@ -255,6 +255,23 @@ ul.tips {
+  font-size: small;

+++ themes/bartik/css/style.css	29 Oct 2010 20:55:24 -0000
@@ -255,6 +255,23 @@ ul.tips {
+  border-radius:0 0 10px 10px;

+++ themes/garland/style.css	29 Oct 2010 20:55:24 -0000
@@ -338,6 +338,26 @@ span.form-required {
+  font-size: small;
+  border-radius:0 0 2px 2px;

+++ themes/seven/style.css	29 Oct 2010 20:55:24 -0000
@@ -178,11 +179,43 @@ pre {
+  font-size: small;
+  border-radius:0 0 10px 10px;
+  -moz-border-radius: 0 0 10px 10px;
+  -webkit-border-top-left-radius: 0;
+  -webkit-border-top-right-radius: 0;
+  -webkit-border-bottom-left-radius: 10px;
+  -webkit-border-bottom-right-radius: 10px;

1. font-size: ems need to be used over small
2. border-radius:
   • This line should always be last (after -webkit)
   • A space is needed between the property and value.

Also, I really don't see the point of any of the border-radius properties. I can barely see any difference and I think it just makes it messier looking.

Powered by Dreditor.

I would love to get Jacine's input on whether there should be some default styling in core. I tend to agree with Jeff that this should be styled by default. If you don't use the keyboard you might not even know these links exist, let alone be moved to style them. But since we're trying to do as little default styling in core as possible, it would be great to hear from more themers.

Okay, you asked :)

I was expecting to actually see a message, not for it to be hidden. Once I saw it, I was surprised because it looks really messy in general. I'm really not a fan off this as hidden text. We are literally scattering easter eggs throughout Drupal. I don't understand why we are going out of our way to hide this, instead of just making it a regular message...

Agreed. If you have CSS enabled and are a keyboard only user you might not find this message. if you don't use the keyboard you almost certainly will not see the message (not that this is really that big of a problem).

In #189 we stepped away from skip link styling to use the blue color used for the block region demonstration page link. With the blue style the border radius will make a lot more sense than it does now.

My personal preference is for the message to push the page content down rather than sit in its own layer on top.

Don't think it makes a lot of difference in this situation to use keyword font sizing or ems, keyword has the distinct advantage of locking the relativity to the browser default as opposed to relying on the theme.

The min-width is set to 700px - how does that par with Overlays overall min-width?

Need a re-roll.

Don't think it makes a lot of difference in this situation to use keyword font sizing or ems, keyword has the distinct advantage of locking the relativity to the browser default as opposed to relying on the theme.

I like consistency and this isn't inconsistent. The patch also sets "small" in some themes and ems in another. I don't really see why relativity to the browser default is more important in this case than with anything else, but it's a pretty minor issue in the scheme of things, so I'll stop complaining about it. :)

So... I think most of us agree that default styling should exist for this, so I suggest we take the "Stark" approach first and have the themes adapt from there.

'#prefix' => '<div id="overlay-disable-message"><h3 class="element-invisible">' . t('Options for the administrative overlay') . '</h3>',

Not sure why this isn't in a theme function, but can we get a class to style against for this that tells us it's focused? We can't easily style the container, i.e. adding padding or borders, without introducing visible issues otherwise. I tried adding a class in the code below, but it doesn't work inside the overlay:

    $('#overlay-disable-message', context)
      .focusin(function () {
        $(this).addClass('overlay-disable-message-focused'); // Any suggestions for a better class name would be appreciated. :)
        $('a.element-focusable', this).removeClass('element-invisible');
      })
      .focusout(function () {
        $(this).removeClass('overlay-disable-message-focused');
        $('a.element-focusable', this).addClass('element-invisible');

      });
  }

Any ideas? :(

Also, this is not desirable:

'#title' => ' ' . t('Dismiss this message.'),

If you choose to style the links with text-decoration: underline, the space looks abnormal (see screenshot). If the space is removed the links are just on top of each other. That space should be added to #prefix, so this doesn't happen:

        '#prefix' => ' ',
        '#title' => t('Dismiss this message.'),

#841184-55: "Skip to main content" link doesn't work correctly in the overlay explains that it will likely be desirable for some keyboard only users to disable the Overlay (IE6 / IE7). Right now the ability to do this is on their Account edit page, or invisible in the Overlay (made visible on focus). We're asking people to hopefully find something that is an Easter egg to do what they need to do.

Now, we have done our best to put the links in the best possible place in the DOM, so that it is most easily discoverable, like hiding the Easter egg in a really easy place to find. But, let's not forget it is still hidden.

Edit: Although I have always wanted (as much as I recall) this message to be visible, I was content about it's being hidden, because we were unaware of issues for keyboard only users at that time. This is no longer the case. The purpose behind element-inivisible.element-focusable is * not * to display content to keyboard only users, it is a method of making sure that the focus doesn't get lost in a focus black hole. If there is content that a sighted keyboard only user may need (like the 'show row weights' link on table drag) it needs to be visible.

Can someone summarize why showing this would be preferable and why showing this would be helpful, I am not clear why this would be the case. I can see this scenario - keyboard user is having many troubles (say IE7 user), they can see this message so keep tabbing in order to get to it, which will happen eventually?

Assigning to myself. I figured out the problem JS I was having, so I'm working on a patch.

PS - The current approach (hiding the text on every page) is really growing on me. It provides an opportunity to solve what I consider to be a very annoying issue, which is that the Overlay is completely useless for administering Drupal on iPad/iPhone, and other mobile devices, etc. Using media queries, and overlay classes, it's actually really easy to show this message under very specific circumstances. That makes me happy.

I think hiding this message for mouse-only users - and possibly showing it on touch-screen devices, as Jacine suggests - is going to serve everyone well, no matter what their circumstances. I have tried and tried to think of accessibility concerns we haven't addressed that will keep sighted admins from using the overlay easily, and outside the touch-screen issue, I can't come up with a single one. Cognitive impairments, limited mobility, color blindness, seizures, low-literacy sighted screenreader users, attention deficit, low-vision high-contrast environments, keyboard-only, mouse-only, mouse+keyboard combination -- none of it should be a problem. If you can see the screen at all, and you're using a browser from anytime this century, you will be fine. Either the overlay will work for you, or it will be patently obvious how to turn it off. For example, some keyboard users will find it inconvenient to use the overlay with IE6 and IE7. Not impossible, mind you; just inconvenient. Those users will see this message loud and clear at the top of every single page.

So I beg you all, please, pretty please, let's not revisit the question of whether these toggle links should be shown to mouse users. We're almost done with a patch that I believe will serve everyone's needs. And when it's done, we'll have finished every single critical issue, and we can release this amazing piece of software.

The overlay works fine on an iPad/iPhone/iPod Touch (and, likely, Android) with the patch in #878020-15: position:fixed prevents iOS devices from scrolling the Overlay. Displaying the message for them is really not necessary at all.

I agree with #244 quite strongly, I also have thought long and hard about this which is why I asked for good arguments as to why this is being raised again (showing the message by default). I can't see any real benefit, on the other hand showing this would add cognitive load to all users and be one more thing in the way of getting on with using Drupal. So I would ask also, no bikeshed on this please, lets get on with it and IF over the course of D7 this becomes an issue for some unknown/unforeseen reason then we revisit it in D8, otherwise this is looking good to go bar the shouting over style.

@Jacine - I just now realized why I used small font keyword (I was racking my brain as to why I would not just use ems), it was because the block region demo page link uses small, and I largely cut/paste the styles when I was prototyping.

@240 - this would be hugely helpful for styling these messages, any takers?

For example, some keyboard users will find it inconvenient to use the overlay with IE6 and IE7. Not impossible, mind you; just inconvenient. Those users will see this message loud and clear at the top of every single page.

Do we have * any * sighted keyboard only users in the community who can test this preposition?