Dialog not programmatically identified as modal (Settings dialog)
Categories
(Firefox :: New Tab Page, enhancement)
Tracking
()
People
(Reporter: john.northup, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(2 files)
Steps to Reproduce
Open DevTools. Activate the Customize button. Inspect the Settings dialog container.
Expected Behavior
Dialog container has aria-modal="true".
Actual Behavior
Dialog container lacks the aria-modal attribute.
User Impact
Semantic information diluted.
WCAG 2.2 References
Best practice only. While aria-modal="true" adds semantic information, its absence does not constitute a WCAG failure provided the dialog itself is properly implemented and announced.
Recommendations
Apply aria-modal="true" to the dialog container. This is the clearest, least fragile way to convey "this is modal" to screen readers.
Testing Environment
Any
Assistive Technology Used
Any
Code Pointers
<div class="customize-menu " role="dialog" data-l10n-id="newtab-settings-dialog-label" aria-label="Settings">
Further Reference
| Reporter | ||
Comment 1•8 months ago
|
||
Updated•8 months ago
|
Comment 2•7 months ago
|
||
The Settings dialog element has role="dialog" and aria-label="Settings", but lacks aria-modal="true" as described by reporter. Marking as NEW.
Comment 3•7 months ago
|
||
This section functions as a non-modal dialog, which, even given that the bug 2009172 applies (both modal and non-modal dialogs are expected to contain the keyboard focus), is supported by the interface that is allowing a mouse/touch user to continue interact with the page under the Settings dialog: user could scroll the page, hover and activate the controls that are appearing to be under the dialog. The main page content is not dimmed and is not inert.
If the UX team would decide to make the main HNT page content to be inert, this bug should be addressed.
Updated•7 months ago
|
Description
•