There are a number of different areas where core, or contributed projects, wish to implement modal dialogs. There are currently a number of concerns with making modal dialogs accessible to all users, and this has held back their implementation in Drupal Core.

I am opening this issue so that we can come up with, and implement, a plan to research, and implement, an accessible and reusable modal dialog for Drupal 8 Core.

1. Generalize the use-case for modals in core
2. Prepare a requirements document
3. Research current solutions (ideally jQuery based)
4. Select candidate solutions and test for compliance with requirements document
5. Prepare a recommendation for a candidate solution(s) to include in Drupal 8 Core

#112 Screen Shot 2013-03-29 at 18.03.27.png91.24 KBWim Leers
#102 jquery-ui-1.10-1175830.102.patch1.4 MBlarowlan
PASSED: [[SimpleTest]]: [MySQL] 53,279 pass(es).
[ View ]
#95 jquery-ui-1.10-1175830.95.patch1.33 MBlarowlan
PASSED: [[SimpleTest]]: [MySQL] 51,446 pass(es).
[ View ]


Thanks for this issue. Starting with #1:

One example is the D7 Views UI, where on the page where you edit a view, you have links for your various options, like filter criteria. Each of these links opens a modal dialog for configuring that option. If JS is disabled, then the links take you to full pages instead, and the OK/Cancel buttons on those pages take you back to the original Edit View page. If JS is enabled, I do not believe the current modal dialogs meet the accessibility criteria we would want for D8 core.

In some cases, I don't think that navigating you to a full other page would work well as a nojs (or have js, but choose to disable modal dialogs for other reasons like incompatibility with my screen reader) fallback. For example, #1101600: Users need to be able to select from list when adding menu items to a menu proposes a dialog launched from a form that also has other input fields. Those other input fields may have updated but not yet saved data. I think in this case, falling back to something inline would be better.

A good question is whether modal dialogs are needed at all. I think they are. For example, consider adding Media into a WYSIWYG textarea. The Media module currently adds a button to the wysiwyg toolbar that launches a modal dialog for selecting the media to add. This does have accessibility problems currently, but what's the alternative? It would be awesome if we can find a solution that allows for accessible modal dialogs.

What is missing from this plan is the current problem statement why its not possible. I mean, that's been the biggest struggle so far, is actually understanding that space.

I do agree with @effulgentsia - that we should explore the idea, of it being needed at all. I agree there are cases where it is a fine solution, but it raises a lot of problems regarding its propper use and whether in principle inline interactions are not to be favored.

Sorry, nothing to add yet; just subscribing.

Subscribing. A (possible) use case is #87994: Quit clobbering people's work when they click the filter tips link, though we may be moving away from the idea of actually using a modal there.


+ other candidate use case in core : Field UI formatter settings, currently expanding inline in the table row. Works when the settings form has like 3-4 elements.
Some contrib modules (display suite, semantic fields...), have cases for more complex options, and there's a push to generalize form_alters on formatter settings forms (field formatter settings).

Back in #796658: UI for field formatter settings, when working on shaping the UI with @Bojhan and @yoroy, I scrupulously avoided to bring the notion of modals to the table, to avoid the fate of #87994: Quit clobbering people's work when they click the filter tips link :-)

Issue tags:+html5

I don't know if there's anything in the html5 spec that can help us here, but adding the tag for now to bring in the people who might know.

What is missing from this plan is the current problem statement why its not possible.

Agreed. I for one would like to understand what makes modal dialogs more challenging from an accessibility standpoint than other kinds of AJAX. For example, taking the #6 example of formatter settings on the "Manage display" page for Field UI. What makes an AJAX callback that returns its content inline into the table row more accessible than an AJAX callback that returns its content into a DIV styled as a modal dialog? Is it an issue of markup proximity, linking the content for screen readers, keyboard navigation issues, ...?

Actually, Everett Zufelt has proposed a html5 modal attribute:

Marked #1179118: Build Accessible Modal Windows or Die as a duplicate of this issue.

Everett, it might be worth linking to, or creating, a document that clearly explains why modals are problematic for accessibility (at this time), because this is going to get asked many times.

@7 - I can tell you that using Media module... its very easy to navigate out of the modal (with keyboard tabbing), thereafter you can never get back in, you are stuck and I found only by hitting escape key can I get out of no-mans land.

So it was only by guessing to hit escape that I got out of it - there is no easy way to recover from this error (the system is not forgiving of human error).

