This patch adds a little checkbox to allow users to opt-out of the overlay. Many users will not want the overlay for a variety of reasons - maybe they use a screen reader, maybe they use internet explorer 5, maybe they just don't like it. In any case, we should allow users to opt-out of the overlay in the same way we allow users to opt-out of the update module. It's fine to say that users can disable the overlay on the modules page, but many users will not know how to do that or will not wish to expend the extra effort.

This patch also allows the user to opt-in to the overlay in the case that the install profile does not normally include the overlay. The overlay checkbox is checked by default under profiles that use the overlay module (such as the standard profile), and is unchecked by default under profiles that do not use the overlay module (such as the minimal profile).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cwgordon7’s picture

Status: Reviewed & tested by the community » Needs review

Uh, whoops.

lut4rp’s picture

I just tested this with both Standard and Minimal installs on the latest HEAD checkout, works great! Anyone else got other thoughts?

michaelfavia’s picture

I personally don't think its necessary to add this option from a standard usability pov as you can already disable overlay functionality at the module and permissions levels (which i personally do).

I also fully understand and appreciate the irony of requiring the use of an overlay to disable overlays using either of these methods and maybe this is a nice concession to that for our friends with screen readers. In absence of a better solution i support it fwiw.

yoroy’s picture

It's fine to say that users can disable the overlay on the modules page, but many users will not know how to do that or will not wish to expend the extra effort.

I see no reason for a special treatment of overlay here, nor do you provide an argument for it that's specific to overlay.

cwgordon7’s picture

Issue tags: +overlay
cwgordon7’s picture

One major concern is accessibility, as one has to use the overlay to disable the overlay. If for no other reasons, it would be nice for screen reader users to be able to disable the overlay upon installation so they never have to use it. I've actually found that using the overlay degrades my user experience, so I'd personally prefer an easy way to disable the overlay upon installation. I believe that many other "power-users" will share my dislike of the overlay, and allowing those who know what they're doing to disable the overlay would be nice. Usability studies have shown that users who do not know what they're doing will prefer to stick with the default settings.

michaelfavia’s picture

Like i said. I hold the same preferences as charlie with regards to the overlay but i dont think THAT alone is a good argument adding yet another option. I do however think that the accessibility issue is a legitimate one and it was reaised at the core summit in sf two days ago.

Everett Zufelt’s picture

+1

Problem:

For some users the overlay is inaccessible, or offers a drastically degraded user experience. One group of users effected by overlay are users of certain assistive technologies.

When the overlay needs to be used to disable the overlay then some users may not be able to disable the overlay.

Solution

1. Correct the accessibility problems with overlay.

This is currently not possible for all users of assistive technology.

2. Provide a method of disabling overlay during the installation process.

This patch appears to accomplish this task in the best wayy that I can think of.

3. Provide a method to disable overlay, that does not require the use of overlay, after Drupal (default profile) has been installed.

I cannot think of a good method that would have any advantages over the current patch.

Bojhan’s picture

Either way this is not a solution for the problem. As we described in many accessibility issues now already. The best solution would actually be providing a page in the installer, allowing accessibility profile to be chosen (which is a long term solution) rather then this short-term solution, which would be a disgrace to Drupal its new UX.

Then again, give me a few minutes to provide a alternative solution

dmitrig01’s picture

Status: Needs review » Reviewed & tested by the community
Bojhan’s picture

Status: Reviewed & tested by the community » Needs review
aspilicious’s picture

Status: Needs review » Reviewed & tested by the community

#9 Bohjan whats the difference between a accesibilty profile and the checkbox?

yoroy’s picture

Status: Reviewed & tested by the community » Needs review

Thanks Everett, I was hoping for that summary. I know there's a big discussion behind this and comment #8 is the executive summary of our status to date. We are now discussing solutions in IRC :-)

Everett Zufelt’s picture

Status: Needs review » Reviewed & tested by the community

@bojhan

Your suggestion, of an "accessible profile" would address my second category of solution above "2. Provide a method of disabling overlay during the installation process". Can you explain the reasons that you believe your approach to have benefits over the approach offered by the current

The downside that I see to the accessibility profile (which is perhaps rhetorical), is that it initiats a concept of accessibility being equivalent to difference. This may only be semantics, as clearly we are needing to do something different for certain users, and the reason is accessibility related. However, different m

yoroy’s picture

Status: Reviewed & tested by the community » Needs review

aspilicious: not tying it to a single module?

proposal from the patch in #0:

Everett Zufelt’s picture

resetting status

Everett Zufelt’s picture

@Yoroy

Ideally, we will not need to disable * any * other aspect of core for accessibility reasons. An accessibility profile says "it's ok to have poorly accessible modules in core, we'll just disable them for the gimps and blinks". It is semantics perhaps, but we need to foster a culture of full inclusion and universal design, which has been improving in our community greatly. A more conceptually agnostic checkbox does this better than an "accessibility" profile.

deviantintegral’s picture

Would it be better for this to be a per-user option in overlay to allow disabling the overlay on a per-user basis? If not, we should rename this issue to indicate it's a site-wide install-time option.

Everett Zufelt’s picture

@deviantintegral

There is already an issue for case-by-case disabling of overlay: #659480: Per-user setting for the Overlay. The problem with that approach is that some people might have problems installing / configuring Drupal 7 with overlay enabled.

Bojhan’s picture

Sorry guys, but this is ridiculous - could we please take a step back and look at the bigger picture? We are now making a decision that impacts the initial UX of every single person that installs Drupal and with that could set a negative tone. If we care at all about UX or have learned anything in the last 2 years, we know not to rush decisions like these.

1. Does a beginning person or someone with disabilities know what an "Administration overlay" or "overlay dialog box" means? Probally not, so it would only be a useful description for the people in this issue or the few core developers.

2. Adding options to opt-out, should always be considered a short-term win for a long-term problem. With this problem the scope is obviously to fix the overlay problem within the next month, which we don't see happening (sadly) - so we have to provide an option or do something else about it.

3. So onto my solution, which is indeed very different and more intrusive - but does hold long-term value as we encounter more unsolvable RIA accessibility problems.

accesability-page.png

So even without this issue, I think its worthwhile to have an information page on Accessibility in Drupal core. Don't mind the position of the link. I do think its fairly common for large systems or websites to provide an accessibility page with information about how its implemented.

the_accesiblity_choise.png

This could be an installation profile, or could just be a radio. The larger idea is that, instead of saying something meaningless about an overlay. We give proper direction on how to install an accessible Drupal install. And probally also a bit more information on how to use it.

Either way these are just some thoughts. Although I strongly agree with Everett his take on the semantics of this topic, given the actual reality I am unsure we can provide a better solution for issues which technically can not be tackled at this moment, obviously core would still hold high to its accessible to all standard.

