Location: Any page that has a Support tab along the left edge of the page e.g. https://courses.edx.org/dashboard (click on Support tab on the side of the page)
Description: [12/19/2016] - Not Fixed
While users are alerted that they have entered into a dialog, there is no programmatic indication where the beginning and end of the dialog are, at present.
Without this indication, screen reader users may be unable to determine what exactly is contained within and not within the simulated modal dialog.
Auditor Note: Developers must provide a programmatic indication of the beginning and end of the modal dialog. This can most easily be obtained by adding off-screen text to indicate the beginning and end. Additionally, developers can use aria-hidden to hide the other contents of the page. Aria-modal="true" should be added to ensure there is programmatic indication that this dialog is modal.
Internal Note: Pro tip, on the div that is the immediate child of the div with role=dialog, add a role="group" with an aria-labelledby that references the id of the Heading that serves as the dialog box title. If the dialog box doesn't have a title, you can use aria-label="modal dialog". Screen readers announce the beginning and the end of modals, so this would serve as just the notification the user needs.
Is this just the LMS Modals?
Which Modals does this cover overall?
I am going to create a Discovery ticket to look into answering these questions.
Can you help answer the open questions above ?
this issue pertains to the dialog box that is opened when the user initiates a support request using the Support tab that appears on the sidebar in LMS. Let me know if you have any questions.
Is this actually a dup of ? It looks like a fix for making this dialog more screen-reader-friendly landed in February. Specifically, adding role="dialog" and aria-modal="true" with an aria-labelledby= tag. The date in the description above is from last December and looks like the same description in ECOM-6921.
In testing, screen readers seemed to recognize they were in a dialog, though I'm not sure whether they were acting ideally or if there were still gaps in what they should be doing.
There is the role="group" bit in the "internal note" above – is that still a useful change as well?
this is not a dupe. Unfortunately, it's a fix required to address a particular behavior observed when using a particular screen reader (Voiceover) in a particular OS (OSX) in a particular way (reading mode). I wish I could say it is an edge case, but its not. VO/OSX/reading mode is used by a large number of users.
When in reading mode, the browser focus is not synchronized with the screen reader focus, so the VO user can actually exit the bounds of the dialog box without knowing it.
As is defined in the ARIA Best Practices document for modal dialog boxes and is observed in all native OS UIs, a user should expect their focus to be trapped within a dialog box. The web is a much more flexible authoring environment. There is no native property that restricts the bounds of focus, leaving the developer to implement it. This means we must jump through many hoops to emulate this behavior (as you can see in the best practices document, which recommends marking all non dialog elements as inert). aria-modal=true, defined in WAI-ARIA 1.1 (very, very new in the grand scheme of things) is designed to provide a more native property. However, we are years and years away from having support for this property in all the browsers and screen readers.
We are doing most everything we can to trap the focus within the dialog, with the exception of the edge case mentioned above. All we are being asked to do here is to indicate where the beginning and the end of the dialog box is, in a manner that is accessible to screen reader users, so that they are informed of when they are exiting the bounds of the dialog box. The most elegant way to do this is to add a new div with a role=group and an aria-label(ledby) on it. This works because VO/OSX/reading mode will announce when a user enters and leaves a group.