Somewhat related I noticed the "cancel" button never takes focus, so there is actually no way for me to escape the modal if I am using my keyboard, other than guessing to hit escape.

Additionally if I shift/tab and loose focus out the top of the modal it disappears off the page and leaves me with just the transparent overlay background - the modal for some reason is now below the fold, but I can't get its focus back.

I'm not sure if you were looking for a technical summary, however this is one end users UX and I hope that gives you some idea of the problems with modal windows (none of these problems are unique to Media module).

I'm sure casey and Everett can give you much better explanations as to what is going on here, but from my lay interpretation its one of focus - the modal looses focus far to easily and you can't get back in, and thus are trapped with no way to resolve the error.

Good suggestion Jeff. It would be useful to know which D7 contrib modules are currently using this as well.

The post I made at is a good introduction to the problem. It is over a year old and isn't up to date.

Primarily it is missing the concept of nesting a "document" role within the "dialog" role to force supporting AT back into virtual buffer (document reading) mode.

<div role="dialog">
<div role="document">
... all dialog markup goes here ...

I can go into more detail but I think Jeff's feedback in #10 and the article should help people become familiar with the problem.


@Everett, can you test this Yahoo UI dialog example?

I can't get back in virtual buffer mode when the modal dialog (button 2) is open, but then again I am not very experienced with AT.


With NVDA it is NVDA Key (insert) + space. With JAWS it is JAWS Key (caps lock) + z

I was able to do some things with the dialog, but it seemed buggy, in a way that I would only be able to really explain well if I did more thorough testing. Tested w/ JAWS 12 and FF 4

Ah, I can get into the underlying document as well.


@Everett, question: non-AT users can, however grayed out, see the underlying page beneath a modal dialog. Shouldn't AT-users be able too? It only has to be clear to them that the underlying page is inaccessible. Maybe aria-disabled could help out? And a accesskey to refocus into the modal dialog if they move out (using the virtual cursor) to inspect the underlying page.


This would need a lot of usability testing. The visual affordance, IMO, is far stronger than the textual one. That is, it is far easier to understand the separation of content (underlying / dialog) when provided with the visual affordance than when provided with any textual affordance.

That being said, I expect the pressure to put modals in Core will be greater than the pressure to keep Core accessible. So we need to find something that works the best it possibly can, even if it isn't perfect.

What it boils down to is that I am a very bad person to test prototypes, they should be tested by a group of assistive technology users, within a task completion workflow, as this is how they will discover them in Core.

And what about this one:


1. I was able to get out of the dialog and access the underlying page. The content had been altered from before the dialog, perhaps using role = presentation or aria-disabled?