Also please stop changing status to RTBC, this is a community process - if one asks for a Usability review I believe it is respectful to at least have a small discussion about it? Rather then a decision within 5 minutes.

Everett Zufelt’s picture

1. Does a beginning person or someone with disabilities know what an "Administration overlay" or "overlay dialog box" means? Probally not, so it would only
be a useful description for the people in this issue or the few core developers.

* Absolutely agreed, there needs to be a better way of communicating this information. Must weigh pros / cons of cluttering UI vs. fully informing users.

2. Adding options to opt-out, should always be considered a short-term win for a long-term problem. With this problem the scope is obviously to fix the
overlay problem within the next month, which we don't see happening (sadly) - so we have to provide an option or do something else about it.

* To clarify, for those who have not been part of the prior discussions. It is not that we aren't going to fix the accessibility issue, it is that it is impossible, at this time, to make a fully accessible modal dialog on the web.

3. So onto my solution, which is indeed very different and more intrusive - but does hold long-term value as we encounter more unsolvable RIA accessibility
problems.

* Would love to fully understand your solution, can you please exlain te images you've used?

So even without this issue, I think its worthwhile to have an information page on Accessibility in Drupal core. Don't mind the position of the link. I do
think its fairly common for large systems or websites to provide an accessibility page with information about how its implemented.

This could be an installation profile, or could just be a radio. The larger idea is that, instead of saying something meaningless about an overlay. We give
proper direction on how to install an accessible Drupal install. And probally also a bit more information on how to use it.

* Fully agree, we've been discussing this at the conf. I will put a page up on g.d.o/accessibility shortly about some of the ideas.

Bojhan’s picture

@Everett Sorry about not providing a patch for you to try out. I am unable to produce those so fast, but to explain the images the solution I purpose is having a link at the bottom of the installer which takes the user to a workflow optimized for accessibility. Which this means is that they will get a page with information about accessibility implementation in Drupal core, and a next step to install Drupal: Accesible... which means a disabled overlay and possibly some accessibility features (like exposing weight links?).

Everett Zufelt’s picture

@Bojhan

I like the idea that on the first page of the installer there is a link to a d.o page on accessibility for that particular version of drupal. Part of this can explain the overlay issue (for d7, hopefully it is possible to correct in d8). As for any other accessibility issue, I am unaware of any show-stoppers in d7, not that we have solved them all, but they are all solvable (we just might not agree on the solutions (smile)).

Bojhan’s picture

So I am not proposing a link to a d.o page, I mean a page within the installer that provides information on accessibility and allows people to install Drupal without the overlay (i.e Installing Drupal:Accesible).

There are indeed no show-stoppers, but I do imagine distributions to use this profile/option to install contrib modules in there accessible administration configuration.

Either way we are now discussing accessibility - which seems a bit off from the original intend of this issue to provide a opt-out for all users, mostly because of taste which should be handled off at #659480: Per-user setting for the Overlay.

lut4rp’s picture

I agree with Bojhan's suggestion here.
All accessibility features along with their descriptions (or at least the ones that will be made a choice during install) could go on in one page. The person installing could then select any of those features to enable, or the page could have a "Skip this step" button (which could come with a warning that you should care about these features)

Though, other than the Overlay, what else could go on that page?

Dave Reid’s picture

Should we make an install profile as a contrib profile and put it on drupal.org here? It could then be available as a distribution.

lut4rp’s picture

IMHO this should be in Drupal core and not a separate distribution. Accessibility is important.

Cliff’s picture

@Everett, for your benefit, the first image Bojhan posted is a mockup of the "Choose profile" screen with this basic configuration of the focusable elements:

1. Radio button for standard configuration (Start with commonly used features preconfigured)

2. Radio button for minimal configuration (Start with only a few modules enabled)

3. "Save and continue" button

4. Link: "Accessibility," in regular text with a contrast to background of about 3:1.

If you click the "Accessibility" link, apparently you go to the second mockup, which is another panel in the same interface. This time, title of the panel is "Accessibility" and there is this statement:

"Drupal has implemented the following accessibility features in its installer, use access keys. Information about accessibility can be found in [link]accessibility handbooks[end link] and in the help section of your Drupal administration."

Below this, there is a radio button labeled "Accessible: Install with commonly used features optimized for certain disabilities."

