Not sure if that would help, or how easy that patch would be to write :) #668640: Overlay shouldn't be based on jQuery UI DialogĪlready being discussed for other reasons. Or, to brainstorm other more suitable alternatives.Īlso, to the extent that this is an issue with jQuery UI dialogs specifically, note that there is an open issue at I would prefer a profile option without overlay at installation. Unfortunately there is no way to use JS to detect if a user is using a screen-reader, so we would have to include this markup to everyone who visits a page with Overlay enabled. * The message / option for disabling Overlay for users of screen-readers is an excellent idea, and I think that your suggestion is great. 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 Or, To have overlay disabled in the default profile.Ĭould the proposed ribbon just be displayed inside a div that has the "element-invisible" class added to it? (Assuming the accessibility issues discussed Provide an installation profile that is the same as the default, but without the overlay. Provide documentation for screen-reader users about the experience they can anticipate with the overlay.Ģ.
It is not critical, as screen-reader users can with some effort learn how to use the overlay, even if it degrades user experience for some or many. As far as I know overlay is the only jQuery UI modal dialog currently in core.
Depending on the necessity and importance of the information communicated in the dialog there needs to be a relatively easy way for the dialog to be disabled. Using application mode on any UI that contains text (other than labels and descriptions directly related to a focusable UI component is a bad practice, as users have less commands available to allow them to navigate within the 'application'.įinal thought is that it is not possible at this time for a screen-reader user to have a consistent experience with a modal dialog.
Application mode increases the chance that users will stay in the dialog, but can significantly decrease the commands that users have available to navigate within the dialog.ģ. This is because these two screen-readers handle ARIA role="application" differently. Some screen-readers, like NVDA, will enter into application mode and others, like JAWS, will not with the jQuery UI modal dialog. In my opinion neither of these techniques is reasonably sufficient to increase user experience (i.e. These include the tab key handler that is native to jQuery UI dialog and using the ARIA role="application".
It is not possible to make a dialog modal for NVDA, JAWS or VoiceOver, although inconsistent techniques can be used to increase the likelyhood that users will not leave the dialog. After discussions on the jQuery accessibility mailing list at.