pressing escape close the dialog (that can't happen because of how escape can often be used by screen-reader users) and the dialog didn't have a title. The last two issues are easy fixes.

Yes you can get out of the dialog, but can you actually read the underlying page? I wrapped the page content in a img role (and a tree role to hide the content from JAWS' virtual buffer). So in virtual buffer mode a user sees two elements: a graphic with label "underlying page" and the modal dialog. I thought that to be pretty accessible.

The dialogs do have titles set by aria-labelledby... aren't they pronounced? They are to me. The first dialog has title "Overlay", maybe that confused you?

The page actually contains three types of modal dialogs: document inside dialog (overlay-style), form in dialog and confirmation form.

Documents inside dialogs (like in #12) aren't currently supported in NVDA but it should be fixed in the next version: NVDA Ticket #1452.


When I open any of the three dialogs the following text is available to JAWS outside of the dialog:

Modal dialog test

banner landmark

Administrative links for Node 1 content info landmark

banner landmark

Administrative links for Node 2 content info landmark

Note: that Treeview graphic unavailable is also read a number of times, but does not get copied into the clipboard from the JAWS virtual buffer.

Landmarks seem to be handled a different way:

In the case of the ARIA Landmark roles for example, the JAWS screen reader supports them, although they are not exposed using an accessibility API. It is surmised that JAWS picks them up from the browsers HTML DOM.


The underlying content is now read only as

Close dialog and return to underlying page button

The button does nothing. I haven't tested with a screen-reader that doesn't support ARIA.

Yes button doesn't do anything yet; I am not sure yet if it should read "Close dialog and return to underlying page button" or "The underlying page is currently inaccessible, return to dialog Foobar" or something like that.

The current html5 change proposal to add <dialog> is at

The CP needs a couple of tweaks, but both Steve Faulkner, author of a different CP for dialog, and myself (who opened the original bug against the spec), are on board with this CP. I am hoping that the HTML WG will be able to build consensus around this CP and that it will make it into html5. Nevertheless, it will be some time before we see this implemented by UAs.

In the meantime we could use something like my proposal in #27. I think the semantics are pretty correct: the underlying page is exposed as an image (this is how non AT users experience it too), inside a button that closes the overlay on click.

When a dialog element is included in the html5 spec we can easily include it into #27 for as long as the element isn't natively supported by UAs.


I took another quick look at #27. Is it possible to get a close button inside the iframe? I believe that Voiceover users may be sandboxed in the frame, and possibly not knowing this, won't know how to get out or how to find the close button.

I think that the pattern you have come up with might be the best we can do, although not without problems, and we should do some further usability / accessibility testing with real-world users. But, I would lean toward including something very close to what you have now as a dialog API in D8, possibly with a backport to D7 (if API additions are being permitted).

Sure, that is possible. For starters I'll open a new issue to get overlay using this pattern.

Maybe we should communicate this pattern also to the jquery community so the may include it in their dialog.

@casey: can you also open an issue in whichever D7 contrib project you think is the most appropriate to house this and link to it from here? Perhaps

I think that before we make * any * changes or promote the pattern that we need some real testing. I am * not * the proper user to test such things, as I am far too familiar with the issue. So, although I do believe that we are on the right track, I think that we really need to do testing with users of assistive technology before we move too far forward.

After we get some positive feedback from testing we should look at the API requirements for the html5 <dialog> CP, since the work was already done to come up with requirements. Then we can, hopefully, create a dialog API for Core that meets the needs identified in the CP, and have as accessible / functional of a dialog as current technology will allow.

If we create the dialog API on our own, or by leveraging and providing assistance to the jQuery UI dialog, it really doesn't matter too much to me. However, I would prefer to see us make as many upstream accessibility improvements as is reasonable.


I got a message back from Colin, he pointed me to . I haven't read through or summarized any of this.

That link doesn't really have much in it though. No direct code in anycase that helps us get closer to resolving this problem. There's this and autocomplete that it would be great if we could get improved in jQuery & then just use in Drupal.

Any thoughts on how to approach the user testing? Do we have a pool of AT users who we can draw on to test? Where would we get a signup list that we can call on? Could just create a webform to gather interested people.

Doing testing for accessibility, as you are well aware, is far more difficult than usability testing in general. It's pretty easy to find someone to sit down for 15 mins and test a UI. Not as easy to find people using assistive tech, or with other disabilities.

I have no list, though I am sure I could find a handful of interested people if someone wanted to setup a demo and a test scenario.

I think we should have some signup list of sorts that we can call on from time to time. How we get there and what we do with it is another thing. And yes, It's definitely difficult to do!

Kinda off topic, but a mailing list for accessibility should be fairly easy to setup and could be helpful:

This is soo offtopic guys :) But anyway, loving the idea of attracting a test panel - I am going to work on improving the "getting involved" pages. So if you want to jump start getting people involved with accessibility let me know how to do that.

I think it would be good to have a page that says something like:
"The Drupal community needs testers to help evaluate how we can make the experience better for people with disabilities. We need people with different kinds of disabilities & with access to a range of assistive technology to help evaluate the work that has been done & help point us on what else there is that we can do. If you're interested in being approached from time to time to be engaged by the community please let us know:

Assistive Technology (if any):
Availability (how often can we contact you):

There will be no compensation for participating in this other than knowing that you are influencing best practices for a significant portion of the Internet. If you want a better experience, it may be well worth your time.

EDIT: we should set up a different issue queue for this. Whoever is next hopefully can take it on. This should be about modal dialog rather than how to assess implementations. And also a mailing list might not be a bad idea too. We've got some inputs, but not many.

Er, can't we just use the jQuery UI dialog function?

If there are accessibility issues, we have PLENTY of time to fix them upstream.


Can you provide a link to an accessibility review of that option?

I don't know of any official studies or anything like that offhand, but here's a blogpost about it:

The reason that I suggest it is that we already have all of the Javascript in core.

jQuery UI is the way to go. A bunch of ARIA fixes come with #1085590: Update to jQuery UI 1.9 from the ARIA July Hackathon. If that's not enough, we need to fix it upstream.

I'm not participating in any Druplicated/ARIA-related efforts here. Learned my lesson from #87994: Quit clobbering people's work when they click the filter tips link. Those issues should be fixed in the jQuery UI front.

@Rob Loach

I agree completely that we shouldn't role our own solution. We should assess other upstream solutions and incorporate one if it meets our use case.

Can you please point me to a demo of the jQuery UI modal dialog that you are suggesting, one that comes with the patch in #1085590: Update to jQuery UI 1.9?

Issue tags:+modal

Everett, any new information on this since your investigation of jQuery's dev code?

@Everett, to answer your question in #49, jQuery UI demo is located here:

The contents of the dialog box are as follows:

Title: Basic Dialog
Body: This is the default dialog which is useful for displaying information. The dialog window can be moved, resized and closed with the 'x' icon.

If you'd like, I can put together a custom demo for you...there's a ton of stuff on that page, and I'm not sure how well it's going to work with a screen reader.

@Everett, to answer your question in #49, jQuery UI demo is located here:

The jQuery UI 1.9 demos are probably a better demonstration of it... We should get 1.9 in to help out the jQuery UI team via #1085590: Update to jQuery UI 1.9.

I have opened issues for every accessibility bug I have found in jQuery UI master (1.9). There are definitely issues related to modal dialogs. I'll report back here should they be resolved.

Thanks, Everett. Are they all captured in this view:!closed&reporter=ezufelt ?

I don't know at the moment if that is all of the jQuery UI bugs, but the two dialog bugs are there.

Issue tags:+Media Initiative

This could also help the Media project, so adding a tag.

Given that other issues rely on this one - #1101600: Users need to be able to select from list when adding menu items to a menu

And that I don't think jQuery UI has the solution yet.

I'm wondering what we're going to do to see that we have a solution for D8 given where we are in the release cycle.

My recommendation is for someone who's a good JavaScript developer to start by submitting a jQuery patch to and These bugs are listed as minor for the jQuery project, but if they're blockers for Drupal to have modal dialogs in core, fixing them will be a huge boon for Drupal. If anyone does submit a patch there, please comment here too to keep us in the loop.

Great suggestion @effulgentsia

I added links back to this issue from #675446: Use jQuery UI Autocomplete as you've made a good point about Drupal contributing patches to jQuery.

Unfortunately, the accessibility team doesn't really have spare cycles to even keep up with stuff with Drupal development these days. We need more big shops investing in continuing to improve Drupal's accessibility.

Has anyone considered nyro modal? I've used it before and it's powerful but there aren't very many good tutorials. I think it is worth a shot. Uses jquery as well.

1. Is there confirmation somewhere that it's licensed GPL?
2. Can anyone confirm that it solves the accessibility concerns of #53/#54 and doesn't come with new ones?

We already have jQuery UI in core. Let's fix it upstream and just use it. There's only two issues to look at for the jQuery UI dialog: and I know nothing about how jQuery UI works, so I'll have to defer to somebody else on that, but they don't seem to be particularly difficult things to do.

Issue tags:+jQuery UI, +Github

Quick update on this. These issues probably won't be fixed until the Dialog API redesign which is planned for 1.10. The jQuery UI team will then be looking at dialog accessibility. Of the widgets, this has a pretty high priority after 1.9 is released. The roadmap defines this pretty well.

Is anyone interested in forking jQuery UI and testing the Dialog API for accessibility issues?

It's possible if we get a pull request in soon that it could land in 1.9, but the timelines are very short.

Any idea what the estimated timeframe is around jQuery 1.10? Will it be ready by next August?

Issue tags:+VDC

scott_gonzalez from the jQuery UI project contacted me in #drupal to inquire more about that proposed timeline in #64. And really, that's not correct, because August 2013 is when we're hoping to have Drupal 8.0, which means we'd need to add jQuery UI 1.10 well before then so contributed modules could develop against something stable.

(See top of for a reference Drupal 8 release timeline)

I'm of the opinion that this is the kind of thing we could still be changed up until "code freeze," currently slated for February 2013. However, pushing it that far means that the features developed up until "feature freeze" (Dec 2012) would not be able to make use of it, and we risk us having to go our own way on this, particularly since we are going to need some solution to this problem in order to complete the "Views in Core" initiative (tagging accordingly).

Scott was going to circle with his team and see what the options (if any) are.

So glad that Scott reached out to you on IRC. #63 is all just paraphrased from an email from Scott. He's great.

Anyways, would be great if we could get some of Drupal's JS guru's to look at jQuery UI ASAP. Might save us all a lot of time in the long run.

We've adjusted our roadmap to do our best to get 1.10 (with updated dialog) out in time for your code freeze. We're hoping to start on 1.10 by August 1, and have code in master that should meet your needs before your feature freeze on December 1. We keep master very stable, and you can always see the current status of our builds on TestSwarm.

Since you're currently only using sortable, you should be able to grab master at any point for testing. Since sortable is planned for a rewrite in 2.0, there should be very few changes any time prior to that (likely limited to bug fixes submitted by the community). Also, autocomplete has had accessibility updates done for 1.9, so you might be interested in looking at switching to that instead of your custom implementation when you pull in new code for dialog.

Status:Active» Postponed

The consensus from the Drupal Accessibility Sprint is that we are waiting for jQuery 1.10. (Discussed with @lennwebb, @Everett Zufelt, @mgifford).

Marking postponed for now. Set back to Active when we are ready to proceed.

FYI fixes tabbing out of modals with jQuery UI dialog
Everett Zufelt: I'm willing to work on the jQuery UI bugs to try and unlock this, particularly on the VDC front - are you available to provide guidance on the issues? I've only got VoiceOver (no Jaws) but the functionality seems similar. I want to confirm what constitutes a fix for these two issues.

Status:Postponed» Active

Given #69, unpostponing. Thanks, @larowlan!


Please ping me on Skype and I will do my best to make some time to respond to the question in #69.

Summary of discussions with Everett on skype:

  • The dialog element (role=dialog) needs a child element with role=document which wraps the dialog contents, this will force the screen reader to be sandboxed into the dialog.
  • The dismiss/close buttons on the dialog need to return focus to their triggering element.
  • The first focusable element in the dialog should receive focus when the dialog is opened, it should also contain a describedby/labelledby attribute to give the user context of what just happened.

Thanks for your time Everett

Looking for reviews of this commit before I send a pull-request to jquery-ui team:

Basically it adds
a) a wrapper div inside the dialog with role="document" as per #72
b) a triggerEl parameter to the open method on a dialog, when passed this element regains focus when the dialog is closed.
c) Updates examples to include triggerEl.