Then we have the "Save and continue" button, and, again, at the bottom of the page we have a link labeled "Accessibility" in regular text with a contrast to background of 3:1. (Now I'm starting to wonder if I correctly interpreted the role of this link in the first mockup.)

I'm guessing that when you hit "Save and continue" on this screen you go to the next item in the menu at left, which is "Choose language."

@Bojhan, if I have misrepresented this, please help me out. But, as you can see, I need help understanding these points:

  • How the two images and their components work together
  • What difference will occur if I leave "Accessible" on rather than turning it off
  • How that difference addresses the myriad issues that are possible obstacles to accessibility

Please clarify.

yoroy’s picture

What is happening here:
__

Screen 1:

page title: Select an installation profile
with
radio for standard,
radio for minimal,
and the "save and continue" button

(then quite some visual vertical spacing)

simple text link: "Accessibility".

__

…you click the accessibility link…

__

Screen 2:

page title: Accessibility
with:
A text listing the accessibility options/features, to be written.
A single, selected radio (?) button with a label and description that basically say "Yes, install with this accessible profile."

(again lots of visual spacing and what I think is an error in this second mockup:)

Again the text link "Accessibility". This either should be a "Back…" link (but with better text than that), or not be there at all.

__

"What difference will occur if I leave "Accessible" on rather than turning it off?"

That's the same question as "What happens when I choose to install the "Accessible" profile, no?
For now that means installing with Overlay disabled. And anything else we think we must do.

"How that difference addresses the myriad of possible issues…"

What Bojhan suggests is that installing an accessible Drupal is more than disabling Overlay. Thus more than one checkbox somewhere. The install profile approach acknowledges this and gives us the right spot to tackle the "possible myriad", by adding other out-of-box configuration options for accessibility. (And I think that's where the single radio button comes from, just like in the 'Choose language' step in the installer: anticipating more than 1 flavor of accessible profiles.

Everett Zufelt’s picture

There is absolutely nothing else that needs to, r should be, offered as a "accessibility" option other than installing with overlay disabled in d7. Just wanted to make sure that we're all clear on this. Educating about accessibility in the installer is good, making it look like accessibility is a strange, hard to understand, different, separate, unequal thing is very, very, bad.

Cliff’s picture

The concept of a list leaves a lot of work to be done before I can even decide if I think it will work. And as Everett has far more experience with D7 than I, and far more awareness of accessibility issues in particular, I have to accept his assessment that there is nothing more to cover.

But if there does turn out to be more, who is going to compile this list of situations in which the user must change a standard setting if they need a different interface for accessibility?

And what is the gamut of disabilities that this profile will consider? Cognitive disability? Mobility impairment? Blindness? Moderate low vision? Colorblindness?

As an aside, I would like to suggest that everyone who is suggesting that we have one profile for "us" and another for people with disabilities read Designing with Progressive Enhancement. If you can't get the book, at least read the introduction, which the publisher put online for free.

Whatever we do for Drupal 7, that book outlines the approach we need to take with Drupal 8.

yoroy’s picture

Clear. Which I think this solution caters for more elegantly, proposing itself as an opt-in choice, instead of an "undo stuff/overlay" checkbox? Are you saying that the 'accessibility statement' on top of the second screen would come off as derogatory? We don't want to spell things out, so agreed there.

Or does this interaction sound 'heavier' than the checkbox?

yoroy’s picture

#32 was in response to #30
Cliff: "checking the accessible box" at the install profile level gives us room to do it but I get the impression that 'install profile' comes off as putting "you guys" in the corner. That's not how it's intended nor how we want to design this. Thanks for the link.

Cliff’s picture

@yoroy, I'm sorry, but I missed an important point in my last message. Let's look at the first proposed screen, and please help me understand the interaction:

Screen 1:

page title: Select an installation profile
with
radio for standard,
radio for minimal,
and the "save and continue" button

(then quite some visual vertical spacing)

simple text link: "Accessibility".

[end of Screen 1]

Okay, here's the important point — and where this approach might fall short of being accessible: What happens when I click "Save and continue"?

yoroy’s picture

Drupal would install *with* Overlay enabled if you kept 'Standard' selected. Minimal profile has overlay disabled.

Ha, I see now I think :)

Cliff’s picture

Yeah — I never even get to hear "Link: Accessibility."

So the people who absolutely need this option won't even know it's there.

I haven't tried installing a site in so long that I would be the wrong person to judge whether the checkbox is in the right place, but I think the main issue here is not "checkbox or radio button?" but "where do we give people who won't be able to deal with overlays the option to turn them off?"

Wherever the switch is placed, if its label is too cryptic for newbies, the fix I would go for is a link to an explanation in plain language of the ramifications of this choice — not just from the standpoint of accessibility, but so I would know, as a person who can see perfectly well and has no mobility impairments, whether this option is appealing to me. And I should be told how I can turn this back on if I decide I was wrong in turning it off.

By addressing it clearly enough that everyone can tell whether they would prefer the option, we avoid singling anyone out. And that I think would address some of @Everett's concerns.

Everett Zufelt’s picture

@yoroy

Accessibility statements aren't necessarily bad, but without a use-case for an accessibility profile (one disabled module isn't a really good use-case) then I see it as opening up the potential for other "we can't / haven't / don't want to be bothered fixing the accessibility issue, so lets use that accessibility profile scenarios.

Recognizing that there absolutely needs to be a way to disable overlay, without the use of the overlay, I make the following suggestions, in order of preference. Note: this is only about install time, there are other issues to discuss enabling / disabling overlay on a er user / per admin page basis.

1. Have Overlay disabled in both install profiles (don't feel like I'll get a lot of support here). If we can't make a feature work for all members of our community, and anyone interested in our prodouct, then it * cannot * be a default feature.

2. An ability to disable overlay while installing / initially configuring. This, as @bojhan has suggested, needs to clearly identify what is being disabled and why it may be important for accessibility / screen-reader users. We'd have to work on wording here to get a concise yet meaningful statement.

3. An accessibility toggle on the profile page that provides a reference link to a document explaining the singular problem and what will happen to solve the problem if "accessible install" mode is selected. This provides the option that any future or contrib profiles can have Overlay disabled through the same UI control (pros and cons to this approach, as some contrib profiles may be for apps that depend upon overlay).

4. an accessible standard profile, which is the same as the default profile, but with overlay disabled, this needs to be again explained on an info page in the installer.

Again, I would stress, that as a community that prides itself on inclusion that the most appropriate method is to have overlay disabled in the default profile. Anyone can go and turn it on, not everyone can turn it off. This also means hat when overlay is enabled by a site admin they can be alerted to potential accessibility concerns that may be raised.

Everett Zufelt’s picture

Priority: Normal » Critical

Setting to critical, as not ensuring that there is a way to disable overlay for all install profiles will cause critical breakage of functionality (admin) for some screen-reader users installing Drupal.

My new post on GDO on this topic: Why Overlay should be disabled by default in all Drupal 7 profiles.

Bojhan’s picture

Priority: Critical » Normal

Sorry, but how is this diffrent from #716612: Overlay is not accessible to screen reader users ?

@Everett It saddens me you are constantly pressing on being inclusive, I hope that we have made it clear on many occasions that we are all about doing that. At the end of the day, I have too make sure the UX doesn't get sacrificed on whatever problems get trow at it, adding a link here, an option there is all about sacrificing UX because we can't make a decision or proper solution.

Please forget about install profiles, I am proposing a way for installing Drupal without overlay that makes sense. As you mention in #2, and thats all we are proposing.

This accessibility issue is indeed critical, but this issue is initially not about that. Its about allowing core developers and people who know of the existence of overlay to opt-out and with that creating a usability problem to all new users of Drupal.

So back to normal, we either change the scope of this issue to be about the accessibility or we continue in the correct issue. But at least I am not going to discuss the opt-out function, because we have wont fixed that on numerous occasions.

cwgordon7’s picture

In what sense is this issue "not about" accessibility? Accessibility is one of the reasons why an opt-out option is critical. I don't see why this issue has sparked so much opposition. We do not have a way to make the overlay accessible to users with screen readers. The overlay is a special case because one must use the overlay to disable the overlay, so we must allow these users to opt-out of the overlay on installation. This patch adds a checkbox akin to the checkbox that allows users to opt-out of the update module. Until we get an elegant solution to fix the overlay, we should at least allow users to uncheck that checkbox upon installation. So, as outlined in #8, an opt-out is the only viable solution here.

I'd also like to reiterate that this patch ALSO allows users who install profiles without the overlay enabled (such as the minimal profile) to opt-in to the overlay should they know they want it.

No one wants to sacrifice UX, but we have to make some difficult trade-offs. Fortunately, this is not a difficult trade-off, as we are degrading UX ever so slightly while making Drupal much more accessible for users with screen readers. I'd like a core maintainer to weigh in here, if either of them get a chance.

Bojhan’s picture

Title: Allow users to opt-out of the overlay » Allow users to opt-out of the overlay for accessibility

