Overlay is not accessible to screen reader users

subscribe!

jquery ui dialog add an aria attribute (http://code.google.com/p/jquery-ui/source/browse/tags/1.7.2/ui/ui.dialog.js):

uiDialog = (this.uiDialog = $('<div/>'))
...
.attr({
  role: 'dialog',
  'aria-labelledby': titleId
})
..

This attribute isn't ok?

This is indeed not favorable for this UI, does anyone have a fix?

I think overlay in the default profile is pretty important, but if we can't get it to work for AT users, we at least need to make it easy to disable quickly. Lots of web applications detect whether you have Firebug enabled, and add a suggestion in a ribbon at the top of the page like "Firebug is known to cause performance problems with this app. Why not disable it?" Maybe we could do something similar.

Could the proposed ribbon just be displayed inside a div that has the "element-invisible" class added to it? (Assuming the accessibility issues discussed here are limited to screen readers...) Or does that cause issues for others since by definition a link (focusable element) would probably have to appear inside the ribbon.

Also, to the extent that this is an issue with jQuery UI dialogs specifically, note that there is an open issue at #668640: Overlay shouldn't be based on jQuery UI Dialog already being discussed for other reasons. Not sure if that would help, or how easy that patch would be to write :)

Is there a way to identity screen-reader users using javascript?

If so we could disable overlay for those users. After all, overlay just provides visual distiction between the actual website and administrative tasks.

How about CSS @media selectors (http://www.w3.org/TR/CSS2/media.html#at-media-rule)? Is there one that does identify normal users but not screenreader users, or in reverse?

If so, I think we could make this work.

/edit what if we make the overlay only work for devices matching the media type "screen" but not the media type "speech"?

http://cssmedia.pemor.pl/

Regarding option 1; maybe we should ask us the question what use the overlay has for AT users.

Regarding option 2, you mean something like this: #659480: Per-user setting for the Overlay?

I don't see why the Overlay module is enabled by default. There are lots of modules that aren't enabled by default and Overlay is going to be a harder adjustment for people when they upgrade from D6.

If it is going to be enabled by default, why not just set it up as an option in the install process that is easily disabled by unchecking it before the module is actually installed? It's just another check box. Could possibly be included in a set of advanced options on install that were collapsed so it didn't add too many options.

Why should everyone's overlay be disabled because it blocks access for just a few? Seems like a nice way of introducing a problem for admins where there doesn't need to be one. Of course per user options for Overlay are needed.

I don't see why the Overlay module is enabled by default. There are lots of modules that aren't enabled by default and Overlay is going to be a harder adjustment for people when they upgrade from D6.

It's not turned on automatically for people upgrading from D6, just people who do a fresh D7 installation with the Standard profile.

I think that as long as the Overlay remains in core (and that itself is still up for debate), it should be on by default in the Standard profile. The reason is that the Standard profile seems to be evolving into something that highlights the "major" features of core. Almost by definition, the Overlay is a major feature - so if this is going to remain in core, it would seem to be a little strange to have this thing hanging around in there but then essentially hide it by default.

I'd like to see Overlay in core. I've attached a screen shot of one way to disable this from the install page (mind you it's just visual for now, doesn't actually work), but if we add in a checkbox like:

Index: includes/install.core.inc
===================================================================
RCS file: /cvs/drupal/drupal/includes/install.core.inc,v
retrieving revision 1.6
diff -r1.6 install.core.inc
1685a1686,1691
>   
>   $form['accessibility']['overlay'] = array(
>     '#type' => 'checkbox',
>     '#title' => t('Disable Overlay'),
>     '#default_value' => 0,
>   );

Admins can hide the overlay by default. Could even set it up so that this checkbox is invisible if there was controversy about adding another visual element to the install page. This would make it much easier for blind admins to install.

Mike

@mgifford We are not going to have that in the installer (no module is), and honestly should such a suggestion not be in this topic. This is about fixing accessibility issues with the overlay, disabling is not fixing it.

So, honestly - its no solution. So lets work on this "impossible" thing.

Well, lots of different ways to approach this. Could go back to my initial concerns about iframes and accessibility:
http://drupal.org/node/610234#comment-2282334

Would be great if Overlay was built with tools that could be easily supported by screen readers. I do think it's a bit late to be rewriting overlay to use something else.

So we're back to setting up "the ability to disable the overlay for any particular user." So maybe we can just set it up as a checkbox in /user to be enabled/disabled. Or perhaps as a cookie as we've done for Drag/Drop.

A link hidden to everyone but screenreaders that sets a cookie? If the cookie is true then the Overlay isn't loaded?

Whatever I now said enough times, that an option should not be a possibility. And that we should instead focus on addressing at least some of the accessibility issues, I am very sadden by the lack of initiative to actually work on this.

For example the navigation of the tabs, and navigation from and too the overlay? Why wouldn't we be able to fix that, ie using the skip to content link as a way to navigate towards the overlay. And making sure you can navigate back to the toolbar. Where as close should preferably close the overlay?

This may have been mentioned before... but I think the "solution" also involves a bit of documentation/UI text:

If we are going to leave the overlay module as part of the standard profile, and if these problems cannot be fixed, then the help text you see when choosing install profiles at install time should warn you that it includes the overlay module, which may have accessibilty issues for screen reader users.

We should also put this note in the overlay.info file's description, so it shows up on the modules page, so someone doesn't enable the module and then not be able to visit the modules page to disable it again.

This is another reason why I think that it might be best, although difficult, to follow the course of action I laid out in the most recent comments on #659488: Properly test the overlay to determine if it belongs in core or contrib.

If Drupal 7 shipped with 3 install profiles, instead of 2, there could be a "middle-ground" one between Standard and Minimal, which didn't have Overlay enabled. That way, people could still have Overlay out of the box, if they wanted, but there would be a more accessible option also, which still had most of the D7UX usability improvements in it.

The "middle-ground" profile would essentially be a clone of the standard profile minus Overlay, so hopefully not too hard to make...

More specifically, the comment in question was http://drupal.org/node/659488#comment-2780012. But I'm thinking that the middle ground profile wouldn't actually have to disable Toolbar or even Edit-in-Place probably. They don't seem to have near the same # of issues.

Here is a starter patch for testing purposes - all this does is remove the ARIA-related properties that @casey noted in #3, i.e. these:

.attr({
  role: 'dialog',
  'aria-labelledby': titleId
})

(Side question, but perhaps important: Why does jQuery UI use "role: dialog" here... based on everything I've read above and elsewhere, shouldn't it be "role: application"?)

It would be useful if anyone could test this patch and see where it's at with various screenreaders (this won't fix everything, but it would be nice to know where it leaves us). For a real patch, we wouldn't plan to hack jQuery UI of course - probably would aim to replace it as per the previous suggestions, since the overlay isn't really a traditional "dialog" anyway.

The various problems with screenreaders not handling focus correctly are not yet fixed by this. Note that we have a massive amount of code in overlay-parent.js that plays around with the focus (along the lines of http://www.geedew.com/2010/02/25/jquery-ui-dialog-accessibility/ which Jody Lynn linked to in another issue, but a bit different). There could very well be a bug in there - I think there is, since I don't appear to have any way to even tab to the toolbar when the overlay is open; seems like another accessibility problem? It would be useful to know exactly what happens (where focus goes to and when) when a screenreader (a) opens the overlay, (b) clicks on a link within the already-open overlay to load a new page, and (c) tries to tab to new elements after already being in the overlay. I would assume this is possible to fix.

Finally, the one remaining accessibility issue I know of is that the underlying page text is not actually hidden from screenreaders - apparently you can still read it. jQuery UI uses z-index to prevent e.g. clicking on the links in the underlying page, but apparently we'd need something more. If we need a hack to solve this (we might) then I wonder if we can still come up with one. For example, Everett showed me the other day how we do things like put invisible text that says "active tab" next to the current selected local task (elsewhere in Drupal) so that screenreaders know which one is selected. Maybe we can explore similar hacks in the overlay parent window, to indicate to screenreaders that (somehow) find their way in there that they should leave and tab back to the overlay.

This is "needs review" because it needs testing - but otherwise certainly needs work.

[Edit: first part removed]

David, first of all, huge props for trying to help by writing some code.
How would removing the ARIA attributes help the situation?
Also, the current reason we have text under the overlay is so we get that nice overlay effect where it's partially transparent. It is very possible to hide/remove this text completely while the overlay is present and that is something to explore. I did think of some problem with this but it's late and I can't remember

ATM There are 9 critical issues related to accessibility and this one in particular seems to be most important. I've spent a couple of hours checking a bunch of them, have to say that is so exciting to know that D7 might be the most accessible ever!

Great initiative so far @Everett Zufelt, keep pushing!

Is what Everett Zufellt proposes technically possible? (putting the overlay in the footer, marking it display:none and probably unchecking the display:none via Javascript)

In #44, @dmitrig asked:

How would removing the ARIA attributes help the situation?

Simple: The reason the Overlay is failing to work with certain combinations of common browsers and screen readers is that the specification for ARIA 1.0 is still draft, so there is not yet a consensus on how to apply this code and respond to it. So we (and by "we" I mean "not I") have two possible paths to success:

• Get all the browsers and screen readers in synch, which just requires that we:
  1. Finalize the specification for ARIA 1.0.
  2. Get every browser updated to conform with that specification. (Perhaps we could leverage our new relationship with Microsoft to get IE updated sooner than it otherwise would be.)
  3. Get every screen reader updated to work consistently with browsers and Web content in accordance with the final specification for ARIA 1.0.

  And at that point the best we could say about Drupal 7 would be, "Accessible with Safari 12.0, FireFox 8.3, or IE2012 ;-) and NVDA 5, JAWS 15, or VoiceOver 7." (Note that I used arbitrary version numbers to represent future versions. Only the version number used for IE is hopelessly optimistic.)

• Or we could look for some approach that does not require ARIA, at least until each component needed to support this bleeding-edge development does actually become available.

That's how.

So trying to get my head around this: The basic problem seems to me that with the overlay, there are actually two pages rendered, with header, body, and footer, and the screenreaders cannot distinguish which one is the relevant one.

As we load all admin pages into an iframe and everything has to work, it is hard to imagine to keep both pages visible that can be accessible.
Things that come to my mind is adding extra classes (like adding an extra class "admin-overlay" to every relevant element inside the overlay like headings, blocks, divs so they are at least distinguishable while not breaking the routing. Not sure how to build on those classes. Might be one nightmare of code-creep, but might not.

But hiding all content behind the overlay contradicts the idea of the overlay altogether, because then you could just as well go to a page and keep the starting point in the frontend in a =direction variable to go back in the end.

Does the order of the rendering of the two pages matter? What everett proposes (if I get it right this time) is to put overlay conent first, so this would need a clear indication if you are still in the upper page, or in the lower. I imagine if I just jump to the next h2 element, I might just as well end up in the non-overlay content which is the problem.

If I am still completely on the wrong track, please explain further.

So - one page overlaying another can never be accessible unless we hide one of both.
But as the concept of the overlay _is_ that the background page is still visible, this appears unsolvable to me by design.

Boils down to a choice between person with eyesight vs a person without such ability to me. One likes to have the context of the underlying page, the other has a hard time making sense of the two DOM Trees.

Everett Zufelt in #50:

With or without ARIA the majority of screen-reader users will be presented with the main page of content, followed by the overlay page of content. I don't think that switching the order (overlay then main page) will make this any better.

Could you elaborate on that?
I think it was proposed above that the main page content could be hidden via CSS and then reappear via JS for all sighted users.
And screenreader users would get the page in the overlay as if it were the only one (right?), because the main page comes afterwards and is "display: none;". That way a sighted user would see no difference to how it is now, and the screenreader user just "thinks" (this is not meant in a pejorative way, I just don't know any better word) there is only one page.
Yet you indicate, that this wouldn't really solve the problem.

I think it was proposed above that the main page content could be hidden via CSS and then reappear via JS for all sighted users.

That doesn't work because screenreaders use JavaScript also, and apparently there is no "browser-sniffing" that can detect the presence of a screenreader.

However, to be honest I'm not sure why we would want to hide it from screenreaders. Part of the point of the overlay is that there are two pages on the screen at the same time. I don't think we want to pretend to screenreader users that that isn't true. What we need to do instead is to find a way to communicate it to them. As per #40, I don't see why we couldn't do that via some kind of a hack (e.g., text that explains what is going on, placed inside an "element-invisible" div at the top of the underlying document). Again, we already use similar hacks elsewhere in core, where ARIA would be used in the future. I don't see why this is different - we just need to think of the appropriate way to organize the page and to communicate it.

Re #54: All right. So instead of switching the whole main page/overlay around, there could be a "Skip to Overlay" link (similar to the "Skip to Navigation" we have now) and perhaps some explanation on what the overlay is or what is going on in general?!

Sounds o.k.
We take for granted that this will be mainly for people that run their own site and thus are admins. For non-sighted non-admin users that are allowed to create content, I think we can presume the scenario that the overlay is switched off.

So we can expect from a site admin to get used to a skip link or whatever - keeping in mind this is only until the ARIA stuff gets out of draft state.

This entire ARIA Problem will not only affect drupal, so we should be good not to be the No1 most accessible system and score at No. 4.

I have been pondering this one, and I think having an element-invisible link at the top of the page is the best workaround for now (barring removing or significantly reworking overlay). The advantage of a link is that in addition to setting the focus appropriately it would also allow us to trigger some javascript. This could do things such as disable problematic Javascript (from reading Everett's description it seems the issue is more than just the focus) or even set a cookie to disable the overlay for that session or user.

@David_Rothstein, in #54 you said:

However, to be honest I'm not sure why we would want to hide it from screenreaders. Part of the point of the overlay is that there are two pages on the screen at the same time. I don't think we want to pretend to screenreader users that that isn't true.

I thought the whole point of having the overlay is so a sighted user will understand the context of the changes being made. Letting them see the page where the changes will be applied behind the floating window where they enter the changes is the proposed way to provide that context. (And isn't that still subject to usability testing?)

The whole point of accessibility is to give people with disabilities — in this case, people with visual disabilities — comparable access to and experience with the information. So we don't need a method that makes available to them all the content from the affected page; we just need some kind of label, flag, or hook that lets them confirm where the change they are making will take effect.

And, come to think of it, in this interface we who can see don't need the html for the content being changed, either. We just need something that helps us keep track of context. Right now, Overlay is rendering the affected page in html behind the active window, but a background image produced from that rendered page would work just fine for anyone who can see it. That approach should not require ARIA and would not create confusion for people who use screen readers.

I don't know how hard it would be to make that happen, but it's at least worth considering.

Producing a background image is out of scope for sure.
To me the aim must be to find a compromise between sighted and non-sighted people.

A benefit of the overlay that also non-sighted people will benefit from a lot is that once you close it, you are still on the page you started from.

So the point should be: how to make it clear which part of the page is the underlying page and how to make it not confuse Screenreaders. To not render it at all, not displaying the text or whatever won't really help since the page elements like Header, Footer, content will still be there.

If they are not there anymore, the underlying page does not look like the page you came from anymore and it leads the entire concept into not making sense anymore.

So what kind of flag, skip, mark or whatever can help seperate the two pages?

To get the entire thing less abstract:let's try it out. I found this as an extreme example http://www.webaim.org/simulations/screenreader.php to show us what a badly coded web page sounds like ;)

Also there's Fangs for Firefox https://addons.mozilla.org/de/firefox/addon/402?src=api that renders the Screen Reader as text.
Maybe you have some more tools to test that that you can point us at?

Regarding:

2. The skip-link is an interestng idea. But, you need to remember that screen-reader users access the page in a serial / linear manner. This means that there is no good way to ensure that they are anywher near the skip-link when the overlay opens.

Can't we set focus via JavaScript when the overlay opens? We could focus on the top of the overlay, which would make the flow for a non-sighted user pretty normal (I would think???) e.g. if he/she clicks a link (that opens an overlay) he/she lands at the top of the target page (in an overlay). Then there would still be the need to somehow communicate that, in fact, you are in something called 'overlay' and there's also something called 'main page', but I guess the actual workflow would not be entirely corrupted as I think (!!!) it is now.

I'm probably missing something obvious but I wanted to put this out there...

@tstoeckler, unfortunately there are so many facets to this issue that the discussion isn't confined to this queue. For more background, you might want to read Why Overlay should be disabled by default in all Drupal 7 profiles.

@tstoeckler, the existing code already sets focus similar to the way you describe. However, see Everett's blog post from above - apparently not all screenreaders are respecting that. It's not totally clear why... One of the points of the patch in #40 is to see if removing the ARIA role might fix that (in addition to the other problems it fixes), because other than that I'm not sure why screenreaders wouldn't be handling the focus correctly when other browsers do.

(And we also need to allow the focus to move to the toolbar/etc, although that shouldn't be too hard.)

But fixing the focus isn't enough - the short explanation being that screenreaders have other ways to move/jump to a different section of the page. I'm not familiar with all the ways they can do that, so I don't quite understand the best way to organize the page to address that, i.e. whether something like what Owen suggests in #57 would work or not. In the worst case, I don't see why we couldn't just saturate the underlying (parent) page with screenreader-only text all over the place. This overall feels more like an annoying problem than an unsolvable one.

I've taken the bold step of unpublishing unrelated comments. If people are really unhappy with this I'm happy to publish them again.

I took a look at the unpublished comments and decided to republish them. They aren't really unrelated per se (even though that part of the discussion has now mostly split off to the separate issue at #775084: Allow users to opt-out of the overlay during installation for accessibility), but rather I think they reflect the history of how this issue evolved, and it seems like some of them contain important information.

In general I don't think comments should be unpublished unless they really truly are off-topic (spam, ranting, etc) :) Hope that's OK.

@Everett Zufelt, so a screenreader totally cannot distinguish accessibly between a document and a document inside a iframe? If there is a way to that, I think we can make overlay accessible...

And what about role="document"?

<body>
...
<iframe id="overlay" role="document" src="..."/>
</body>

Or even (http://www.w3.org/TR/wai-aria-practices/#make_modal):

<body>
...
<div id="overlay" role="dialog">
<iframe role="document" src="..."/>
</div>
</body>

If such an apprach still isn't accessible, what if (i already suggested it before in another issue) overlay only kicks in when the user matches the CSS media selector "screen" (or one that leaves screenreaders out)? After all overlay is just an iframe which provides visual distinction between admin pages and the actual site (a screenreader user has no benifits).

In that issue you said there might be screenreader users that still want to use the overlay. But overlay isn't accessible, so if we disable it for everything but screen users, drupal is accessible again...

@David - fine with me, just wanted to get this fixed and reduce noise.

Everett, what would the point of coding it up be if it won't work?

Everett, right now we have code that's supposed to be forcing focus to stay within the overlay. In FF, without a screenreader, when I tab through the overlay and get to the end, it forces me back to the start of the overlay, instead of the start of the parent document. I'm assuming screenreaders are ignoring that right now. Is there any chance we could get screenreaders to respect that code or something like it? It seems like that would essentially make the parent document "invisible."

Thanks, Everett. From what I'd read upthread I was afraid that was the case, but wanted to clarify. At this point I'm going to focus on #775084: Allow users to opt-out of the overlay during installation for accessibility. :(

Before we go adding more options to the installer, something we've spent the past 18 months *removing* options from, not to mention totally non-sensical ones to anyone who's new to Drupal 7, and by proxy adding even _more_ special-casing to Overlay in core (in case you can't tell, I'm not a fan of this at all... :P~), can we please talk through a few other possible options?

1. Only trigger Overlay from Contextual Links, not from the Toolbar. The Overlay is solving the problem of "I just need to quick go edit this content|ban this user|delete this spam|configure the title on this block|etc." and be able to jump right back into the site context when it's done. VS. when you start digging through the admin panel, you are likely in a "I need to set up my site structure|turn on and configure functionality|configure my site's appearance|etc." i.e. a "Site building" context, where Overlay is less appropriate. We could then add the hidden class (if it doesn't already exist) on contextual links for screen-readers, and they would not be confronted with this at all.

2. Add some sort of "minimize/maximize" button for the Overlay, to allow you to break out of it on specific pages without having to navigate all the way to the modules page and disable it whole-sale. Like the shortcut bar on/off toggle, we'd store this setting in the session so it would persist across page loads. Not sure where to put the on/off toggle -- maybe in the toolbar -- and of course we'd need some design work done around this. But this would allow select advanced admins to turn the feature off for them while keeping it for their content editors, for whom it's more useful.

#74 those arent solutions to the accessibilty problem.

I see two options:

1. Provide a ARIA-based overlay; accessible to modern/future screen-readers
2. Enable overlay only for users that match CSS media type "screen" (or at least one that leaves screen-readers out)

Let's remember here that accessibility is a continuum...

We can absolutely make significant improvements to the accessibility of the overlay, which is the goal of this issue - to get it to something that is usable (even if not 100% perfect) for screenreader users. Then they can decide for themselves individually if any possible benefits (e.g., the close button) outweigh any possible confusion - keeping in mind that the confusion will tend to decrease with time and experience, but the benefits, such as they are, probably won't.

***

Everett, I have read through this thread a couple times the past weeks:

http://groups.google.com/group/jquery-a11y/browse_thread/thread/3b59aa35...

And it mostly makes sense, but can you clarify, from your discussions there, does it seem like there any short-term changes that the jQuery UI team is thinking of making to its particular use of ARIA in the jQuery UI dialog, in order to make it work better with today's browsers and screen readers - or are they comfortable with it in the short term and only thinking about long-term improvements? I couldn't quite tell from that discussion where they left that - i.e., is it basically their position that the Drupal overlay is using the dialog for things it was never intended for and therefore it's our problem to deal with?

I've also noticed (for example) recommendations at http://www.w3.org/TR/wai-aria-practices/#kbd_layout_impact that suggest using a mix of different ARIA roles in different places in a document, which is not currently being done - but it also seems from your tests that there is at least one screen reader (was it Voice Over?) where even that would not help.

Otherwise this issue seems partially blocked, since we are either waiting for:
(a) changes to jQuery UI itself
(b) #668640: Overlay shouldn't be based on jQuery UI Dialog

However, in the meantime, it would still be great to see tests of the patch in #40 (which removes ARIA from the equation altogether) to see exactly where we're at - especially if we're definitely confident that an ARIA-less solution is the only way to go.

Everett, is there by chance a place to get semi-reliable usage statistics on screen reader versions? In Drupal 8, for example, we will definitely drop support for IE6, which was formally EOLed on Feb 2009 (if we'd known that Drupal 7 wouldn't ship until at least mid-summer 2010, it's conceivable we could've dropped support for it in D7 too...). We don't go out of our way to support older versions of more "fringe" browsers such as Opera and Chrome. I'm curious how pervasive these browsers are that lack ARIA support.

I opened a seperate issue for suggestion 2 in #74: #786576: Maximize/minimize button

Everett, I don't suppose it would make any difference to have overlay be inserted into the DOM above the page content, instead of below?

"Only trigger Overlay from Contextual Links, not from the Toolbar. "

This sounds very useful to me. It will relieve a lot of the stress that overlay causes. I really like David's statement "Let's remember here that accessibility is a continuum..."

@Everett Zufelt, do screenreaders allow javascript to move the focus?

Also are there DOM events being triggered when navigating through a document? Just focus/blur on focusable elements (like links and inputs) or also on for example the header/paragraph being read?

(could I talk to you on irc for a moment?)

@Everett, could you test attached html page if it correctly traps the focus?

Instead of just moving the focus back to the overlay iframe, we could also move the focus to a message inside the overlay iframe that say something like:

You have opened a modal dialog containing a seperate document. Access to the underlying document is currently blocked.

[Continue in dialog] [Close dialog]

I found a rather comprehensive article, where someone tested different ways of setting focus in screenreaders (in German, sorry): http://www.protofunc.com/2009/10/11/der-grose-screenreader-focus-test/
They tested:
JAWS 8/9/10
Cobra 8.1
Webformator 2.4c
NVDA 0.6p3.2
in IE7/8/FF3.5
From looking at the WebAIM survey it seems at least Window-Eyes and VoiceOver are missing from that list, but I guess it's a start.

I found the following quite relevant:
Only JAWS 8/9 seem to have problems following the focus on newly inserted DOM elements.
The author mentions two workarounds for making focus change work in JAWS 8/9.

1. Instead of actually inserting something in the DOM, simply rewrite it. The element has to be non-empty before it is rewritten for this to work consistently. This is used by the jQuery accessible tabs plugin (demo here). I have no clue, though, whether this is actually possible or feasible with an implementation such as the overlay.
2. The author has a modified setFocus script, which, according to him, works in all tested screen-readers. A demo (also German, but should be universally understandable) can be found here. The demo hides and inserts rather simple elements, so, again, I don't know if this is would work for us.

I'm sorry if this has been mentioned before, I just jumped into this issue rather late.

Hm, #87 doesn't seem to handle focus correctly for me without a screenreader either... there may just be something wrong with the code?

I should have been a little more clear above, by the way - one of the reasons I thought it might be useful to test out #40 again was to see if the ARIA stuff (in addition to the known problems it causes) was also interfering with the focus behavior in some way. But looking a little more closely, it seems that is not so likely to be the case.

Also see @casey's patch at #786394: Improve overlay keydown handler (TAB-navigation) which tries to improve the focus behavior when the overlay is open so you can TAB to (e.g.) the toolbar also.

Articles that might be usefull

• Improving Ajax applications for JAWS users
• Making Ajax Work with Screen Readers and then escpecially the section on Informing a Screen Reader that Content has Changed

Ahem, reading #81 and as all kind of real user-testing appears to be poorly lacking for the overlay:

Everett, Cliff, as you appear to be the specialists: It would put some flesh to the bone if you could test the thing with some real-life Screenreader users. We need real data, and this might give the discussion a more focused direction.

Or maybe you know some blind or sight-restricted people that other people could work on tests with?

I opened a new issue for 3b: #788556: Open Overlay from Contextual Links but not from Toolbar

@eigentor: I think that is a great idea. I wish I knew how to do user testing myself, as it seems like that would be the best way to proceed at this point.

@Everett: Your most recent comment is a great summary of the issue, I think. I hope we can find a good solution to this critical problem.

Another useful article: JavaScript and screen readers. I am starting to understand how these screenreaders work.

@Everett would you test these too?

This one might even be better.

sub

@eigentor: With respect to #95, Everett does use a screen reader. I know the theory and practice, but he also lives it. I'll try to seize any opportunities I can get to test with others. I hear that the students at San Francisco State University are interested in doing just that type of testing. Finding the users and getting the resources is a challenge, but let's see what they come up with. I understand they were really pumped after DrupalCon.

#668640: Overlay shouldn't be based on jQuery UI Dialog got committed and it might have fixed/effected this issue.

And with other screenreaders everett?

The focus seems to be on screen readers, but what of people who can see but need to use the keyboard only?

Odd that I don't see any discussion here of the onClick event. If the onClick is only set off by an actual click, and activating a button or link via the Enter key does not trigger the onClick event, then wouldn't Drupal simply be able to check whether the action was triggered by onClick or not? If it was triggered by a click, then use the overlay on the reasonable assumption that if you clicked into it, you can click out of it. If it was triggered by the keyboard, don't use the overlay on the reasonable assumption that if you didn't click into it, you might not be able to click out of it.

There is the unfortunate possibility that a blind person could accidentally activate the click mechanism on their laptop, so this may not be the ideal solution, but it would seem to be a possibility. The other downside is possible disorientation on the part of folks like me who switch back and forth between pointing and keying to activate buttons and links, in that the UI would change back and forth between overlay and non-overlay.

Hm. That's an interesting suggestion! Thanks, Chas.

casey, Everett, et al... what do you think?

Ow wait its a suggestion... So you suggest to only open the overlay when a link is clicked using a mouse?

The "click" event is always triggered when opening a link: also when using the Enter key. I am not aware of any browsers allowing to disable this, or are there?

Instead of the "click" event we could use the "mouseup" event, which only fires when the user releases the mouse button. I am not sure however if this will be consistent for all browsers (combined with screen readers).

I don't think it's a good idea though: sighted keyboard only users are currently perfectly able to use the overlay, using the "mouseup" event would remove that ability.

Also, Everett suggested a couple of times screen reader users should be able to decide whether or not to use overlay (Using the "mouseup" event would only allow mouse users to use the overlay). I don't necessarily agree with this though: overlay actually provides not much more than a visual indication of the context from which admin pages are opened. There are however also partially sighted screen reader users, so Everett might be right after all.

I opened a separate concrete issue for #108: #837602: some AT's don't recognize overlay being opened.

@casey I think we need to choose a trade off somewhere. Its true sighted keyboard only users are currently perfectly able to use the overlay but if this fixes the problem for all non-sighted keyboard users I would hardly argue that is not a good tradeoff.

I dont see why screen reader users should decide not or to do use the overlay, when its inaccesible? I mean we don't give any user the posiblity to use or not use the overlay - other then disabling it?

I really like this posiblity and I feel we shouldn't rush to trowing it down. There are ineavibilty trade offs to be made if we want to keep overlay as a enabled by default module - as clear we can't do it on accesiblity, but sadly we can if needed for user experience of sighted keyboard-only users.

This is the most promising suggestion I've heard on this issue in a while. Thanks Chas. I agree it could be annoying for sighted hybrid keyboard/mouse users, but a) it's a bit of an edge case; b) it's just an annoyance, not a barrier, since they can easily see what's happening either way; and c) it would be easy to fix in contrib by adding the click event back in. Let's throw a mouseup patch together and see what happens in screen readers. I'll try to do it today unless casey beats me to it.

It wouldn't just be annoying, it would be broken - and not just for "hybrid" users, but for all sighted keyboard users, no?

What would the experience for keyboard users be? You turn on the overlay module expecting to get an overlay, but no matter what you do, no overlay appears? Maybe I'm just not getting something here.

To my understanding, it would work like this:

1. If Overlay module is enabled, and you use the mouse to click on, for example, "Modules", you would get the Modules page in an overlay.

2. If Overlay module is enabled, and you tab to the "Modules" link and hit enter (or space or whatever it is), you would just get the page, no overlay.

3. If Overlay module is disabled, you can click whatever links you want, and never get the overlay.

Screen reader users would always get the second behaviour (no overlay) since they're presumably not using a mouse to navigate around, or else they wouldn't be using a screen reader (correct me if I'm wrong?).

Keyboard-only users would always get the second behaviour (no overlay) since they only trigger keyboard behaviour.

The only people who would find this annoying is if they clicked the mouse either purposely or accidentally to trigger the Overlay opening, and then tried to navigate around with the keyboard, I guess. That seems like a significant enough edge case that a "overlay_keyboard_trigger.module" in contrib could deal with it.

So even though the overlay works basically fine for sighted keyboard users now, we'd be choosing to remove their ability to use it, in order to make things less broken for screen readers? I can see how that is an improvement in the extreme short-term (in that apparently the admin experience is totally broken on at least one screen reader right now), but overall that really seems like one-and-a-half steps forward, one step back :) I would personally still consider this a critical bug even after a change like that was made. Turning on the overlay module should do what it says it does - put the admin interface in an overlay - or otherwise the module doesn't actually work.

I think that what this issue desperately needs at the moment is an issue summary... there are a lot of tangents here, and a lot of recent changes since #668640: Overlay shouldn't be based on jQuery UI Dialog went in. I will try to write one up later (if not today, then tomorrow).

1.5 steps forward and 1 step back is still a net gain of .5 steps, which is a lot farther than we've come on this issue to date.

@Everett

1. Well, thats a bit wierd to optimize core for
2. Right, but we dont know?
3. Right, but we dont know?
4. Tradeoff?

Eitherway, if this is not a solution fine - but somewhere we need to make a tradeoff. As much as you might not like it, I dont think any of us truely like it. But sometimes we have to keep moving forward, we can't wait for screenreaders to get better and we can't sacrifice on user experience like we did with drag-and-drop - this is far more impacting, as it will confuse people in the installer. As pointed out solution 1,2,3 will sacrifice on UX, in that 3 will sacrifice the least.

Feedback on Everett's solutions:

1. Absolutely not. We're not presenting an extra, confusing option during installation that will make no sense to anyone who is coming to Drupal 7 for the first time (which is the entire population of the earth, with the exception of about ~800 core developers/reviewers).

3. Maybe. But requires some work on design, and has met resistance from the usability team. The option I like best of those proposed is a "full screen" mode whose state is set in a session cookie, like the shortcut bar collapse state.

I completely don't understand your first reason for not going this approach, other than maybe to be argumentative? :P If people liked the existing behaviour, we wouldn't have a months-old critical issue about Overlay's lack of accessibility, now would we? ;) 2 and 3 are reasonable objections. I'm basically finding myself in the "let's cross that bridge when/if we get to it" camp at this point, though.

4 could be solved by a contrib module. I get David's frustration that we've spent a lot of time trying to make Overlay work across the board, even for sighted, keyboard-only users, and we'd be throwing away some of this work.

But I don't know. This issue is incredibly frustrating. I'm open to discussing further options, to a point, but we need to wrap this sucker up in some way that fixes the 'critical' part of the critical bug (an important segment of users can't do anything at all in the admin panel whatsoever).

1. Absolutely not. We're not presenting an extra, confusing option during installation that will make no sense to anyone who is coming to Drupal 7 for the first time (which is the entire population of the earth, with the exception of about ~800 core developers/reviewers).

What if we use the 'keyup' trick in install.php to detect if someone is a keyboard-only/screenreader-user and conditionally display the option to enable overlay on install. That would have a few pros:

1. Not everyone would see that confusing option, but only a small percentage (right?!), and also people who might already have a certain disposition to accessibility-related issues, so it might not actually be that confusing to them.
2. On the one hand, we would give everyone the possibility to use Drupal to its full extent after install. On the other hand, we give people with ultra-cool-screanreaders and keyboard-only users the ability to use the overlay just like anyone else.
3. There would be no inconsistency in the display of the overlay: If overlay.module is installed -> show admin pages in an overlay, if not -> don't

@Everett were you by the way suggesting in #108 that overlay is accessible (enough) in NVDA?

My thoughts go all the way back to #15 & #17 in this thread ...

I don't see why we cant do this:

1. A user (any user) clicks "modules" to open the overlay
2. A link that says something like "This form uses Drupal's overlay which can be disabled here." is added to the DOM outside of the overlay (and removed when the overlay is closed)
3. Clicking that link brings the user to a non-overlay version of the modules admin form ... or better yet, just disables the module with a confirmation form

Screen readers will see this link and be able to act on it. And so will keyboard-only users if they need/want to. AND so will sighted users! This link does not cater to any specific type of AT ... it just does what it says, for everyone.

...And if that doesn't pass UX muster then the link can be an invisible link.

Aren't we overcomplicating this now that we have concluded that with current AT the overlay cannot be made accesible yet...

In fact, if we word it and style it correctly, there is no reason this couldn't be a visible link... an equal opportunity link to disable overlay.

Well if so this should be an invisible link. Else I can see a lot of people disabling the overlay on a first impression without really having tried it. Sighted users can have another option that is a bit easier than having to find out they have to go to the modules page to disable it.

Other than it being just wrong (#127), which I don't find to be a very good argument*, nobody has yet commented on #123, which I still think would solve all of webchick's concerns in #121.

_{* I think this argument is unfair to make, because we are not actively trying to segregate our user-base, we just have to cope with the fact that some of our users simply have a different experience because of e.g. technical limitations of current screen-reader software. That's not something we choose, but we have to live with it. And if the best solution is to present exactly those users, which have a degraded/unusable user experience in the overlay an option to disable the overlay, which for others is superfluous, then we're not harming anyone's rights.}

@tstoeckler On #123 imagine the many users who tab through the installer. Its likely not to be a good solution, and the reason most responses didn't go there because we are still arguing whether we want to disable overlay based on people using their keyboard.

@Everett

So we dont offer the possibility to turn off user experience parts because that would turn the installer and the whole experience of Drupal into a mess - disabling should just be done by disabling the module.

So the only way you argue is to make this work is to offer a checkbox ( which will be terribly confusing, but apparently that trade off is less worse?) - which will just allow users themselfs to make the decision whether their screenreader accepts the overlay, without knowing we have an overlay or without knowing if their screenreader accepts it? I hope you understand why we don't get why its a better solution.

So I guess keydown is shot down, to bad - looked promising.

Onto your hyperbolic argument I think it is unfair and you know thats not what we are trying to do. We are just exploring options.

I don't have the issue summary I promised written up yet, because in addition to the summary I'm trying to work on a new patch :) I'll have something to post tomorrow.

Everett's argument is, as he says, a bit hyperbolic, but I think his main point is that we should not be deciding for certain users that they are not allowed to use the overlay - it is not our decision to make. Especially not in the case of a class of users (sighted keyboard-only users) for whom the overlay currently works fine. Also, the proposed solution involving mouse-up events really doesn't seem like it would work well technically. There are the edge cases mentioned above, but here is an example that is less of edge case: Suppose I don't use a mouse but work in an organization with people who do. Someone emails me a link to an admin page on our website, e.g. http://example.com/#overlay=admin/content. When I click on that link in my email, the overlay will pop up no matter what - there is no way for Drupal to tell that I used a keyboard to get there.

Also, I hate to say it but this issue is complicated enough as it is - can we please move discussion of various ways to allow people to avoid or turn off the overlay to other issues (e.g. #659480: Per-user setting for the Overlay or #775084: Allow users to opt-out of the overlay during installation for accessibility or elsewhere)? The only way those comments are relevant for this issue is that they might allow the priority of this issue to be lowered from critical to normal. They don't actually make the overlay itself any more accessible, which is what we should be focusing on here.

If we move discussion about disabling overlays inline to another issue, we might as well "won't fix" this one; we're at a stalemate. I'd prefer not to do that; it sends the totally wrong signal, since we very much do want to fix this, and there is valuable discussion here among all the people who need to be involved. I'd prefer to come up with an agreed-upon (or at least a "can live with") plan here and then branch off into issue X.

This hyperbolic stuff though has got to go, and is completely poisoning and derailing this discussion. Let's be very clear here: we are trying to come up with a solution to a technology problem, not a people problem. If there was some browser.isScreenReader JavaScript property, to properly identify a screenreader browser as opposed to Firefox or IE, we would've put this in the can months ago.

So adding options during install is a no-go. Basing behaviour of the overlay on mouse behaviours rather than keyboard behaviours also sounds like a no-go. Sounds like the only other option left to us is some kind of "get rid of the overlay on this screen/for this user" button type of thing?

Bojhan, yoroy, et al, can you elaborate on your specific objections to this approach? And propose an alternative?

At risk of complicating the interface, overlays could come with a default footnote:

Press Escape to dismiss this overlay. Press [some key combination] to turn off overlays altogether. [checkbox] Don't show this note again.

This assumes screen-readers will read this text.

re #133: I believe that #668640: Overlay shouldn't be based on jQuery UI Dialog removed the ability to use 'esc' to close overlay ... and I think that #655388: Many ways to lose data on form input in the overlay needs it that way.

But fundamentally I think this is the correct approach until we have a better way to detect if a user is using AT

So adding options during install is a no-go.

IMHO, this option should be at the install only beacuse :

• There are options to choose language as well as other options at the time of install. The overlay is a sort of "unknown" "language" which I must have chance to opt out.
• First time Drupal users are expected to learn so many things and combat so many short-comings of Drupal - an extra option button is really small compared to the hassle it can save afterwards
• Since no other CMS or anything on earth has such weird and detailed overlay, that also thrown upon a separate admin theme, it actually *breaks* normal user expectancy. Users or first time users usually compare things in the mind with existing stuffs and here they will not find that. So best is offer them the options at the onset.

@webchick So I am somewhat sad I am the only person who argues for not allowing an because-we-cant-fix-it-option. But I am pretty sure others are with me on this one.

We have worked incredibly hard to remove any option pollution from the installer, since people just want to get the installer done and don't want to worry about making to many decisions before they actually see Drupal.

Adding an option that is basically saying, we didn't know how to fix this. Means that its good enough for Drupal to sacrifice on user experience because we cant fix an issue. So let me explain why we are sacrificing, at first we are adding an option that will be confusing - this because any new user won't know what overlay or administrative modal, or whatever wording we use, it will be unclear why one would need this option. To be quite frank the option is: [] Make Drupal accessible. Secondary I can not justify adding an option for the sake of a bug, the bug should be fixed not a workaround.

So with that in mind, we can't find a solution for the bug? I guess we should wait for more people to chime in and hope they have a solution. Obviously we dont have a better alternative, otherwise we would have offered that a long time ago.

@kaakuu Its easy to give up on user experience because accessibility is a binary equation. But to be honest your arguments are wrong.
1. Its not a language? You are putting every option there is on the same line.
2. It might seem like a small option but please remember the story where the factory reduced the sesame on the bun one by one over time to reduce costs ending up with no sesame? The same principle applies here, we might just be adding one option - but its short-term thinking if you don't see the larger problem by doing that. .
3. Somewhat agreed - not common in CMS but in apps sure, but if no user knows it how can he make a choice on it?

It might seem like a small option but please remember the story where the factory reduced the sesame on the bun one by one over time to reduce costs ending up with no sesame?

I think the principle is called Law of diminishing returns.

@bojhan in #136: I dont think that webchick is advocating for adding an option to the installer. In fact she says so explicitly:

So adding options during install is a no-go.

I think she is saying (and i agree) that because we are dealing with a technological limitation that the most promising option is to add a link or button (which is accessible to screen readers) to disable the overlay when the overlay is opened (not during install). This way screen-reader users will not be stuck with no way to administer a D7 site. Webchick:

Sounds like the only other option left to us is some kind of "get rid of the overlay on this screen/for this user" button type of thing?

--------------

This issue can be summed up simply... either we can (a) make the overlay accessible to screen readers (and other AT) as they exist now or (b) if that is impossible, we *must* provide a way for users of AT to easily disable the overlay so that they can administer their sites.

So far, no one has come up with a viable solution for (a) ... that leaves us with (b)

The options that have been proposed are:

1. Predict that a user is using AT based on their lack of mouse behaviors: This has been fairly well nixed because we could wrongly remove features from keyboard only users and future screen readers that will be able to use the overlay
2. Add an option during the install process: Many of the usability folks, as well as webchick have (rightly) ruled this out because the installer needs to be kept as simple as possible
3. Turn off overlay by default: This has been nixed several times ... the feeling seems to be that an important usability improvement will get lost
4. Add an accessible link that says "disable the overlay" when the overlay is opened: Currently this is still on the table

Am I missing any other proposed solutions? I'll happily add them to this list...

Yes, bleen is correct. I feel as strongly about adding an option to disable the overlay during installation as Everett and David do about removing overlay behaviour for keyboard-only users. In other words, neither of those are acceptable fixes.

But we need a middle ground here, and some sort of "get the overlay out of my face for a sec" mechanism is not only a very frequently-requested feature, but it would also resolve this release-blocker, from what I can tell. So can we discuss this option a bit more, Bojhan et al?

@webchick Sure, I just don't see how an in-your-face function - is not adding more clutter. But I mean sure, we can discuss it. I am really lost what Everett is condoning other then the no-go UX wise, I am out of solutions - I hope you guys have some.

I have 2 ideas:

1. Add a hidden duplicate for all admin links that opens the link without the overlay. Alter the title attribute of the original link so it reads something like "%title (opened in overlay)" and the duplicate's title reading something like "%title (opened without overlay)".

   Drawback here is that you have to use TAB twice for all admin links on a page.

2. Alter the title attribute of admin links so they read something like "%title (use %keycombination to open this link without the overlay)"

   Issue here is that there seems to be few available/usable keycombinations.

An disable-overlay-module-at-install option seems silly to me. I can however perfectly imagine an AT user getting tired having to read every admin link twice/use another key to open an admin link. Combining one of these solutions with a per-user option to disable admin links being opened in overlay at all (#659480: Per-user setting for the Overlay) does make sense to me.

So it might come up to a kind of ribbon or Message on the top (top right?) of the overlay giving two options:

O Disable Overlay for this page
O Disable Overlay permanently
O Don't show this message again.

Three options already. Ouch.

Still there is a question when to show this.
Showing this every single time you open the overlay is a UX no-go.
Opening it just for, say the first five times someone opens the overlay after having enabled the module might be equally unsatisfactory.

So thera are two extremes:
- Make the message un-intrusive - People might overlook it
- Make it shout loud - it gets on your nerves quickly and can only be shown for a limited count of times.

People might disable the overlay just to get rid of this silly nag-screen.
So maybe someone has better ideas how to do this...

Another idea is to make it an "expand" icon, next to the "close" icon. Please excuse my awful excuse for graphic skills:

In my mind, this would then make the Overlay swoosh away and it'd be just the normal page without the frame. The question then would be how they get back. Maybe a little bar appended to the Toolbar, much like the Shortcut bar..? And if the toolbar weren't there, just a bar along the top of the screen?

Anyway, just throwing around some ideas. :)

If the consensus is to move forward with a "click here to disable the overlay" option, then I suggest we close this issue and move forward with the work being done at #659480: Per-user setting for the Overlay, mark that issue as critical and tag it for UX & accessibility.

EDIT: in truth we should postpone this issue (not close) until such time as we can make the overlay accessible to screen-readers... but my proposal still stands

+1 for bleen18's proposal.

This issue pretty much got stuck at the point that from Everett and other's accessibility specialists experience, the overlay cannot be fully accessible with current screenreaders. So this would have to be revisited when the technical basis changes.

On the other issue we would at least get some movement into this.

@webchick: #786576: Maximize/minimize button

@Everett: what do you think of #141?

So as I expressed quite a few times before (@webchick Sorry but it has been proposed before), exposing another button will add an incredible amount of clutter and I don't know if users will understand the concept of minimizing but not actually minimizing - but rather removing overlay? Its very much counterintuitive to how your application works and its a way bigger trade off we will impose on all of our users then doing anything in the installer.

We have gotten so many design ideas, but only so very few indepth technical ideas - maybe we are looking in the wrong realm.

Bojhan, I'm not sure what you mean by looking in the wrong realm, but if you mean we need to keep banging our head against the wall looking for a technical solution that makes overlay accessible, I don't think that's realistic. D7 is barreling toward release, and we are running out of time and resources. We need to accept that barring a miracle, D7 is going to release with an overlay module that is not accessible to screen reader users. The question at hand is what we can do to let those users opt out.

@ksenzee Well, I agree. I still feel we are giving up on UX.

Here, as promised, is the issue summary and patch I've been working on. I'll keep the summary to the minimum required; I'm interested in getting the patch itself tested out. Everett's summary in #94 is worth reading as well and still mostly a good description of where we're at, but a couple things have changed since then.

Issue summary:

• This issue focuses on screen readers, so I'm retitling it appropriately.
• JAWS apparently no longer opens the overlay at all; this is a serious regression from previous overlay behavior. Presumably the fact that it's a regression means it's possible to fix :)
• There appears to be some difficulty getting screen readers to move focus to the overlay once it's added to the page. However, I think we are trying to solve the wrong problem here anyway. The correct place to put focus is actually the top of the document (i.e., above the toolbar), just like any other page.
• ARIA is either helping or hurting, depending on what screen reader is being used. Note that since the overlay stopped using jQuery UI dialog, it started using ARIA roles markup in a different (and more semantically correct) way than it did before. However, given that some screen readers won't respect ARIA anyway, it seems that in this issue it would be best to start by removing the ARIA markup so we can have a baseline to compare to. Note also that the effect of the ARIA roles (when interpreted properly) is to "trap" the user inside the dialog; however, we want users to be able to access the toolbar also, so unless we were to move the toolbar inside the overlay it is not clear to me that we want to trap the user anyway.
• We need to add some textual information to explain to screen readers what is going on with the overlay.

The attached patch:

• Removes all ARIA-related markup.
• Moves the overlay up near the top of the HTML document (i.e., right underneath the toolbar, when that is enabled).
• Tries a fun little experiment: Since some screen readers apparently have problems dealing with the overlay as it is being added to an existing page, this patch simply forces the page to reload when the overlay is initially opened. The idea is that you then get a fresh page load with the overlay as part of the document, focus at the top of the HTML document where it belongs, and as you read down the page you encounter first the toolbar and then the overlay, which is exactly what we want. Not sure how well this will work, but figured it was so simple it was worth a try. In Firefox, at least, the reload doesn't look bad visually at all; if it's a problem in other browsers, we do have ways around that, I think.
• Adds textual hints to help screen readers understand the overlay. These include a much more descriptive iframe title (the previous one said something like "Page Title dialog" which makes no sense to anyone; this one explains that the overlay content is on top of the page) and also saturates the underlying page with text (visible to screen readers only) explaining that you've left the overlay and giving you a link to close the overlay then and there if you want to fully access that underlying page. It would be nice to add a "or return to the overlay" link here too but I wasn't sure how to do that.
• Is extremely rough and ugly :) I tried to focus on functionality only for now, not code beauty or details.

It would be wonderful to test, with this patch applied:

• Initial opening of the overlay in various screen readers.
• Browsing around the overlay in various screen readers after it is already open.
• The subjective experience of reading through the end of the overlay and, so to speak, "falling off the edge" back on to the underlying document, and how the textual help there does at explaining the situation and orienting the user as to where they are and why they are there. I agree with Everett that this needs real usability testing if we want to truly understand its effect, but I think for the time being we can make significant progress even without that.

So Everett said he would take a look at it tomorrow. And we discussed the possibility of a UX trade off by considering some kind of option to turn off the overlay (not in the installer) - anyways lets explore that some more tomorrow, without pursuing an in your face element.

@ksenzee (#148) - One option you omitted is the one that Everett started with: overlay module should be disabled by default in all core install profiles. The justification is that we were unable to make overlay accessible to screen readers and we are unwilling to release D7 as inaccessible out of the box. IMO, this is our best option. And yes, I do think this is the right issue to mention this resolution.

And yet another option is to just remove overlay from core altogether... there may wind up being other reasons to do that anyway. But that one I really don't want to talk about in this particular issue :)

The reason I think we should not be discussing all these other options here is that they complicate the issue. We already have over 150 comments and it's very hard to follow; we would probably have less than half that if we just focused on trying to improve the accessibility of the overlay itself. I have a patch in #151 which I would like to see reviewed, but I'm afraid that instead it will be buried behind 20 more comments debating back and forth the best way to avoid the overlay.

Also, it seems that a lot of people in this issue have formed the opinion that the overlay is impossible to make accessible; I have no idea what justifies that opinion. Most of the accessibility issues listed above are pure bugs that are possible to fix - and there is no reason not to fix them, regardless of what else happens. The only remaining issue that could put this into the "impossible" category is the difficulty of communicating the page-on-top-of-a-page scenario to screen reader users. Everett has stated that he personally believes that might not be possible to do, but also says it should be subject to actual user testing - his opinion is tainted because he is already familiar with the overlay :) As far as I see it, while it may be technically impossible to completely hide the underlying page in all screen readers, there is no reason that should be a requirement given that we don't do that for other users either. We provide visual cues (dark, transparent background) that it is not the part of the page we want to draw people's eyes to, but nothing prevents a sighted user from reading the underlying page if they want to. What we discussed above (and now implemented in #151) is providing a similar experience for screen reader users via textual affordances and correct placement of the overlay within the HTML document. There is plenty of room to easily tweak that approach also. In #151 I took the approach of absolutely saturating the underlying document with these textual affordances - there should pretty much be no way a screen reader user can miss them in the event they keep reading past the end of the overlay. Just like we have previously adjusted the opacity of the overlay background based on how hidden we want the underlying page to look, we could do the same thing with the frequency of textual affordances for screen readers. (By the way, we could additionally do something like disabling all links in the underlying page so that they can only be read - not clicked - I didn't do that for now, though, because I'm not sure it's necessary.)

@David_Rothstein Thanks! I applied your patch and tested it in my sandbox http://drupal7.dev.openconcept.ca

If folks want access, please sign up with a password & I'll authorize you as an admin.

I am only testing in Safari with VoiceOver so it certainly isn't going to address the questions about Jaws.

With Safari it was rough but workable with Overlay.

There are two Skip to Main links in the page which isn't very useful. Not sure if there is a way to bring the Overlay's Skip to main up to the first link & just replace the old one but it's just annoying.

The link to close the Overlay doesn't say "Close window" it says 'updates' on the Available updates page. This changes to 'settings' if you click there.

I didn't see the enhanced iframe titles.

Also, it seems that a lot of people in this issue have formed the opinion that the overlay is impossible to make accessible; I have no idea what justifies that opinion. Most of the accessibility issues listed above are pure bugs that are possible to fix

IMHO this is because the concept of overlay itself is a bug because
- there is already a separate admin theme
- there is no such thing in existing CMSes and this breaks normal user expectancy

Some people have "formed opinion" that overlay is not needed.
And some people do have "formed opinion" that overlay is needed indeed, for reasons which are at best flimsy because it was not 'demanded' by users from user tests nor by users feedback in issue lists or forums.

If Drupal continued with single default theme for admin and non-admin use as in D5 or D6 which was NOT broken and continued to offer ease to admins to see what pages actually look like to users instead of toggling to and fro, there would have been some justification on using overlay ( like lightbox to those who could use it if wanted)

But now we have "three" screens by default to combat - the overlay, the admin, the regular theme.
This is NOT very usable either :) Tackling Views or Panels within overlay on an admin theme and then testing how those pages look like in the regular site theme actually makes things MORE cumbersome.

@kaakuu, you're off-topic in this issue. Take it to #659488: Properly test the overlay to determine if it belongs in core or contrib, please.

I've installed JAWS 10 and it looks like I can get overlay pretty accessible for that screen reader; for a keyboard only user/AT user it is just like they are visiting the overlay page on its own.

I managed to get this working by adding the presentation role to all elements of the parent document when the overlay is being opened.

• WAI ARIA presentation (role)
• Accessible tree vs. DOM tree - what's the relation?

Still testing though... I hope to post a patch tomorrow.

Well, what we do with browser compatibility in the rest of core is testing in all versions of whatever the biggest marketshare is (IE 6, 7, 8) and then the latest release in the rest, based on the subset of browsers that jQuery supports (FF, Chrome, Safari, and Opera). If there's a glitch in Opera from three years ago, or in any version of Konqueror, that doesn't hold up a bug fix (though can be fixed in a follow-up).

So it seems we need a similar scale for screen readers, and we should document this in the handbook. http://www.webaim.org/projects/screenreadersurvey2/#demographics looks like it has some useful information in this regard:

So to be complete, we probably need to test in the last 5 years' versions of JAWS on IE 6, 7, 8, and Firefox/Safari 3, and then whatever the most recent version is of NVDA and the rest. I don't see Orca listed here, so it's probably lumped under "other". Unless someone knows of a more definitive source for this sort of demographics, WebAIM's stuff looks like it might be a good place to start basing our own best practices on.

In terms of an initial commit to deal with the "criticalness" of this critical bug, though, I'm comfortable with a much smaller subset of screen reader/browser combinations, and fixing more esoteric ones in a follow-up.

May be slightly OT but not irrelevant, since there has been some statistical display of facts above...

How about doing some stats about the Overlay itself as by now many users have already downloaded D7 and that Overlay has been made somewhat "accessible" so far, taking it to "new" non-biased users giving them also the option of the MOST downloaded and used Admin module ?

So lets have a stats ( based on respondents' survey perhaps like the above graphs)

- how many think overlay is accessible and usable?
- what percentage has put it off
- what percentage has put it off and using Admin module instead ? (stats of this is available in d org)

That should be logical unless we follow logic only in case of stuffs like browsers or screen readers and follow our "hearts" only in case of Overlay.

@kaakuu ... except that one of the main issues that is being discussed here is that a screen-reader user has no easy way to disable the overlay as it stands in HEAD right now.

So how do we choose screen readers ?

The issue title was changed in #151 much after and sort of arbitrarily as "accessible" has a broader meaning in terms of usability, comfort as well as takes many other browsers and OS such as those in mobile and handheld systems.

We choose screen readers according to stats ?? and what we choose that for, we do not follow any stats??

@kaakuu Can you please stop derailing the discussion - any discussion regarding usage and viability of the overlay should be in #659488: Properly test the overlay to determine if it belongs in core or contrib .

webchick's argument was that we should focus on fixing the critical bugs for the primary and secondary technology first and focus on the edge cases with more specific followups. For more on that see http://www.webchick.net/please-stop-eating-baby-kittens , fyi for UX I had to get used to this too.

@Everett I am trying to test with JAWS now, it seems to work fairly oke with the newer version - but having trouble finding older versions.

@casey looking forward to your patch.

Short comment on what I've been testing/came up with.

Best ARIA solution to hide the parent page is to wrap its content in a div with role="img". This is semantically correct as this is what the parent page actually is; the parent page is a visual indication of the context the overlay is opened from.

According to the ARIA roles documentation the children of role="img" should be considered presentational and thus not be added to the accessibility tree. Unfortunatey, FF nor IE implement this correctly.

Another semantically correct solution would be adding the "presentation" role to all elements of the parent page. This appears to work for both FF and IE8. We could combine this with patch of David for browsers that don't support ARIA; David's solution would work as a fallback.

Drawback of this solution (David's patch has the very same drawback) is that we have to traverse the whole DOM on opening/closing the overlay to add/remove the presentation role.

I'll try to post my patch today.

@casey: Yup, that sounds great. If those two approaches can be merged, then we get the best of both worlds :) I was wondering about the DOM traversal a bit. I think compared to some of the other things that go on when the overlay is opened, that is not adding much overhead? On the other hand, I haven't really tried it out with a large, complex page underneath the overlay.

@mgifford: Thanks for setting up the demo site. Regarding the issues you noticed:

There are two Skip to Main links in the page which isn't very useful. Not sure if there is a way to bring the Overlay's Skip to main up to the first link & just replace the old one but it's just annoying.

Yeah, I had noticed that too, but forgot to file a bug :) I created #841184: "Skip to main content" link doesn't work correctly in the overlay now. I think it can probably be a separate issue, although maybe in the end we will wind up having to merge a fix for that into here.

The link to close the Overlay doesn't say "Close window" it says 'updates' on the Available updates page. This changes to 'settings' if you click there.

Patch here which should hopefully fix that: #841194: Overlay close button doesn't have a title in screen readers

I didn't see the enhanced iframe titles.

The titles appear as the title attribute of the iframe element itself, i.e. <iframe title="some title">. Those titles were already there (all my patch did was change the wording). AFAIK, they were put there originally so that screen readers could access them and get some information about what the iframe contains, but it's not something I've ever tested personally.

Initial patch (still have to merge David's patch).

I tested overlay in FF3.6/IE8 using JAWS 10 and NVDA. Both browsers seem to work fine.

Expected behavior for aria supporting browsers when opening overlay:

1. AT says something like: "Overlay containing the administrative page @title (dialog)"
2. cursor is moved to the first tabbable element, currently skip link
3. AT says: "Skip to main content (same page link)"
4. Content of parent page is not accessible, except for elements inside a overlay-displaced element like the toolbar

Expected behavior for aria supporting browsers when focusing the close button:

1. AT says: "Close overlay and return to the previous non-administrative page. (link)"

Expected behavior for aria supporting browsers when the overlay is being closed:

1. cursor is moved to the last active element of the parent page

Combined with David's patch.

David's patch added a link to the underlying page messages. It is however not possible to combine this with aria; the links can't be removed from the accessibility tree of aria supported browsers. Therefor I removed those links.

Looks interesting!

However, I think we also need to merge in the part of my patch that moved the overlay up near the top of the HTML document (underneath the toolbar). The reason is that for screen readers which do not respect ARIA, we need to ensure that they can read through the page in a sensible order. They should not hit the "underlying page" stuff until after they have gotten past the overlay.

Just curious to know : has the overlay got any significance to screen reader users? Is it useful or helps in any way? Does it make things complicated or easy if overlay is accessible? If it complicates, it defeats "accessibility".

There is no real difference between a modal dialog and a modeless dialog as far as a screen reader is concerned.

http://zufelt.ca/comment/22#comment-22

@kaakuu, I will ask you again to please stop commenting on this issue unless you have a concrete suggestion for making overlay more accessible. You're essentially trolling at this point.

Ok can anyone whip up a patch to address #169.

@Everett Is it possible to test the then created patch? Or just general feedback on the chosen approaches?

@webchick regarding #160, because NVDA is free and such a new player, I agree that we need to test only the latest version. But it's also an incredibly huge player, given how new it is to the scene. NVDA wasn't available before 2007, so in two to two and a half years — WebAIM's survey was done in October 2009 — NVDA has gone from being used by nobody to being used by 26 percent of all respondents. That rapid growth is likely to continue, because NVDA is free.

Based on NVDA's growth rate, I think we absolutely have to be sure that Overlay is accessible with it. (Fortunately there aren't as many OS combinations to consider — NVDA is available for Windows only.)

Reroll with #169 in mind.

I tested the patch above in VoiceOver and captured it in Screenr:
http://screenr.com/1NR

We need to get similar versions for Jaws & NVDA for sure. However, I was able to navigate through Overlay effectively.

There are still problems with Skip to Main Content. Likely some other issues too.

Sadly Screenr isn't accessible so people wanting to listen to this who are blind won't be able to hit play. Anyways, I expect most of them can see this themselves.

It is presently applied here http://drupal7.dev.openconcept.ca/

Fascinating to see this. So are you navigating by hitting Tab button again and again? What appeared most irritating is that you always had to start at the first Button of the browser itself and tabbing all the way down.

But I guess Screen reader users are used to this? The computed voice is so hard to understand...

It is certainly interesting to watch it if you've never tried to browse the web without a mouse. It's a useful exercise. Yes, I was just using tab or shift-tab to navigate through the page. There are also ways to jump between the headers which is why they are important.

The Skip to Main link should be the first think that the browser tabs to. Without Overlay it zips right down to the body of the page and cuts out a lot of effort to tab across it. With Overlay it's just broken.

There is progress on this however.

Although most folks who use screen-readers can get used to listening to the page be read much faster than it was in the demo, it is a problem (and not one that folks just adapt to). It's also not just for screen-readers. This is a video of a friend of trying Drupal out for the first time:
http://www.youtube.com/watch?v=NyIHtNHYroM

It's pretty old, but without the Skip to Main links working it still holds.

+  if ($('.region-page-top').length) {
+    this.$container.insertAfter('.region-page-top');
+  }

This assumes that the overlay always belongs between the "page top" region and the rest of the underlying page, but depending on the content of the page top region that might not be the case - it might be intimately connected to the rest of the page, and not something that should be interrupted.

The original code I had addressed this issue by looking for overlay displaced regions (like the toolbar) within the page top region before using it in this way. Was there something wrong with that approach?

Here's a reroll that addresses that issue, but still limits us to putting the overlay no lower on the page than underneath the "page top" region (which my earlier patch did not do).

All I did was change the above-quoted code to this:

  if ($('.region-page-top .overlay-displace-top').length) {
    this.$container.insertAfter('.region-page-top');
  }

Otherwise this is the same as #174.

+      <a id="overlay-close" href="#" class="overlay-close" title="<?php print t('Close overlay and return to the previous non-administrative page.'); ?>"><span><?php print t('Close overlay'); ?></span></a>

The "Close overlay" text still doesn't actually display to screen readers AFAIK, since it's being hidden by display: none. It should use element-invisible instead. I already did this in #841194: Overlay close button doesn't have a title in screen readers but if we're touching this code anyway we could just merge that in and fix it here too. Wary of turning this into a mega-issue, though :)

David, the patch in #179 is an improvement again for #VoiceOver.

I've applied the patch & the element-invisible discussed in #180 here http://drupal7.dev.openconcept.ca

Please let me know if you can test this with other AT.

@David_Rothstein - Here's a report on using Overlay Windows 7, IE8 & JAWS 11 and Window-Eyes 7.

The summary of @jkiss' experience is:
"the few times that things went smoothly, links and functionality seemed to be clear and work well enough in JAWS 11 and Window-Eyes 7.2, but these instances were indeed few in number"

From the Accessibility IRC discussion earlier in the week it seems that the very minimum that we need to do to address accessibility concerns is provide a means for users to easily disable overlay #659480: Per-user setting for the Overlay and continue working to implement improvements in Overlay's accessibility even though we have to accept that it may never be compliant for even the most recent versions of JAWS, Window-Eyes, NVDA & VoiceOver.

There certainly should be more done to make Overlay more accessible, but at least for D7 I don't think that it will be accessible enough to be a mandatory module.

@mgifford, from quickly skimming that report I don't get the impression that the overlay was tested with any of the patches in this issue, or at least with any of the recent patches. Was it?

(In particular because of this sentence: "focus nonetheless goes to the non-administrative page underneath and I need to navigate through that page before getting to the overlay iframe". The overlay iframe is no longer at the end of the document with the latest patches posted here, so that should really be impossible I think.)

I set up Overlay on my dev server here with the patches you provided -> http://drupal7.dev.openconcept.ca/

I just took a diff of modules/overlay to compare it to the patch that you provided in #179. Although not identical, that element is the same.

The only areas that are different are that I have also applied patches from #659480: Per-user setting for the Overlay & #841194: Overlay close button doesn't have a title in screen readers however those don't affect the iframe issue.

Screen readers are working with same standards based guidelines that browsers are. Sadly, we can't assume that they will play by a common set of rules.

@mgifford, I tested latest patch in JAWS 10/NVDA using both FF3.6 and IE8 and get results as outlined in #167. Don't you?

@casey - I didn't do this test, but another accessibility guy did.

Please test as per #167 on http://drupal7.dev.openconcept.ca/

Would be good to know if your results still work.

Full result of the test is posted here:
http://drupal7.dev.openconcept.ca/node/107

@casey, can you describe your patch? Should I replace the one I have on my sandbox with yours & get people to re-test it in Windows-Eyes & Jaws?

Did you have similar experiences in my sandbox as I'd described?

Yes, please replace the patch. I will create a screen capture afterward.

Your new patch is applied here - http://drupal7.dev.openconcept.ca/

I also attached class="element-invisible" to the overlay.tpl.php file so that close wasn't hidden from screen readers.

After more comprehensive testing again of the overlay implemented at http://drupal7.dev.openconcept.ca, here are some more, and in some cases slightly better, results:

IE7 and IE8

• whether or not JAWS or Window-Eyes is running, i'm regularly getting the "script slowing down your browser" message, though after selecting "No" and letting the script continue, the overlay does load.
• whether the "script slowing down your browser" message is related to all the JavaScript and the overlay content being loaded/written in conjunction with IE's slower JS engine, or something else entirely, I don't know.
• upon closing the overlay, there is the following JS error: Exception thrown and not caught js_7sk8WxhA4f0IM-HRs4ldo7FsYqgXjP7VMGY_iN7XB3k.js, line 77 character 399.
• whether or not JAWS or Window-Eyes is running, in an overlay where the content has tabs, e.g., "Content" and "Appearance" admin overlays, after selecting a different tab, e.g, the "Books" tab in the "Content" overlay, the "Close overlay" link no longer closes the overlay, a second scrollbar shows up on the right, and in addition to the "Exception thrown" JS error noted above, there is also the following JS error: Permission denied js_xtRt3xHqrz5AxSzzzGLvI0uS9nvvW7n2fDtvX7kDAIA.js, line 23 character 306.
• This doesn't seem to happen at all in Firefox

JAWS 11 in IE8

• getting some better, more consistent results, now
• when the overlay loads, focus is moving to and JAWS is announcing the "Skip to main content" link
• the underlying page is not accessible while overlay is open, and when tabbing up to the admin toolbar from the overlay or back into the overlay from the admin toolbar, JAWS says "Overlay containing the administrative page @title frame"

JAWS 11 in Firefox 3.6

• after opening the overlay, JAWS says "Overlay containing the administrative page @title dialog", focus is set to the "Skip to main content" link, which JAWS also announces; the same thing occurs if you happen to be tabbing into the overlay from the admin toolbar
• if the overlay content contains tabs, after selecting a different tab, e.g, the "Books" tab in the "Content" overlay, focus is set to the "Skip to main content" link, JAWS reads it, and stops
• all seems to work consistently and fine in this combination

Window-Eyes 7.2 in IE8

• when things work well, the overlay loads, Window-Eyes summarises the page, e.g., total number of links, tables, headings, etc., then starts reading the page from the overlay's "Skip to main content" link; at this point, pressing the TAB key moves focus from the "Skip to main content" link to the "Close overlay" link.
• sometimes, after selecting "No" in the "script slowing down your browser" warning dialogue, the overlay fails to load, at which point it is very difficult to continue or refresh the page
• sometimes, after selecting "No" in the "script slowing down your browser" warning dialogue, the overlay loads, but is not at all available to Window-Eyes, which only sees the admin toolbar and the content in the underlying page, e.g., pressing TAB takes through all the links in the underlying page

Window-Eyes 7.2 in Firefox 3.6

• this is not specific to the overlay, but in Firefox, Window-Eyes has some strange behaviour with links whose text is made up of some visible text and some text that is made invisible with ".element-invisible": it reads each portion of the link text as an individual link. For example, when you first TAB to the "Content" admin link, Window-Eyes says "link, content". Press TAB again, and Window-Eyes says "link, administer content and comments". Visible focus does not change, and the link works no matter on which portion of the link you press Enter. But, it takes two TAB presses to get through each of the main admin toolbar links that are constructed this way, and each portion of the link is listed as its own link in Window-Eyes' links list, for example, both "Content" and "(Administer content and comments)" are listed as links in the links list dialogue.
• Window-Eyes does not consistently set and keep focus on the "Skip to main content" link in the overlay after it loads. Much of the time, in my tests anyway, the overlay loads, the "Skip to main content" link is visible with focus, but then it disappears, and focus seems to move to the top of the admin toolbar or somewhere random in the page, from which Window-Eyes starts reading. In these cases it doesn't always seem to then be able to find the overlay iframe content, either only allowing access to the underlying page, and sometimes showing that strange behaviour I noted several days ago with JAWS, namely prefacing every link on the underlying page with "You have left the overlay and are now browsing the underlying page".

Hope this helps.

Unfortunately the patch is pretty heavy on performance.

In IE it may cause "script slowing down your browser" messages (like @jasonkiss experiences in #191). Although not that extreme performance in other browsers is also affected.

When opening/closing the overlay, the patch traverses through the whole DOM of the parent document. The larger the parent document is, the slower the script gets. This is necessary for both my and Davids approach (#151).

We might optimize the patch a bit, but I think it keeps being a performance hog.

@jasonkiss, thanks for testing! So yeah, it sounds like most (all?) of those issues are performance-related? It's hard to say. I also wonder if there is some kind of race condition going on, since we are doing the performance-heavy stuff in a setTimeout()....

@casey, do you know if it's really required to add the "presentation" role to every single element - i.e., no way to make it inherit? The text I added does not require traversing the entire DOM by itself - for that we could do something like $elements = $('a, address, h1, h2, h3, h4, h5, h6, p, li, td, th') and then loop through those, which is not blazing fast, but I assume would be a lot faster than traversing every DOM element one-by-one. Do you know if there is any way to take a similar shortcut with the ARIA role?

@David_Rothstein, see #165; I don't think so.

Optimization seems to be working miracles however.

What are the differences between the patch in #196, and #197?

XP/FF 3.6/JAWS 10: Video of testing

Tests on WinXP:

• JAWS 10
  • FF 3.6 (Video)
  • IE8 (Video)
  • Safari 5 (Video)
  • Chrome 5 (Video)
• NVDA
  • TODO

Casey, so patch 200 is working for you in your tests with Jaws 10. Why Jaws 10?

Thanks for posting the videos.

Is this mostly about performance improvements to the script?

Because I only have JAWS 10 (and NVDA) installed.

Yes mostly performance. I also fixed the skip-link.

Performance improvements are good for everyone. Thanks for doing this.

I haven't done an exhaustive review, but thought I should contribute a screenshot with VoiceOver at the very least. http://screenr.com/PCX

There are problems with the Skip to Main links not going where they should, but think that boils down to:
http://www.communis.co.uk/blog/2009-06-02-skip-links-chrome-safari-and-a...
http://www.russback.com/javascript/fixing-anchor-focus-in-safari-and-ope...
http://stackoverflow.com/questions/2292016/is-there-a-workaround-to-safa...

Not sure how much we can do to fix that. Apple's got to work on Mac's accessibility a bit more perhaps.

Chasing HEAD...

@Everett, could you give this one more review? At least for ARIA supporting browsers I think overlay is quite accessible now. It is almost like you're just opening a normal link. Does opening admin links behave differently when using the overlay compared to without the overlay? Could you outline those differences? Maybe things that normally are being said by the AT and, when using the overlay, is not?

Overall I think this is an improvement to the current behavior.

Hey, you've been making performance enhancements. This works for everyone. I'm tagging this for performance as surely this should benefit everyone.

If I'm not mistaken, the main performance enhancements in this patch actually only affect code that the patch itself added... so the overall effect might still not be a performance improvement, just less of a performance hit than otherwise would be :)

I looked through the code quickly and it looked pretty awesome but haven't had time for a full review of the latest patch.

@David_Rothstein - thanks for the clarification.

removing performance tags as per #206

So as of today this is the only item in the critical queue for the overlay module! Reviewing the code I think casey has done fabulous work. It looks like there's some more optimization that can be done in the traverse() function, which I'm kind of itching to work on, so I'll take a look at that today. But as long as we can keep applyARIAPresentation() from slowing things down too noticeably, this is just fine from a code perspective.

I'm a little concerned that we haven't heard from Everett in a month. Everett, are you out there? :)

Everett Zufelt: The patch contains a fallback for screen readers that don't have ARIA, so it is intended to produce noticeable improvements in all cases.

***

While I'm writing here, I noticed this a while ago while looking over the patch but it wasn't worth a separate comment to point out :)

<+  // This function is highly optimized and uses as less jQuery as possible as

Should be "little", not "less".

The last time I looked at this patch I thought it was fine otherwise - I worked on it too much to RTBC it and I'm not sure the current state of testing with various screen readers, but it seems like it will really lead to some big improvements. So we should probably try to get it in soon and leave further improvements for (non-critical?) followups.

I disagree that this should go in as is - it's a perceptible performance hit, at least for me. I guess I should have moved it to needs work, so I'll do that now. Fortunately, there are perfectly reasonable improvements that can be made. For example, we have an inline function being called recursively. That is probably not wise - it's adding the closure to the scope chain, and there's no need for it. We also need to test whether the regular expressions are necessary. I'm guessing an object with properties for each tag name will be faster. At any rate, I should have an updated version posted today.

Yes, that is what I meant by "we should probably try to get it in soon" :)

(In other words, talking about not making additional accessibility changes here; continuing to improve the performance is different.)

continuing to improve the performance is different

Whew. I feel better. :) And yes, I agree we should go ahead and add this, and make further accessibility improvements in a follow-up issue.

The attached patch removes most of the inline closures. It also moves a call to updateARIABuffer() from inside an event handler, so it only gets called once on overlay close.

The performance cost on overlay open is negligible (about 35 ms). Overlay close is harder to time, because of the event handlers, but to me it feels quite zippy. @casey, it would be good if you would look this over and test it again, to make sure I didn't miss anything in my mad closure-killing quest.

@Everett Yes, you are able to disable it easily on your user profile. As discussed in #659480: Per-user setting for the Overlay , we accepted that functionality exactly for your described reasoning to make it possible to disable for any of anyone who's despite our optimization it still doesn't work for.

In the other issue you said :

"I don't believe that the current approach makes the setting easily discoverable and understandable. Remember, this is not a preference, it is a requirement for accessibility (although I think I have long since lost that argument).

That being said, this is a much better approach than having no option at all, and I can't really think of a better location for the seting than on the user page."

I mean, unless you have a solution for that particular issue - I honestly feel the best thing to do now is to let this optimization go in.

So we already knew in #659480: Per-user setting for the Overlay that it wasn't a particularly easy to find setting for new users. But the alternative would be a right-up-in-your-face-setting which is bad in terms of UX for the people who have no difficulty with it? I mean unless you have a solution that doesn't do that, I think we should let this optimization in.

I am somewhat saddened that you didn't chime in on the other issue, when we where asking for your feedback if it actually fixed the accessibility issue regarding the point your making - apparently it isn't.

We could add a link with class "element-invisible" next to the overlay close link reading something like "Overlay user-preferences" and linking to /user/{id}/edit/#{overlay-fieldset-id}.

But lets focus on this issue first. I'll retest patch later today.

@Everett Can you join us in a line of thought of finding a solution that does such a pointer? I would love something "element-invisible" as casey suggests, since a message saying "You can disable the overlay on the user settings page" is obviously a bit obnoxious.

Duh I missed an essential part of the patch since #204; updating the buffer and moving the focus after opening the overlay... Sorry about that. Could you give it one more try?

Note that overlay does not change to application mode.

Cannot the overlay go off by default as soon it recognizes the client agent is a screenreader?
[the prized Overlay is there but just hidden to the screen reader, for better accessibilty]
If that is possible, will that be not more user friendly?

[ We had one folk story in our childhood : the earth was full of dust and the mighty king summonned all the pandits and geeks how to prevent the feet from catching dust and getting soiled. There were suggestions and implementations : hose the soil with water, cover the earth with tiles, clean every few seconds etc etc .
Then, a man came forward with the idea/model of "shoes" - that is how you cover your feet only and that is how you had the first shoes! ]

kaakuu: there was a lot of discussion earlier in this thread, and that was eliminated as a posibility because there is no reliable way to know that a user is using a screen reader (in Everett's review in #223 he is using Safari, for example). Also, doing browser sniffing can wreak havok on caching and CDN's, and there were a few other reasons that I cannot remember...

But no, there that is not a viable solution

@ bleen18
Websites, most of them, continually assess what the 'client' is - examples: conditional css if IE or certain CSS codes for firefox, whether the user is accessing from mobile and redirecting to a mobile theme, providing flash if the client has flash. I am not aware how this causes havok.

If php cannot detect screen reader we may submit an issue to php.net with a long-term goal?
For short term, I find that this solution is being used by many to detect whether the 'client' is a screenreader - see this link and scroll down to "Detecting Screen Readers" - http://webaim.org/techniques/flash/techniques#detecting

@kaakuu: conditional stylesheets are handled client side, not server side. The identical markup is delivered to someone using IE6 as someone using chrome4; mobile redirects are exactly that, redirects. What you suggest in #225 would be delivering different markup on a per client basis and CDNs like Akamai need to be specially configured to deal with that.

All that aside, though the problem of detection is still there. And it's not necessarily a php problem. For example, I can use Safari with "voiceover" but as far as every HTTP request is concerned, I'm just using safari - the request does not provide any clue that I'm using voiceover and so PHP has nothing to work with.

The link you provided is interesting, but it clearly says:

(currently only up-to-date versions of Window-Eyes, JAWS, and IBM Home Page Reader) ... Finally, this method of detecting a screen reader, will not detect all screen readers. It will only detect the most recent versions of screen readers that support MSAA and have the Flash 6+ player installed

This reliance on only the latest software is one of the main sticking points that Everette has been bringing up... and its reliance on Flash is something that isn't going to fly in core I suspect.

As you can see from the loooooong thread, this is not an easy problem to fix. I think the patch in #224 is going to be pretty close to a workable solution

Thanks. Problems remain but we need to see what satisfies most users. Problems mean NOT we do not tread that path.

So far as " reliance on Flash is something that isn't going to fly in core" the problem is that Overlay itself is MORE "flashy" than Flash itself. When using it we are not sticking to lean, minimalistic, baseline stuffs :)

The focus of this issue is to make the overlay itself as accessible as we possibly can. Ideas for detecting screen readers (and refutations of those ideas) belong in another issue; please feel free to file one. Let's keep the discussion here on topic so we don't balloon to 300 comments before commit.

@Everett, thanks for testing!

JAWS activating application mode is pretty weird, as overlay doesn't. And about the separation; looks like the trick used to update JAWS virtual buffer doesn't work for JAWS 11 (it does for JAWS 7 - 10). Overlay adds the presentation role to all elements of the parent page so it really shouldn't be accessible. It works for JAWS 10 at least.

About the behavior in VoiceOver; if the user thinks he's taken to a new page, than overlay is accessible. Overlay is just a visual layer, keeping the last non-administrative page (context) visible in the background. This is what JAWS is supposed to do too.

I agree "Close the overlay" is not easily perceivable. What about "Return to last non-administrative page"?

Some more options to force a virtual buffer refresh.

In #125 I suggested "This form uses Drupal's overlay which can be disabled here."

"Return to last non-administrative page"?

I would have no idea what that means, and I wouldn't expect the target audience to, either.

@Everett It can be used by anonymous yes, its merely a permission thing. However that is probably a very unlikely scenario.

@Bojhan, I agree that it's "probably a very unlikely scenario," in part because I am skeptical that Overlay will turn out to be as usable as we seem to have decided it will be. Where's the usability test data that says this proposed solution to the problem of users losing context actually works? ;-)

@Everett, I consider that WebAIM survey to be overly optimistic. I'll bet that someone who is "highly experienced" with the "pop-up windows" of MS Office would be a novice with a modal dialog, pop-up window, or overlay in a new application.

You've got to learn the lay of the land before you can navigate in the dark, and it's hard to learn the lay of the land when you never get a chance to see it.

@Everett

I'll try to get my hands on JAWS 11 and to get the patch working for that one too.

The back button is expected to behave like if the overlay doesn't exist. So the behavior you describe is correct. The close button however returns the user to the page from which the overlay was opened.

I'll post a new patch containing a hidden link (but tabbable) next to the close button with the text suggested by Everett. But lets focus on the current patch first.

@Cliff, ok what about "Return to the main website"?

About the WebAIM Screenreader User Survey. The patch tries to make it for ATs (ARIA supporting) look like if the overlay isn't there, as if the user visits a new page. So the overlay shouldn't be considered a popup.

For older (non-ARIA) ATs we use a fallback message, added all over the DOM of the parent page. So if the user traverses out of the overlay he'll encounter those messages. Not pretty but, it might be better than nothing. In this case the overlay could be considered a popup.

@Cliff, forgive me if I am wrong, but I get the feeling you are just trying to be destructive on this issue. Have you even tried overlay using an AT?

@Cliff I have to agree with Casey here, this is not the right thread for this kind of discussion. We already have that over at #659488: Properly test the overlay to determine if it belongs in core or contrib.

Anonymous users is really really unlikely scenario, sure we can expose a one-time exposed check box linked to a cookie in that case. I mean even if we don't find a solution for it, it shouldn't hold up this issue. Lets focus on the issue at hand, please - casey is doing hard work, lets not waste that on way less important discussions.

"Any thoughts on how an anonymous user can disable Overlay?"

Overlay, in whatever incarnation it is and in however "constructive" way it is being attempted to be presented is nothing but an annoying pop-up. Sites like Facebook have this, one might say, but these are much smaller and do only a tiny portion of a task and yet motion is building up on them to return to the expected and normal browser behaviors. Thus future versions of Firefox and Opera (if not IE 9 also) will have something like pop-up blocker that blocks all these stupidity.

Currently FF has Page style>No style option and soon the real user ( not the usability dumbo test users) will have neat and nifty ways to block these stuffs.

So in short the answer is: anonymous user will be able to do that at that browser level what Drupal, unduly and without "test" data and favorable public opinion, may forcibly throw on her or him.

#244 gave a very specific on-topic answer to #242 - the question is within the quote.

@Everett, I can't really reproduce the behavior you encountered JAWS 11; I get the same behavior as you described for VoiceOver in JAWS 10 and JAWS 11.

Do you use custom JAWS settings?

I have no idea what causes this then.

@Everett

Uh VoiceOver handles the iframe as a seperate document you need to open/interact with before it is accessible? That I didn't understand earlier. I thought the presentation roles on the elements of the underlying page where doing their jobs.

And on JAWS: are you still able to access the underlying page while the overlay is open? If so, I am getting totally different results than you.

I am trying to understand this issue, and I really can not by now.

I am using Debian, GNOME, Orca, Firefox 3.6.8 environment for screen reading, and __I am able__ to navigate through the overlay on all the cases I tried. The "skip to content" works as expected, so I think I am missing something, or maybe it works only in my environment, can someone help me to understand the problem? (I am on the core dev summit sprint)

So I think we can continue improving accessibility for the overlay (even if its a bit hackish). I applaud caseys work on this, an near heroic effort :)

But lets for the sake of getting this issue fixed, add in the pointer mentioned in http://drupal.org/node/716612#comment-3324218 if thats what needed for this to move forward? (ie towards, somewhat fixed) Everett said it could be a on:focus like the skip link?

Can it link to the user profile page?

If we add that link to disable overlay, would it be per session? Per user? Per-manently?