Looks very nice! I can haz patch? :)

Patch should be ready next week. Still need to clean up some cruft.

Accessibility fixes for jquery.ui.dialog here.
Please review.

Hi all,

I am a blind drupal user... I have a bit of experience with php, but no experiences at all with javascript and jquery (I don't know anything about them, except what they can do).

I know this is of-topic, but if needed I could test any demo you think should be tested; and I could also manage to create an "accessibility tester's team" (with blind users, don't know for other disabilities)...

However you can email me at or we could discuss these aspects on the accessibility group....

If you need a real blind user tester tell me what to test and I will be more than happy to do it... (I am an experienced mac os X user and windows and Jaws user).

That's awesome, falcon03!

We actually do have an accessibility team already, and we'd love for you to be part of it!

There are also a variety of Drupal 8 issues that would be great to have your input/testing on. See the accessibility and needs accessibility review tags (there might be others I'm not aware of).

Welcome to the core dev team! :D

FYI patch is green here: #1667742: Add abstracted dialog to core (resolves accessibility bug), would love a review!

Hi all,

I wonder what the status of this issue is...

Is there any work in progress?
seems to be stalling for a while now. With the progress of the VDC and Wysiwyg in core initiatives this issue is (I think) critical for drupal' accessibility!

Another problem, in my opinion, is that we could end up having more than one way to use modals, instead of having an unique, consistent and accessible API to be used for all the features that needs to use modals (not to mention that with these modals we could seriously improve overlay' accessibility).

Hi falcon03, We have been asked to review by the jquery.ui team they've continued to work on a11y issues and have ready to go - just needs testers.
I'm back on #1667742: Add abstracted dialog to core (resolves accessibility bug) this week

can someone let me know if this dialog is accessible/accessible enough?

I wouldn't know how to xhaustively test this for accessibitilty but
- tabbing to the "trigger dialog" button works
- "enter" opens the popup, and places focus on the 1st input
- I can loop-tab indefinitely in the elements in the popup and never get out
- "enter" on the close button closes the popup
- "enter" on the submit button submit (probably ?, no visual confirmation implemented) and closes the tab

Only glitches :
- I can not tab *back* when focus is on the popup's resize handle
- "enter" in an input element within the popup doesn't submit the form (maybe that's intended ?)

Also (working points) :
- when focus is on the resize handle or the popup titlebar, keyboard arrows work for resize/move

Since the dialog patch is RTBC and jQuery UI will be made accessible enough for us, should we close this or is there more to talk about still?

Title:Research and implement accessible / reusable modal dialogEnsure jQuery UI 1.10 dialog is accessible and update to it when it's released
Category:feature» task

#1667742: Add abstracted dialog to core (resolves accessibility bug) landed. Retitling this issue accordingly. I don't object to it being closed if the people working most closely on this are doing it in upstream channels and don't need this issue for communication.

We're getting very close to a beta release of jQuery UI 1.10.0. It'd be great if you could do another round of testing to make sure we're meeting your accessibility requirements. As always, you can test the latest code at

This review from Hans Hillen sums up the status pretty well:

Overall the dialog mark up looks good. The VoiceOver issue is a general issue that has always existed. VoiceOver does not announce ARIA groups, and it does not even announce basic fieldsets. If you move focus into a dialog and wait a few seconds, VO will in fact announce "you are on a text field, inside a dialog". If you then move focus up a level using the VO + Shift + UP Arrow shortcut, VO does correctly announce the dialog as well as its name. So technically speaking it is possible to figure out this information, but it's a huge pain and the user is not going to be aware of the dialog's presence initially. It's definitely something Apple has to fix, so we should probably file a bug for it if there isn't one already. Until then, we could consider a temporary hack: browser sniff for Safari (OSX or IOS), if it's detected add a live region that updates when the dialog pops up (the live text could be something like "opening Profile Information dialog"). Far from ideal, but I'm not sure what else to do at this point (besides moving focus to the dialog itself, which I suppose we could also do in Safari only).

Also, let me know if you have any questions or concerns about the code even if it's not related to accessibility.


Issue tags:+modal dialog


Ok, jQuery UI 1.10.0 was released. Now what?

1) Can someone familiar with the accessibility issues confirm that all have been adequately fixed in that release?

2) We need a patch to update Drupal's jQuery UI library to that version (for whoever rolls that patch, please open a new issue for it and link to it from here).

We need to do 2. regardless of 1., so if it's easier to do 1. after 2., that's ok too.

Yes, please roll the patch for the jQuery UI upgrade first. Thanks!

Status:Active» Needs review
Issue tags:+JavaScript
new1.33 MB
PASSED: [[SimpleTest]]: [MySQL] 51,446 pass(es).
[ View ]

Here's a patch with the new ui
Tried to mirror what we currently have (ie no minified versions, only base theme, no docs, no demos).
ooh I'm in Authors.txt - Proudly Found Elsewhere + Cross project collaboration for the win!

Status:Needs review» Needs work

The last submitted patch, jquery-ui-1.10-1175830.95.patch, failed testing.

I'm assuming that for a contrib library like this that tab in indent & whitespace errors don't matter?

It seems apply fine and so far it all is working fine, but aside from the missing stuff that Lee outlines above, how much testing should be done before this gets into Core? It's leveraged by pretty much everything.

Congrats too on getting into the Authors.txt Lee!

Status:Needs work» Needs review

#95: jquery-ui-1.10-1175830.95.patch queued for re-testing.

In my opinion this issue is critical. If we do not update JQuery UI it will be hard to test stuff like
#1842036: Convert all confirm forms already converted to new routing system to use modal dialog
#1851414: Convert Views to use the abstracted dialog modal
with a screen reader, which we should definitely do! :-)