Because this issue started about opting out because some people might not like it, which is not an direction I agree with. The rest of this issue is indeed about accessibility, but I am unsure why you didn't just continued in #716612: Overlay is not accessible to screen reader users. I think you would agree with me that we should find ways not to degrade any experience, which is what I am proposing ideas rather then saying route 1 is the only way, because that is all secretly assuming that "opt-out" of overlay beside accessibility is something we all agree upon.

Everett Zufelt’s picture

Title: Allow users to opt-out of the overlay for accessibility » Allow users to opt-out of the overlay during installation for accessibility

@Bojhan

As far as I understand it there is nothing about overlay that we all agree upon. I continued this discussion here because there was a discussion and a reasonable patch to solve a significant problem.

There are two issues with the overlay. 1. At install time it needs to be able to be disabled. 2. After install it needs to be able to be configured on a per users / per admin page basis. So, I've changed the issue title to reflect this.

merlinofchaos’s picture

So now we're talking about the standard/minimal/accessible profiles in core. Plus, other profiles will have to have myprofile and myprofile_accessible if they wish to conform to accessibility standards, to control whether or not they install the overlay module. This does not sound like a scalable option to me.

I personally would much prefer an option on the config page:

[x] Do not enable features that may interfere with accessibility (or something worded better than that).

Cliff’s picture

@Bojhan and @yoroy, please understand @Everett's perspective.

You say you are all about being inclusive, but the default installation of Drupal 7 has a significant door closed to him. He has proposed a way to let him open that door.

@Bojhan, you propose a different way of opening the door. But I'm not sure you understand the significance of the exchange between @yoroy and me in #34 through #36: @Everett and other people who use screen readers won't even be able to tell that your proposed opening exists. Before their screen reader tells them that your "Accessibility" link is present, they will have already exited that screen. So, whether intentional or not, your actions are telling @Everett that he is not included in our community.

I know you don't mean it this way, but you're kind of like the restaurant owner who told a family whose daughter relies on a wheelchair for mobility that yes, there is an accessible entrance through the kitchen — and then, when he showed them that long path into the restaurant, noticed for the first time that near the end they had to cross one high step! Like the restaurant owner, you mean sincerely mean for your offering to be inclusive, but it simply isn't, and all the explaining in the world will not change that.

The bottom line here is that if we truly want Drupal to be accessible — and the buzz I'm hearing from DrupalCon (I'm not there, either) is accurate, we truly do — then our general approach needs to be this:

  1. Make sure the default installation of Drupal is fully accessible.
  2. If we can add slicker options that are a barrier to some people, go ahead — but let each person who wants those options turn them on. This is called progressive enhancement.
  3. If the accessibility of any feature of our default installation depends on software that some users might not have available or might choose not to use — regardless of whether that software is "Javascript" or "any browser that is not IE6" — then make sure that when that software is not available the system degrades to something that is also accessible. This is called graceful degradation.
  4. When it's called to our attention that we've guessed wrong on some feature and it is in fact a barrier to someone, we will do our best to redesign the system to remove that barrier.

So in the related issue, Add ability to easily disable overlays, @mfer was on the right track: For all affected users, this needs to be an opt-in feature.

However you slice it, it seems to me that we have two separable issues:

  • When people are setting up their administrative interface, how can we make it possible for them to turn overlays on? This patch seems to do that. In doing so, it makes Drupal accessible.
  • When a user's permissions make it possible for them to use overlays, how can we make it possible for them to turn that feature on? The other issue seems to be focusing on this point. And it's the solution they ultimately need to find. You see, the module needs to make it possible for me, the administrator, to give certain other users the permission to choose to turn this feature on. It should not make it possible for me to force other users to use an interface that might be inaccessible to them. If we make this happen, we will also make Drupal a tool that supports the creation of accessible systems.
Cliff’s picture

@merlin, it would be nice if we could give users a magic wand that would prevent inaccessibility from ever happening. But so long as we let them do so much as choose the wording of their links, the alt text for their images, or the colors of their theme, we cannot have that power.

The concept of an accessibility profile is wrongheaded. That is not what the people who raised this issue requested. It's the answer they're being told is the only one available. But it won't work, and it is not a way to ensure that Drupal continues to become the paragon of accessibility among content management systems.

Bojhan’s picture

@merlinofchaos Agreed, I spoke with Everett and we are not proposing an installation profile. But rather a more carefully chosen label and possibly workflow.

@Cliff I am sorry but I think you are getting the wrong picture. I fully understand Everett his perspective and so does yoroy. But as previously in other issues, the discussion is skewed towards not taking good care of accessibility and implying that we are excluding someone. We are not talking about which one is more important, they are equally important and we need to find a good solution. I am constantly surprised by how often finding a good solution, is actually held off by repeated discussion on the importance of accessibility, I think we all hold that standard very high.

Onto your points mentioned.

1. Unless you know a solution to modal dialogs, we can't.

2. Is also called optionoritus, meaning we open a can of worms allowing options for anything that is questioned.

3. Well as explained before, we can't degrade gracefully because of lacking RIA standards and implementation on this issue.

4. I have spend countless hours looking and researching, from the RIA drafts to other systems (talking to fluid project guys). I have done my best, I think Everett has done too - we on our own simply can't find a proper solution. There have been less then 10 people talking about solutions for the accessibility problem of the overlay, but over 20 about an opt-out feature for accessibility - isn't that wrong?

I honestly think many want to opt-out of the Overlay because they don't like it and that's what I am against on principle as it pollutes our install beyond imagination. The patch right now, doesn't help anybody because the label and description are only understandable to those reading this thread.

cwgordon7’s picture

I still think this patch is the best way to address the issue. But here's an idea. What if we put a "toggle overlays on/off" switch in the toolbar (or main menu if toolbar is turned off) and then saved that preference to a cookie and remembered it from then on? Would that be a universally acceptable solution? Or do we find that even worse?

Everett Zufelt’s picture

It would appear, from talking to Bojhan on IRC, and the comments here, that this patch is the best solution. This requires us to find some suitable wording for the UI control. I would still prefer disabled by default, but I can form consensus without that.

Will discuss wording further at accessibility BOF tomorrow and will get back to the thread with another comment.

Dave Reid’s picture

The recent analogies are out of line. Everett has done a wonderful job of enlightening us all to something we normally aren't thinking about all the time when working with Drupal. We're aware of the problem and we want to address it.

Cliff’s picture

@Dave, I'm sorry if my analogies seem out of line to you. That @Bojhan persisted in defending an alternative that could not possibly fix the problem indicated to me that he did not understand the impracticality of his proposal. I wasn't aware that an IRC session was going on; if I had been, I would have joined in.

@Bojhan, the four points I mentioned are basically the tenets of universal design. If it simply isn't possible at this point to undo the error of making overlays the default (at least, it's an error as they are currently implemented), I can accept that we need a different solution for Drupal 7. But if we are going to avoid similar problems as we move into Drupal 8, we're going to need to be mindful of the tenets of universal design.

