Make sure that the overlay is accessible

adding tag. I'll try to review this shortly.

Might be adressed in an earlier issue, but couldn't really find it: is there a reason why an iframe was chosen?

Not critical. Please read and understand Priority levels of Issues, thanks.

@sun.core

I agree that there is no apparent critical accessibility issue being raised here. However, since there appears to be a great deal of confusion about the accessibility of Overlay then it is critical that accessibility be reviewed. I do not have free time to do this myself, but strongly recommend that someone review the accessibility of this module.

note: in the implementation of d7 I am running overlay is disabled for personal convenience.

Just filed bug: #716612: Overlay is not accessible to screen reader users

Just filed #717810: Some screen-readers do not respect overlay as 'modal' dialog.

Regarding modal dialogs and accessibility for screen-reader users. I have written a blog article Can a modal dialog be made to work properly for screen-reader users on the web?. The short answer is kind of, but not really. I would have posted the entire article here, but it is a lttle to long for that. It explains the objective problem, as well as the subjective experience.

@David_Rothstein - It's been a while since I had time to look at this issue but did wonder about providing a hard coded link within the iframe which a user could click on to break out of the iframes.

I do think that individual users need to be able to disable Overlay (for either accessibility, performance or because they prefer the classic functionality) as suggested here:
#659480: Per-user setting for the Overlay

Here's some code which is focused on screen-readers:

<iframe src="/node/2/edit">
<p class="element-invisible">If you can see this text, your browser does not support iframes 
<a href="/user">disable the Overlay view</a> for your account.</p>
</iframe>

@sun Is wrong, any issue that prevents a large group of users from working with it - should be marked critical. This should be considered a bug, not a task. We pride ourselves on being accessible, yet fail to be from the essential UI components.

I am confused as we asked for an accesiblity review in the early stages of development on the overlay, and got one - which led us to believe we where not encountering these issues.

I truthfully thing that having any "easy disable" or "do not install overlay" is just an easy work around for the problem. It would be great if Drupal can be one of the first to properly work something out for this problem, as I see Drupal growing more in context - the need for modals is becoming more prominent.

Given that, lets find the two problems and work on them. As I read from the article. Are there two problems :

1. Perceiving the existence of the model dialog
2. Accessing the iframe, separate from the underlying page

Perhaps separate those two out, and work towards solutions?

I would prefer a single "review core for accessibility" critical issue, then open sub issues for any modules which specifically need testing. Also is there anything here other than #716612: Overlay is not accessible to screen reader users to be done?

@Catch

AFAIK there is nothing to be done for Overlay accessibility other than #716612: Overlay is not accessible to screen reader users.

The problem is essentially that a modal dialog is a complex UI component. There is currently no reliable way to convey information about the component to assistive technology. ARIA 1.0 is still a W3C draft, and the support for ARIA 1.0 is inconsistent across browsers and assistive technology. There's also a question of whether one document overlaying another is really technically a dialog, or something different. My thought is that the jQuery modal dialog should contain one descendant which is a container with the ARIA 1.0 "document" role. Which is semantically correct, but likely won't resolve the issue.

OK, I opened #755790: Review core for accessibility before release, and I'm downgrading this one.

I don't think that's going to be a good approach.

Sidelining all of the accessibility problems into one massive meta "review before release" is just going to sideline the issue.

The closer the accessibility issues are tied to the module that they are associated with the more likely they are going to be addressed.

Drupal's great in many ways, including that it has a relatively small core. That being said, there really aren't many of us doing accessibility reviews of the site and we're still running into things like #736604: book module now without clearfix & better markup + accessibility love after two years of evaluation.

Fixing it at the end just never seems to work as an approach.

I think that we are safe to close this issue since the actual issue is reported in #716612: Overlay is not accessible to screen reader users and the meta issue to track all core a11y issues is at #755790: Review core for accessibility before release.

ok

removing tag.