I am not marking this critical, though, since I am not sure if we should handle the update here or in a (critical) follow up.

Title:Ensure jQuery UI 1.10 dialog is accessible and update to it when it's releasedUpdate to jQuery UI 1.10 so that Drupal dialogs can be tested for accessibility
Priority:Normal» Critical
Status:Needs review» Needs work

I agree with critical, since it makes no sense to release D8 without this.

Needs work, because #95 is for 1.10.1, but 1.10.2 is now available.

Tried to mirror what we currently have (ie no minified versions, only base theme, no docs, no demos).

Did you do that via the "Custom Download" button on, or via manual cherry picking of files?

Also, system_library_info() needs to be updated to reference the correct version.

I did it via cherry-picking.
Will bump to 1.10.2

Status:Needs work» Needs review
Issue tags:+Needs manual testing
new1.4 MB
PASSED: [[SimpleTest]]: [MySQL] 53,279 pass(es).
[ View ]

Bumps it to 1.10.2, again by fetching the full zip and only committing stuff we already had, plus the json package details for the effects.
Also bumps version in system_library_info().

Adding needs manual testing tag because there is definitely no automated testing for places ui is used in core.

I'm testing it now in Would be good to know where we think there will be problems. It touches on almost everything, but it would be really good to have some idea on where to focus.