By the way, if you haven't had a chance to, please do view the slides from Kate Lynch's presentation and the associated videos. I have seen many excellent presentations about accessibility, but hers is far and away the best.

@Everett, I'll be sure to connect with the BoF session by Skype so I can help work out the best wording associated with whatever solution you and Bojhan have worked out.

Everett Zufelt’s picture

After talking to a few people in the accessibility BOF this morning I think that the current fieldset title and checkbox tile work. I think that we should add a description to the form field with something like the following.

description:

The admin overlay provides specially themed admin pages on top of the real website. This module can cause problems for screen-reader users. You should disable this module if any admin users will be using screen-readers.

Open to recommendations, truncations, and general cleanup.

Bojhan’s picture

So we would probably want too focus on the form label, rather then just the description. We can probably remove the "you should disable this module if any admin users will be using screen-readers." - we encourage our copywriting to avoid, saying users what to do.

I am wondering whether we shouldn't contact Dries or webchick about this to possibly get some refocused effort on actually making the overlay accessible (as impossible as that may be) because either way we are really just violating 508's - 1194.21.

drewish’s picture

Personally I'm all for allowing people to opt out of this on a per-user basis. I'd love for this to be a default for regular users but I'd like to turn it off of my admin account.

Everett Zufelt’s picture

Priority: Normal » Minor

Didn't notice that this was set to normal priority. This is absolutely a critical issue. We can clean up the web of related issues (close them) when this is resolved.

To redefine the scope, this issue is specific to disabling the overlay during install for accessibility reasons, any other reason to disable the overlay (post install, or for any non-accessibility issue) shouldn't be part of the scope here.

It is absolutely critical that a method be provided to install Drupal without Overlay, and that users installing know that Overlay is a potential accessibility pitfall. This patch, once the wording is corrected, accomplishes this task to my satisfaction.

As I have researched, spoken on and written on the inaccessibility of Overlay / jQuery dialog many, many, many, times, I am uninterested in pursuing that path, unless compelling new data is presented to me showing that modal dialogs can be made to be accessible on the web.

Everett Zufelt’s picture

Priority: Minor » Critical
chx’s picture

Status: Needs review » Needs work

We worked a lot to streamline the installer as much as possible. Even removed clean URL, remember. Therefore we are not adding another checkbox. You have not yet even seen Drupal and need to make a decision you are not informed enough about -- what administration pages in what???

Equally, adding an accessibility link, we know users click every link they see and this is not something most users need to care about. It hinders them in their first install of Drupal.

Just say no.

Solve the overlay somewhere else which is not the installer. Add a disable per user to the user profile. Do anything at all but hands off the installer.

chx’s picture

#47 contains a good solution btw.

Cliff’s picture

Status: Needs work » Needs review

Okay, being relatively new to this process, I don't know who trumps whom — Bojhan or chx.

At any rate, chx is right except for one point: We do need a simple toggle somewhere, but that toggle should let users turn this feature on, not off. Unless we take this approach, we cannot make Drupal 7 conform with WCAG 2.0 and comply with Section 508 of the Americans with Disabilities Act.

In response to Bojhan's request for changes to the titles, I drafted this wording (chx posted in the meantime), which could be moved to wherever that toggle switch will appear and reformatted accordingly:

  • Fieldset title: "Administration Overlay."
  • Fieldset contents: One checkbox, unchecked, with the title "Add a floating window above content or settings that are to be edited. Edits will be entered in this window."
  • Description: "Warning: This usability enhancement interferes with screen readers. By enabling overlays, you risk making the back end of your website inaccessible to any administrator who must use a screen reader." (This warning brings us into conformance with ATAG 2.0.)

If we go with a per-user toggle switch (which duplicates another issue), we would still need wording to tell people what happens when they flip that switch:

  • Switch title: "Edit in overlay."
  • Additional information: "Make your changes in a floating window above the content you are actually editing."
  • And: "Warning: This feature interferes with screen readers. If you use a screen reader, do not turn this feature on."

(@Bojhan, I realize that this tells the user what to do, but if we rewrite this into an indirect message, we risk making the information inaccessible to people who have cognitive disabilities.)

I've spent half the day researching this and related issues. I wish I could contribute more time, but I can't. No matter how much we like, hate, or don't care one way or the other about Overlays, we are not going to change the fact that turning it on by default makes Drupal 7 fail to conform with international accessibility guidelines and fail to comply with American law.

And if we leave it up to each person who sets up a site in Drupal to decide whether to turn it on or leave it off for their whole site, then we need to let them know how that decision will affect people who use screen readers.

If we leave it up to each person who participates in maintaining a Drupal site to make the choice for themselves, then we need to let them know that if they use a screen reader, then turning this feature on will make the editing interface inaccessible to them.

And no amount of "Wow" factor will change that.

So, Dries and webchick, we need you to decide: What is to be done about Overlays, and how should it be accomplished?

chx’s picture

The good thing about standards that there are so many to choose from. While you are free to pick a few we won't be compatible with I am sure I can pick a bunch we will be. I still stand firm: hands off the installer. Also "fail to comply with American law" just rubs me a very wrong way.

EvanDonovan’s picture

Cliff's most recent proposal sounds like it would be necessary both from the regulatory perspective, and simply because accessibility is important. Also, it is less technical-sounding than the one from #15, which did not explain why the Administration Overlay could have negative implications for screen-reader users.

If I understood Everett's comments from the other night, it would not be possible to make the overlay accessible in all major browsers, due to their lack of support for ARIA regions.

We can't require people to use the overlay to disable the overlay. Streamlining the installer is important, but not at the expense of accessibility.

I retract my previous suggestion of a separate install profile. I think that the checkbox would be sufficient. By contrast, a separate accessibility page is not clear about what *specifically* is being addressed, and is unlikely to be visited.

chx’s picture

We have two issues by now.

One, we need to make sure people with screenreaders can use Drupal 7. Currently Everett reports they can't. This is a problem that must be fixed.

Two, people complain that the overlay also happens to violate some standard. After the first issue is fixed, the sitebuilder can get to the modules screen and disable to her heart content whatever. This problem is not something to waste a lot of cycles on -- if there is an easy solution, go for it, if not, just let the sitebuilders deal with it.

We have limited resources in many ways and we need to pick carefully we can and what we can not fix.

EvanDonovan’s picture

It might be that the regulatory issue is not something we should focus on, although it was mentioned as part of http://drupal.org/node/769692, the list of requirements for core themes. (Shouldn't core's configuration be held to the same standard?)

More significant is that, if I understand correctly, the ARIA support that is necessary for overlay is lacking in several major browsers. I'm not sure if there is a technical solution for that.

