After discussing the d7ux overlay accessibility issue with several at Drupalcon, and mentioning the issue in my lightning talk at the Core Developer Summit I noticed that an Allow users to opt-out of the overlay issue had been opened in the bug tracker. Overlay is a contentious topic for some in our community, and I will not rehash all of the pros and cons for Overlay's inclusion in core. I will however attempt to concisely present an argument for Overlay being disabled in all Drupal 7 core installation profiles.
-
Drupal is an inclusive community; we are building a tool to be used by everyone; nobody should be excluded (if at all possible).
-
Overlay, based on the jQuery UI Modal Dialog, cannot be made to work for all users. You can read my explanation of this by reading Can a modal dialog be made to work properly for screen-reader users on the web?. You may also be interested in reading through the jQuery Accessibility mailing list topic on dialog accessibility. In summary, it is not jQuery's implementation of modal dialog, but the fact that not all assistive technologies can currently properly interact with a modal dialog on the web that causes the problem.
-
Since we are enabling, by default, a module that will cause significant problems for some unsuspecting new users, then we are not being a responsible inclusive community.
Pros of disabling Overlay in all Drupal 7 installation profiles:
-
No unsuspecting user will be confronted by an overlay that they cannot use.
-
When site admins go to enable the overlay module we can provide them information about the accessibility limitations of the module, allowing them to make the best choice for their user base, meaning less users are excluded.
Important note:
I wish that overlay was not a problem. I wish that modal dialogs on the web were accessible to all users, so that this problem would not exist. But, this is not the case. Our community finds itself in a difficult place, and we need to make a difficult decision. Do we continue to show the world that we are an inclusive community, building an inclusive tool that can be used to grow inclusive communities, or do we choose to make choices that are counter to our community's cultural values and to exclude what is arguably a small subset of members for sake of convenience. We must decide as a community which direction we will go.
Comments
What does Overlay do?
Everett, I understand the general nature of the problems with Overlay, but I'm not sure what the module does to begin with. Can you (or Brandon or Mike or anyone else) give a brief explanation of what purpose Overlay serves and how that affects the interface for people who are not disabled?
One reason I'm asking is that I'm trying to get a sense of where in the process of creating or administering a site it makes sense to be able to turn this on or off. Also, I wonder if it's the kind of thing that I could turn on at times and turn off at others. This information will help me at least have a chance to propose a viable solution.
I am eager to help and do agree that you are on the right track.
Overlay basically adds a
Overlay basically adds a jQuery Modal window over the top of the content. It's like a popup window that isn't a popup. It shades the background behind it. You can see it in many places, best example is in Picasa Desktop app when looking at a picture, or many websites that do an advertisement overlay window when you first go there.
Drupal evangelist.
www.CoderintheRye.com
I should have searched
Thanks! When my brain kicked in, I also did a search of drupal.org and found this succinct explanation of the Overlay module, with pictures.
I'm wondering if we can't
I'm wondering if we can't make overlay work though. I used jQModal in my module, SaveToFtp, and without the modal overlay window on, it just fails gracefully back to a normal form. Surely we can do something similar for overlay in core? Then the forms just end up at the end of the page.
Drupal evangelist.
www.CoderintheRye.com
What triggers the failure?
Kevin, I think — I'm not sure, but I think — your example might involve a different concept. I see these as two separate issues:
The point of graceful degradation is to ensure that I still have a tool that works, even if my software won't support the fanciest tool you offer. The fanciest tool must still be accessible, because my software status is independent of my (dis)ability status. Many people who have disabilities use Javascript; many people who have no (known) disabilities don't. So your fancy-schmancy tool must be accessible, and if I have Javascript turned off, it must degrade into a plain-as-dirt approach that is also accessible.
But in this case, the fancy tool provided by Javascript — the modal overlay window — is inaccessible to people who cannot see. So it's a barrier to anyone who has Javascript turned on but cannot see.
In such cases, the right answer is progressive enhancement. In other words, we need to make the default something simpler and less elegant that works for everybody, but give everybody the option to turn on the more elegant tool if they want it. That's the approach @cwgordon7 proposed in the issue Allow users to opt-out of the overlay. So the proposed fix is fundamentally sound from that perspective.
This tool is used in administering the site, so it makes sense to me that the option to turn it on should be available when I'm specifically setting up the admin interface. If I understand Allow users to opt-out of the overlay correctly, that's what the patch did.
This tool also can be made available to individual roles through permissions. It seems to me that what those users should get is not this potentially inaccessible interface, but the option of turning overlays on if they find them convenient. That notion was raised by @mfer in the discussion of a similar issue, Add ability to easily disable overlays.
Maybe we need to combine those issues and join @mfer and others in calling for the Overlay module to be an opt-in, not an opt-out, feature in all cases.
@nowarninglabel I would love
@nowarninglabel
I would love to hear your thoughts on making jQuery modal dialogs work. I am not interested in exploring this concept any further without someone showing me an example of an accessible modal dialog on the web.
Can you explain what you mean by graceful degradation? As I understand it, you are saying that if you disable the modal dialog then it gracefully degrades. Doesn't this counter the logic of using the modal dialog altogether?
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Yes Everett, unfortunately
Yes Everett, unfortunately this would probably be the concept of separate but equal, though it would still be on the same page and transparent to users I believe. Basically, if Javascript is turned off, or if we test javascript capability for the screen reader via some SimpleTest or something, and we find it can properly display the modal, then we would just turn the modal off completely and it would degrade into simply being a regular form.
I'm willing to consider that is the wrong way at looking at things, and am interested in your further thoughts on the issue. I need to go read the previous issues on it to see what the outcomes were.
Drupal evangelist.
www.CoderintheRye.com
Please be sure to read my comment above
Kevin, please be sure to read my comment above. I think that puts the issues in perspective.
Another idea
Overlay could be enabled/disabled easily during the install process, with some language explaining what could happen accessibility-wise. Even though I agree that making modal dialogs accessible is a noble goal, but getting to that point by a D7 release will be difficult. Even compounding the modal state of overlay is the presence of an iframe with repeating administrative menus that are available on the parent page, which would make a screen reader user think they were in the parent instead of the child.
Do we think there's any chance of getting a patch in that makes overlay an option on the install process itself? I could get a patch in if we think there's a chance of this.
Already an issue / proposed patch
@kevee
You can find the issue and proposed patch at Allow users to opt-out of the overlay.
Thanks
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Just to give some context:
Just to give some context: We'd rather not have it as an option in the installer, because it would clutter the interface, thus UX, for everybody with a setting that applies to few. It's discussed somewhere in this issue: http://drupal.org/node/775084#comment-2874792. That issue basically started out with the patch you propose here :)
Unless Overlay is off by default
@yoroy, if Overlay is off by default, then that checkbox would apply to the majority of users: They would have to check it to obtain the enhanced interface. And really that's the way it needs to be, because otherwise the default installation of Drupal 7 is inaccessible.
I understand that the powers that be will not consider adding that checkbox, and perhaps especially not if it's unchecked, but they need to understand that reworking the ARIA is futile for the reasons explained in my post below, which was meant to be a reply to @kevee's suggestion above.
I know this is old and I know I am new but..
but I think there should show research on this issue, maybe there is but i would like to see user research on how people feel with the "overlay module" vs "flat" is there any research out there ?
Adding a single, yet very large option in the D7 install process would not "clutter the interface" it would be a great function that allow the user the form they want to work in.
I have been using the Rubik theme with the admin_menu in D6 and have fallin in love with D6 and after testing out and building in D7 its just feels really bulky and I am now scared of D7... I would like to be able to turn off the overlay on install. The overlay module just feels a lot different, I don't know just my thought
Screencast of interaction to show the community?
Even though there's great documentation on the web in written form about the theoretical and practical limitations of modal dialogs, I think it might be even more constructive for sighted developers to see the real pain it is to interact with these elements. Would someone more adept than I like to do a recording with narrative of using overlay in D7? We use Silverback for these kind of usability tests, but it's Mac only and costs money (but it's free to use for 30 days!).
If noone is interested, I'll break out my VoiceOver cheatsheet in the next few days and try it out again.
Touch base with Mike Gifford
Yesterday Mike (mgifford) used an online tool to do a rough cut of pretty much what you're describing, Kevee. I think something similar to the video Mike produced might help people who don't quite understand the obstacle get a better appreciation for it. But in the final cut, it would help to take this approach, one step at a time:
If I have time, I'll do this, but I doubt I will have time before tomorrow night. Got to finally get to my Saturday chores for now.
Sadly Screenr isn't accessible
The Screenr service is a great way to capture video/audio and transmit it to Twitter. However, it's not a very good way to do this for Everett & other screen readers as the service doesn't allow you to press play to actually begin hearing the video. It's just fine if you can see the browser & use a mouse, but otherwise........
That being said, mostly we're trying to convey accessibility issues to those who can both see & always use the mouse. So not a great solution, but probably acceptable for the primary audience.
I do think it's more important to have examples to show folks what the struggles are like with D7 now than it is to have something polished & professional. We just need some brief examples to show folks some of the existing challenges.
For testing purposes it's also useful to note that VoiceOver doesn't work with FireFox.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Screencast
@kevee
A screen-cast might be useful. But, I think we already have community buy-in that this is a problem. All we are trying to do now is to decide on the best solution.
Thanks
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
That approach has been nixed
@Kevee, that's exactly what was developed in issue 775084:
Allow users to opt-out of the overlay during installation for accessibility. I'll leave it to you to read the thread, but let's just say that successful patch was shot down daily throughout DrupalCon.
People keep trying to work on the ARIA code to fix this, and they just don't seem to understand the actual problem:
Against that background, your proposal is the only reasonable approach, unless we just don't care about making Drupal 7 accessible. And I know that everyone wants Drupal 7 to be accessible, except for a few who are completely uninformed on why it should be.
We can produce a less flashy version of Drupal that is accessible and allows people to turn Overlay on and off. (It recently occurred to me that they must always be able to turn it off without having to encounter an overlay, because none of us who can see today knows for sure that we will still be able to see tomorrow. Wouldn't it stink to have the interface you picked be the only reason you couldn't continue to maintain your own site?)
But until the standards and two categories of technology sufficiently mature, we cannot make an overlay-based Drupal 7 accessible. In another related issue, eigentor is exploring a different approach. If I understand it, the result will mimic an overlay but not rely on ARIA. It might help for you to compare notes with him.
And if I've forgotten to say it before, thanks for your interest and support!
Ooops
@cliff Sorry about the complete ignorance of the D7 issue queue on my part, I haven't been tracking core this time around because of so many other projects. I agree, the moving target of ARIA makes these kind of things extremely dodgy, and while making a per-user option to turn on/off overlay might help, I don't believe turning on or off accessibility is a good long-term strategy.
No problem!
@kevee, I was following those issues like a hawk and I never knew what was going on, either. But that's another story.
It's actually pretty common for developers to run into this general kind of problem, in which a feature that adds a "Wow!" factor simply cannot be made accessible. In such a case, what you do under the Web Content Accessibility Guidelines is to consider your options:
Unless eigentor's approach can be made to work, it seems clear to me that progressive enhancement is the best option available. Deciding that we just don't want to consider it won't change the facts.
Overlay update
@kevee
Agreed, that turning on-off accessibility is a very bad idea. However, what we are looking at here is turning on and off an inaccessible component. Now, it might just be semantics, but the distinction is significant to me.
As for attempts to make the overlay experience work with / without ARIA, here are my thoughts.
ARIA is inconsistently implemented, meaning that the experience will be inconsistent at best. At worst some people will have no clue what is happening, and that isn't the first impression I want blind web-devs to have of Drupal 7.
Without ARIA then you have two pages rendered in the same document, the origin page and the overlay page. This is better than having strange and unpredictable ARIA stuff (application mode / document mode switching inconsistently) happening, but still is confusing. For starters, focus tracking in some screen-readers is inconsistent. Secondly, and more importantly, it is just plain confusing to have two documents on the same page, especially when the actionable elements on doc1 are disabled in a way that does not communicate to screen-readers that they are disabled.
As an example, try thinking about using te overlay, but instead of being overlayed, it is just appended to the bottom of the origin page. Now realize that you no longer have random access to the document, but that you have serial / linear access to the document (or pair of documents). Now, modern AT provides shortcut keys to jump through a document in a linear way (headings, etc.). But, is that "heading 2: Management" I just heard part of the origin or overlay page?
Just some thoughts, I don't propose to have the answer, other than to disable overlay by default, or to have overlay enabled with an opt-out in the installer; and to provide a per-user option to disable overlay. None of which can rely on overlay.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Everett, No reason though
Everett,
No reason though that we couldn't just ensure using graceful degradation that the former page, that of the origin, is duly noted, or vice-versa that the headings of the origin are duly noted. If it was a simple thing this would be easily done, but if it were a partial implementation of Javascript, then one would have to test for available functionality somehow and apply some changes to the content based on the context, which may be hard to tell. Either way, I don't think it is an unsolvable problem, though I admit I have not worked with it in the ways you have.
Drupal evangelist.
www.CoderintheRye.com
Two paradigms of progressive enhancement
@nowarninglabel
I'm not quite sure that I understand what you are suggesting, but I don't think annotating the entire original document DOM tree is a good solution, either from a performance or an accessibility perspective.
Let me clarify a common problem when talking about progressive enhancement.
The most popular understanding of progressive enhancement is to ensure that base functionality works without client-side scripting or proprietary plugins, and then to enhance the functionality with these technologies. This ensures that the functionality will work for all, regardless of the web technologies supported. This is of course very important.
A less common understanding of progressive enhancement, particularly from the accessibility perspective, is to ensure that functionality works with assistive technology, which may or may not support client-side scripting and proprietary plugins. The problem lies when enhanced technologies are supported in the user agent and by the AT, but that the functionality implemented by these enhanced technologies is not accessible.
Take for example a flash object designed without accessibility used on a site to perform a progressive enhancement of function X. For users without flash installed in their browser function X is still available without flash, for those with flash installed in their browser the standard function X is replaced with the flash version. Although those without flash can use function X and those with flash can use function X, some AT users with flash cannot use function X (whereas without flash installed they would have been able to use function X).
Applying this concept to javascript, and talking only about AT users. If I am logged in as a user with permission to use Overlay and do not have JS enabled in my browser, I as a screen-reader user can still use the functionality of the admin pages of Drupal 7. With JS enabled in my browser I cannot. This is not because JS is inaccessible, it is because the implementation of JS for the particular function creates accessibility barriers.
Taking this further, to the current Overlay discussion, I don't see a way where two documents (one 'inactive' (origin) and one 'active' (overlay)), can coincide in the same page without quite a bit of confusion for some AT users. The overlay is, by definition, a complex UI component, and there is currently no well supported way to provide semantic information (role, properties, state) about the UI component to AT. This will change when ARIA is better supported.
Whether we define the overlay as a dialog, or as some more abstract UI component, it still is a UI component with a role, properties and state. This information is, I hope, implicitly communicated to sighted users through visual presentation, in the same way that an unordered list of links (without semantic markup) is through style alone implicitly understood to be a tabstrip with a selected tab. Providing hidden annotation "(selected tab)" on the selected tab was a relatively simple way to ensure that some semantic information was available to AT users about the role and state of the UI component. Providing hidden annotated information rich enough to convey the semantic role, properties and state of the overlay, in my opinion, is not a possibility. Firstly, the amount of hidden annotation required would be significant. Second, the reason that "(selected tab)" was a workable solution is that it is a commonly accepted and understood method for conveying, in a textual form, the semantic information available through the style, or visual affordance. I really don't think that we will be able to find a commonly accepted and understood method of communicating, in a textual format, the semantics of the overlay. Third, even if we did find a commonly accepted and understood method of providing this information, we still have a barrier in dealing with behaviour. That is, the overlay information and the original document information need to be separated, or jailed, in some way from each other. There is no way to do this type of separation of information without ARIA. Although using headings and skip-links are partial solutions, they still place cognitive burden on the screen-reader user to understand where they are, a burden that is not placed on a sighted user.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Everett, Thanks for the well
Everett,
Thanks for the well thought out response. I have a lot to ponder here and then will get back to you.
Drupal evangelist.
www.CoderintheRye.com
Just Disable the Module
I think the Overlay module is very cool - but I do not care for using it when administering the site. For us it's as simple as performing a D7 install, then visiting the Modules page and disabling Overlay - done & done.
http://edoceo.com/
The overlay isn't only a
The overlay isn't only a problem for special browsers. E.g., I am using Firefox 3.6.25, configured to stop pop-up windows - a very common setting state. The overlay does not display properly. (Uses more than 100% of screen -- without scroll bars, making some tabs and the close "X" unavailable...for one thing. Also, no transparency.)
I can resolve by adding an exception to pop-up rule, in Firefox, but how many users know to do this.
+1 for the making inclusion (screen-readers) a priority
I like the overlay and think it is fine as an option if turned off by default for users.
The superuser 1 could be shown the option early on.