From what I've seen thus far it seems to be working just fine. Needs more eyes though.

This patch seems to break AJAX Dialogs that we just introduced. To test: apply locally, comment out/remove the "hidden: true" line in /core/modules/system/tests/modules/ Enable the AJAX Test module. Then visit ajax-test/dialog. None of the dialogs will open any more because an exception is thrown while loading jQuery UI on-demand. I'm not sure why this problem is occurring yet.

Actually looks like this has the same broken effect on the "admin/config/development/sync", but again I think you have to test it locally because there's no way to make a new staging config on that I'm aware of.

My bad, this was my fault. On a clean install things look good. It looks like my problem was related to an adjustment I had put in place dealing with the horrible jquery.ui.dialog.patch.js file that is currently included in Views. I moved the file around in #1851414: Convert Views to use the abstracted dialog modal and it was causing a problem.

Let's keep this issue focused on just updating jQuery UI. That patch definitely needs to be removed, but it doesn't look like it has any effect in its current form on the Views UI. I'm already moving it around in the Views generic dialog issue, after this patch is committed I'll just remove the "patch" JS file entirely in that issue, since the problem has been fixed in jQuery 1.10+ (see

This patch gets my approval. It fixes several issues I've encountered (i.e. jQuery.ui.version just being "@version" and also properly centering a modal dialog:

Status:Needs review» Reviewed & tested by the community

This helps multiple issues I'm facing with generic dialogs, no new problems are introduced that I can find. Our use of jQuery UI is actually still pretty minimal at this point, but it's nice to see minor upgrades of jQuery UI (a 1.9 to 1.10 jump) not cause a whole basket of problems with existing code. RTBC++

Title:Update to jQuery UI 1.10 so that Drupal dialogs can be tested for accessibilityChange notice: Update to jQuery UI 1.10 so that Drupal dialogs can be tested for accessibility
Status:Reviewed & tested by the community» Active
Issue tags:+Needs change record

Committed and pushed to 8.x. Thanks!

This is probably change notice worthy.

Title:Change notice: Update to jQuery UI 1.10 so that Drupal dialogs can be tested for accessibilityUpdate to jQuery UI 1.10 so that Drupal dialogs can be tested for accessibility
Priority:Critical» Normal

w00t! Thanks.

I'm not familiar with writing change notifications (or "change records" I suppose they're called?), but I took a stab at it:

There aren't any significant API changes in this one, unlike the update to jQuery UI 1.9 changelog:

Should we use this issue to record accessibility improvements/failings? Or time to start a new issue?

quicksketch++ :)

Another related issue: #890288: Improve Overlay accessibility by using modal dialogs

#quicksketch: great job, thanks! :-)

Now testing dialogs with a screen reader will be a piece of cache! :-)

I don't think we need a new issue to discuss dialogs accessibility; I am sure we'll open new issues as soon as we discover them. If there are any accessibility issues they will be discovered for sure reviewing various patches to convert things to modal dialogs. :-)

new91.24 KB

Sadly, this broke Edit module; more specifically, it broke Create.js.

Drupal really needs JS test coverage… :(

Can you report the problem upstream with Create and link to the issue from here? I'd be happy to help them with any upgrade issues.

#113: I should've done that right away, but I had to run. Anyway, issue created: Twitter conversation: with Create.js maintainer.

Now there's a d.o issue for the problem discussed in #112/#113/#114: #1960612: jQuery UI 1.10 update broke Create.js, and thus in-place editing.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Title:Update to jQuery UI 1.10 so that Drupal dialogs can be tested for accessibilityUpdate to jQuery UI 1.10
Issue tags:-Needs manual testing, -Needs change record

Retitling for consistency in the change record. The actual accessibility testing is covered in followups.

Title:Update to jQuery UI 1.10Update to jQuery UI 1.10.2

Let's include the bugfix version.