Trying to fix ARIA support in all browsers would be more difficult than adding a checkbox to the installer, I believe. But I'll say no more until a decision is made by Dries and webchick.

Cliff’s picture

FWIW, Bojhan brought up American law; hence my reference to it. I prefer to refer to the international standards on which the law is based. By the way, many nations also have laws based on the same standards. And I'm sorry if that rubs you the wrong way, chx, but many of us must work under those laws. If we're going to use Drupal, it has to comply.

But any way you slice it, Drupal 7 cannot be accessible with Overlay on by default. I don't care what issue queue fixes that problem, but it needs to be fixed.

Dave Reid’s picture

Is it possible to detect in PHP if the current 'browser' is a screen reader and the installer can automatically perform the appropriate actions (like we did with clean URLs)? Then we don't need to expose a checkbox.

cwgordon7’s picture

Dave Reid: From what i understand, no, there is no reliable way we can tell whether a user will be unable to use the overlay or not from PHP.

Bojhan’s picture

I just brought the law up, because by any standard we should try to be accessible. As chx says adding a checkbox is a very bad option - we should try to avoid at all costs. I wish we could all refocus our efforts on #716612: Overlay is not accessible to screen reader users which if solved should make this whole issue obsolete.

catch’s picture

Status: Needs review » Needs work

Either the standards are covered by the minimal profile, which doesn't use the overlay, or if not, then we should remove the overlay from the standard profile (no checkbox, just remove it as a dependency, at least until the accessibility issues are fixed).

Special casing it in the installer is just a hack to avoid doing one of those two things. If people are really so keen on such a hack, then it should be self-contained in standard.profile - others including the overlay can either copy the pattern or fail the standard.

Bojhan’s picture

Yup, so focus our efforts on fixing it in #716612: Overlay is not accessible to screen reader users - removing until will do nothing but stop any momentum on it.

gowriabhaya’s picture

I would like to note that I made an effort to install the native screen reader for Ubuntu today (Gnome Orca) and hear exactly what happens when using overlay with keyboard navigation. I couldn't encounter any problem so maybe this is a specific screen reader problem.

EDITED BY davereid: ARG that was me.

eigentor’s picture

Don't know if this is an option - but how to create a third install profile that is named "Screen-Reader-Accessible" that only has Overlay disabled and is the same otherwise?
Would be good for all people that don't like the overlay.

Ah, I see other people had this idea: http://drupal.org/node/716612#comment-2799956

EvanDonovan’s picture

Yes, that was the idea that I retracted a few comments up; thanks for finding where I had mentioned it. I am amenable to catch's suggestion in #67 (disable in standard by default), but it would be sad to see all the work that went into the overlay become less significant since it is disabled by default in both profiles.

If there is a way to fix #716612: Overlay is not accessible to screen reader users, of course, that would be ideal. Everett states in #35 of that issue that he is not aware of one. Does anyone else have knowledge of one?

Also, if #716612: Overlay is not accessible to screen reader users is where energies should be focused, rather than this, should the status of that issue change to critical and this one be downgraded or closed?

eigentor’s picture

All that can tell if the overlay is a win is a large user test - the largest possible is the launch with Drupal 7 default.

Given that the risen complexity the JS induces - thinking especially if there are overlays over the overlay and other javascript effects that may interfere with it and need more thought - can be sorted out, Drupal might have done really new: Trying a new concept less on the technical area than in the field of UI concepts.

Think of how that can change the notion of people of drupal - powerful but ugly, flexible but hard to use (I guess this is a common perception) - to a system that takes care of ease of use.
Paired with Drupal Gardens, Buzzr, Open Atrium, Drupal commons and the x other distrubutions that will come out in 2010, this might really rock the CMS world outside of the drupal merryland.

So any solution that leaves it on by default is better in my eyes especially in the mid- and long-term view: Drupal has got to compete in the UX sector and desperately needs to attract more UI and Design people.

So giving Screenreader users a viable solution - providing a different install profile should be one, since this is only adressing a screen reader admin, not a site visitor.

The overlay has come a long way, so let's be confident it can overcome this hurdle as well.

jrabeemer’s picture

Given that Drupal 7 will have distribution capability, we can create an "accessible" Drupal version with the overlay and many other features turned off. Then toss in 508 compliant themes to top if off. This seems like the more sensible solution. Ideally, you start off with sensible defaults and remove as many features as possible from the installer. As a beginner, don't force me to think and make decisions for something I know nothing about. As a power user, I'll use drush or a custom small-core distribution to bypass the overlay.

merlinofchaos’s picture

Just one interjection: If we are going to consider accessibility important, than the base install must be accessible. It's been stated before but most are in agreement but it's been brought up again so I must stress that an install profile (and therefore distro) is an unacceptable solution.

Bojhan’s picture

Status: Needs work » Closed (fixed)

@eigentor @momendo We already discussed(read up) , that's not an option.

@EvanDonovan You are right, all discussion should be focused on fixing the issue rather then trying to skip it. Everett says it can't be done, then again I am hesitant to believe all Modal dialogs on the internet are inaccessible. Lets first have a focused effort on this, rather then just four people having a look at the accessibility issue - we should have more knowledge tuning into it.

#716612: Overlay is not accessible to screen reader users

Bojhan’s picture

Status: Closed (fixed) » Postponed

Or at least postpone till we have a final answer, we can't fix it

Everett Zufelt’s picture

Status: Postponed » Needs work

There is no reason to postpone this issue for further research. Having expert knowledge in this field I can say with great certainty that Overlay cannot, at this time, be considered accessible for screen-reader users. So, unless we postpone issues anytime we disagree with expert opinion we should not postpone this issue. That being said, if someone would like to challenge my expert (research based) opinion on this matter I am happy to be shown to be incorrect.

Some responses to the recent posts.

1. It is not possible to detect if the user is using a screen-reader from the http request, or through JS.

2. My preference is to have Overlay disabled by default in all core profiles, but I am happy for an alternative solution.

3. There needs to be a way for users installing D7 to know about Overlay causing problems (only d7 issue that does) for screen-reader users. I am not picky about how we do this, but it needs to be unobtrusive and should ideally not use an alternative "accessible" workflow.

4. Because ARIA is a draft rec it is poorly supported by most recent browsers and screen-readers, not to mention the older browsers and screen-readers some may be still using.

5. As I have said many times, it is not possible to make a modal dialog accessible to screen-reader users online, even if some can use it with some browser / screen-reader combos. I am happy to be proven wrong on this point, but it is not opinnion, it is based on research and discussion with other accessibility professionals.

David_Rothstein’s picture

I don't know if this should officially be marked "postponed", but it should certainly be "effectively postponed". We are trying at #716612: Overlay is not accessible to screen reader users to fix the remaining accessibility issues, which if fixed would make this issue irrelevant. It's definitely possible that effort will fail, but we won't know if we don't try to actually modify the overlay code and see what happens. I'd rather see people spend effort there rather than commenting here :)

Cliff’s picture

Regarding #69, if you didn't turn off your monitor before you tried the test, you don't have a valid test. And if you know in advance how the system is supposed to work, you don't have a valid test.

Testing for accessibility is harder than those of us who have full capabilities for now think it is. Even people who do it regularly can fool themselves.

By the way, I said "full capabilities for now" for a reason. Of those of us who can see today, none knows for sure how long he or she will have that ability. And wouldn't it really stink if you were suddenly locked out of all of the websites you installed because the default installation wasn't accessible and there was no accessible path for you to change that?

@merlinofchaos, your support is most welcome and most appreciated. Thank you sincerely.

mgifford’s picture

1) An accessible install profile just isn't an option (as has been stated previously) as it would mean effectively doubling the profiles. You'd need an accessible version of every major install profile shipped with core or you'd be giving folks the impression that they could have a generic accessible site or a blog (assuming that at some point there is a blog profile in core).

2) It would be great to see Overlays work well for everyone #716612: Overlay is not accessible to screen reader users, I do think that they should be something that could be disabled per user #659480: Per-user setting for the Overlay, however right now neither of those patches seems to have something that is close to a patch that works. That patch approved here does and brings us closer to fixing a critical issue. In fact if we get a way for blind users to easily disable Overlay on install, maybe we can take #716612: Overlay is not accessible to screen reader users off the list of critical bugs.

I am also worried that the whole Overlay patch may need to be rewritten from scratch to make it accessible. I expressed problems with the approach to implementation months ago in the issue queue and I am pretty sure that they were overlooked. I don't have the skills or time to rewrite this module and I'm pretty certain that those who do have the skills in this community don't have the patience to open up that can of worms at this time. It is not the responsibility of the accessibility team to resolve the problems here, although we've certainly tried to propose solutions. Accessibility for Overlay has been a known problem since at least November. I don't know that we're any closer to resolving the core problems with it.

3) I do think it would be perfectly acceptable to disable the Overlay module by default or perhaps have it as something that can be added in as part of the initial configuration. I know that people want it enabled by default, but there are other great modules like OpenID which aren't turned on with an install.

4) If we come up with a solution to disable Overlay so that the install doesn't need to be complicated by adding an extra form element or accessibility link the patch can always be reverted. It's just two fairly small chunks of code. Heck, I'll even volunteer to write up the patch if it isn't required.

We can't just keep suggesting it should be resolved elsewhere.

@DaveReid, thanks for your testing with #69 it is very possible that Ubuntu & Gnome Orca did a better job of addressing this problem than Jaws or VoiceOver. However, just like nobody would be happy with Overlay if overlay only worked with the Linux Browser Epiphany, Orca just doesn't have the market share. Thanks so much for testing with Orca. It's a good step to understanding the problem. I'm all for using open source but I can't only serve open source tools.

koshea’s picture

I know there is concern about the idea of making people feel second class if they have to opt-in to accessibility options so perhaps this is not an acceptable solution, however I will throw it out there anyways. While the ideal situation here is to remedy the accessibility bug in the overlay module, it is likely that now and in the future there are/will be modules released, especially in contrib, that have accessibility bugs. Perhaps there should be a flag on modules, defaulting to true, allowing developers to mark a module as non-accessible. Then a user preference could be added (and available during the creation of the admin user) to disabled non-accessible features. I wouldn't want to encourage developers to use this as an easy way out in terms of conforming to accessibility standards, however I believe it is likely that at any given time there will be some features that are impossible to implement in an accessible manner so adding the option may be better than nothing.

Cliff’s picture

@koshea, the Accessibility group is working on an accessibility statement for Drupal and a way for module and theme developers to indicate whether their contribution is accessible, for one thing, and produces accessible websites, for another. Your suggestion is not all that far from our target. For an idea of our sense of priorities, you might review Everett Zufelt's presentation to the Core Development Summit just before DrupalCon, Don't Sink the Accessibility Boat. There you can see that our principal focus is on the accessibility of Drupal core, and even there we are not calling for absolutely full accessibility.

Your closing comment, "… so adding the option may be better than nothing," is right on target. It is perfectly acceptable to make this interface available as an option so anyone who wants it can turn it on. It is not acceptable to force everyone to use this interface, in spite of the fact that some of us simply cannot.

gcassie’s picture

I wasn't sure if this should be posted to #659480: Per-user setting for the Overlay or #716612: Overlay is not accessible to screen reader users, but let's give it a go here.

First off, I agree that another install profile isn't an option.

#56 is against adding another checkbox to the default install profile. Perhaps the current two ("Check for updates automatically" and "Receive e-mail notifications") could be changed into a pulldown? Right now jquery is being used to essentially create that effect (unchecking the first hides the second, checking the second implies the first): http://drupal.org/node/199774#comment-1869040. If you have JS disabled it is possible to install D7 with email notifications enabled but no update checking.

Then if we've taken one element out of our form, that leaves a hole that could be filled with the overlay opt-in. Assuming the per-user controls from #659480: Per-user setting for the Overlay or something similar, this checkbox would be an opt-in mechanism for user 1. The accessibility ramifications could be explained in its description.

Another way of putting it: if the overlay is opt-in (which it seems like it must be for accessibility), the module should be enabled in the default profile, but disabled for all users by default. Then this issue's title is a little off, because this isn't really about allowing users to make a choice during install, it is about allowing user 1 to make their choice.

However that choice is managed for each user after the install (via a user setting or a "knob"), the choice should be stored in their account. http://drupal.org/node/659480#comment-2694592 is already doing that. #47 presents another option, but the cookies feel too transient for something that could kill off someone's capacity to administer their site.

eigentor’s picture

@gcassie's proposal sounds reasonable.
The checkboxes area near the updates appear to be the perfect place to me, as it has quite high attention early in the install process.

The fighting will be about if it is opt-in or opt-out.
Making it opt-in in my eyes is a bad deal for people with eyesight, since one can guess 50% of the people will not turn it on. Without even knowing, what they do not turn on, that is. The Overlay concept is rather new the way Drupal uses it, so no chance to understand it less you try it out.

So how about an opt-out that is hard to overlook? Thought needs to be put into what creates more confusion. Help texts won't be a solution here, because the installer is so crucial to Drupal's success in running smoothly and hassle-free, so we don't want to confront the user with a big stopper here.

So mentioning Screenreaders in the opt-whatever dialog might be a good one. As there are quite some other people that would like to disable the overlay right from the start, some more text that suits this group might be good.

So how about a Draft:

Administration Overlay
Turn off for screenreader-accessibility and classical non-javascript navigation

Cliff’s picture

I've been thinking about how we present this option. Out of fear of making the interface too wordy, we seem to be stuck in this mindset of, "Force it on them or leave it up to them, but, either way, don't really explain it to them."

Because of the nature of the overlay interface, it really should be up to each individual to decide if it works best for them. I realize our patches are leaving it up to user1 to make that decision for everyone, but user1 has no way of knowing whether the person his company hires in 6 months and whose role in their website will trigger overlays will use a screen reader. So it has to be set up so each user can turn it on for themselves, or can leave it off at first but turn it on later if they decide that they made the wrong choice, or, if they decided to try it out, can turn it off later if they find it doesn't work for them.

So the way we make it work is to leave it turned off and really sell it: "Check this box to use the Drupal of the future. (incompatible with screen readers today, but we're working on it!)"

We don't have to apologize for being on the bleeding edge, and we shouldn't force everyone out there with us, but that doesn't mean we can't make the option enticing. ;-)

catch’s picture

Status: Needs work » Postponed
FileSize
571 bytes

@Cliff, no we really don't want to give people tonnes of options in the installer - either they've used Drupal before and know what to expect - and hence don't need an option, or they've never used it before and have no idea what we're talking about, then the option only provides a barrier to installing at all.

Attached patch removes the overlay module from the standard install profile, I'm also marking this issue postponed on #659480: Per-user setting for the Overlay and #716612: Overlay is not accessible to screen reader users - either of those may be fixed in such a way that this issue becomes moot, if they aren't, then the only option which doesn't completely mess up the installer is this one. If you're tempted to move this back to an active status because you think this should be solved before those patches are dealt with rather than waiting on them, then please set this issue RTBC - it's a one line patch to remove it, a one line patch to put it back in too.

Everett Zufelt’s picture

+1 for #86 and #84 (in that order).

Cliff’s picture

@Catch, your patch will work as a fall-back position. Because it's a fall-back position, it makes sense to leave this issue as "postponed" until the others run their course.

You might have missed my point in #85; I was tired when I wrote that, so I might not have expressed it clearly. Here's the general point:

  • As an inaccessible feature, Overlay should be off by default. (Your patch does this. Perfect!)
  • Wherever people can turn Overlay on, we can sell it as an advanced feature. (This is the new point I was making.) Whether that sales pitch is on the page where I can turn Overlay on or in supporting documentation makes no difference to me.
  • Ideally, Overlay should be an option available to each user, not something one person turns on or off in a way that affects everyone who works on the site.
  • Once Overlay is turned on, you should not have to go through an overlay to turn it off. Otherwise, if it makes your site administration inaccessible to you, you're stuck.

Good patch. Right now, I don't see a viable alternative to it — but I sure hope we come up with one, because in my book Overlay does provide quite a "Wow!"

Chas Belov’s picture

This is more about some of the concepts discussed in the post rather than the specific bug, although I hope it impacts the decision about this bug, so I believe it belongs here.

The argument that it would be a shame to allow people to disable Overlay (or whatever cool UX feature) after we (I don't include myself in this particular "we" as I am a total newbie) did so much work on it basically translates, for me, as "we have this wonderful new feature and you must use it whether it improves your experience or degrades it," which I find arrogant. There are plenty of fancy-featured web sites and software which are out there that are hard for me to use and for which I would love to be able to turn off these special features. I am also sometimes on a slow device whose performance really slows down with these special features. I love new features, sometimes; I don't love having them forced on me.

I am not taking a position on whether Overlay is good or bad; the truth is, it probably helps some people, and I'd guess (only a guess) it might help some people with cognitive impairments. It obviously hurts others in that it is not (yet) screen-reader accessible. I personally am distracted or made queasy by things that pop up at me, and annoyed by things that suddenly restrict what I can do; the modality of, for an example that was bothering me today, Microsoft Outlook bugs me a lot, and making Overlay screen-reader accessible won't make it more accessible for modal-dialog haters like me or for slow computers that bog down over a lot of JavaScript. That argues for a user-by-user preference, since most sites will be maintained by multiple users. (But I guess I personally would not be seriously affected by having to use Overlay once to turn Overlay off if I discover I don't like it.)

David_Rothstein’s picture

@Chas Belov - huh? No one in this issue is arguing that people should not be allowed to disable the Overlay module.... The question is whether (or how) it should be enabled in the Standard install profile. Even within Drupal core itself right now, it's already disabled by default in the Minimal profile.

kika’s picture

When overlay it is not in neither profile, there is no real justification to have it in core. When in contrib, it could mature and hopefully be rengineered to be less on a complex monster, see #782656: The overlay title and tabs should be inside the child window, not the parent window

Have a look at http://drupal.org/node/659488#comment-2901204 -- there could be some alternatives how to preserve the best of overlay -- clear backend and frontend switching and easy switching between them -- without overlay itself.

(ps. how to make direct link to issue's comment using [#] tag?)

iantresman’s picture

We should give people a layout (a) that they are familiar with (b) is inclusive (ie. summarised all module and tasks) (c) Let people opt-in.

The first thing I did was disable the Toolbar, the dashboard and overlay, as I couldn't find common tasks and features.

I'm still troubled that many features are on secondary menus. eg. Site information is now two clicks away, as are many other options (eg. File system; Image styles; Image toolkit).

Bad Layout (2 clicks)

Media
      Media tools

        Good Layout (1 click)

Media (Media tools)
      File system | Image styles | Image toolkit

EvanDonovan’s picture

@iantresman: Please open a new issue for any usability feedback you have that is unrelated to adding an overlay opt-out to the installation process.

marvil07’s picture

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

Since the recently created issue #890284: Unauthenticated users cannot disable Overlay is now on 8.x, I am moving this also to 8.x

Cliff’s picture

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

oops

Cliff’s picture

@marvil07, my bad: I had confused this issue with a similar one that has already been fixed. Put out other fires before this one.

David_Rothstein’s picture

We really shouldn't be adding options to the installer at this point. But I think @catch's little patch in #86 is certainly still on the table for D7.

Either way, this issue shouldn't be both for Drupal 8 and marked postponed. Pick one or the other :)

Everett Zufelt’s picture

Status: Postponed » Closed (won't fix)

Setting to Won't Fix as #896364: Screen reader users and some keyboard only users need a clear, quick way to disable the overlay will provide an easy method for any user to disable Overlay for their account.

Everett Zufelt’s picture

* will provide an easy way for screen-reader and keyboard only users to disable overlay for their account. All users have option of disabling Overlay on user profile page, but this is not necessarily evident to all.

hassnj02’s picture

Issue summary: View changes
hassnj02’s picture

The overlay is messing with my screen. I just need it removed.