Closed Bug 1330659 Opened 5 years ago Closed 2 years ago

Make HTML5 <dialog> accessible

Categories

(Core :: Disability Access APIs, defect, P5)

defect

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox53 --- wontfix
firefox79 --- fixed

People

(Reporter: MarcoZ, Assigned: MarcoZ)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

Support for the HTML5 <dialog> element is currently being worked on in dependent bugs to bug 840640. We need to make sure it is exposed to accessibility APIs before the element gets pref'ed on for users and web developers by default.

Accessibility API mapping: https://www.w3.org/TR/html-aam-1.0/

We basically need to mimic what we do for WAI-ARIA.
(In reply to Marco Zehe (:MarcoZ) from comment #0)

> Accessibility API mapping: https://www.w3.org/TR/html-aam-1.0/
> 
> We basically need to mimic what we do for WAI-ARIA.

so role='dialog' only? any tricks for inert content? what other browsers do?
Adding accessibility is very simple. Leaving it here for safekeeping, will write a test later when support solidifies and then make sure stuff gets reviewed and checked in in time.
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
(In reply to alexander :surkov from comment #1)

> so role='dialog' only? any tricks for inert content?

I'm not sure if we'll implement inert, or blocking element, or something else. It is worth following: Bug 1200896
(In reply to David Bolter [:davidb] from comment #3)
> (In reply to alexander :surkov from comment #1)
> 
> > so role='dialog' only? any tricks for inert content?
> 
> I'm not sure if we'll implement inert, or blocking element, or something
> else. It is worth following: Bug 1200896

that was a whole point as I understand it :)
A key aspect to ensuring the usability/accessibility of the Firefox dialog implementation is to move focus to the dialog container when a dialog is displayed. This is not what is currently specced, but there is a related issue https://github.com/whatwg/html/issues/1929 I would suggest that firefox should implement whats best for users rather than whats in the spec, in this regards.

Another consideration is moving focus back to the triggering element when a dialog is dismissed.
Flags: needinfo?(mzehe)
Priority: -- → P3
It seems it's not yet implemented, see bug 840640 (no dependencies fixed). Let's move out if from the backlog (one day we should traverse it), we will bump up its priority when it's ready.
Priority: P3 → P5
Agree with Alex, this is not yet relevant.
Flags: needinfo?(mzehe)

hey Team!

I'd like get dialog element enabled in Nightly, can I ask a revisit to this bug?

Not sure if there are things blocking us. The autofocusing steps are implemented in Firefox now, so things inside dialog elements will be focused automatically when dialog elements show up. However, the spec doesn't define moving focus back to the triggering element when a dialog is dismissed.

Flags: needinfo?(mzehe)

Sean, if it is now implemented, I can take the patch I attached to this bug and enhance it with a test. Are there instructions on how to enable it and an example I can look at, with full implementation of what this element can do?

Regarding moving focus back to the triggering element, this is a requirement in the WAI-ARIA version of the dialog role, and should also be what we should do for the native host language version. Even if it is not in the spec, this is what's best for users, better than keeping them lingering at the top of the document, possibly having to require them to tab a cillion times back to the element that opened the dialog.

Flags: needinfo?(mzehe) → needinfo?(sefeng)

Got it. It's now implemented, behind dom.dialog_element.enabled pref. The MDN page is still accurate. https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement.

Regarding moving focus back to the triggering element, this is a requirement in the WAI-ARIA version of the dialog role, and should also be what we should do for the native host language version. Even if it is not in the spec, this is what's best for users, better than keeping them lingering at the top of the document, possibly having to require them to tab a cillion times back to the element that opened the dialog.

I see! There are existing spec issue for it https://github.com/w3c/aria/issues/1284, and I think we can/should start pushing it forward as we are the second implementer. And I don't think this is blocking us from enabling it in Nightly?

Flags: needinfo?(sefeng)

This patch exposes the dialog element as a HyperTextAccessible with role DIALOG and enables the test after flipping the pref temporarily. Once the pref is on by default, the if block should be removed and the test run always.

Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/279475d81cbb
Expose the HTML dialog element to accessibility APIs, r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

For anyone watching this, note that this fix (and this bug) only covers the a11y API exposure. There are still issues to be fixed (both in Firefox and the spec) with respect to dialog keyboard a11y which are covered elsewhere:

  • Bug 1322939 and/or bug 1200896 cover dialog being properly modal. I assume this covers not being able to tab out of the dialog, but we might need a separate bug for that.
  • Any Firefox bugs for dialog should block bug 840640.
  • The currently specified behaviour (and what both Firefox and Chrome implement) is to focus the first element. However, there's stalled spec discussion about changing that to focus the dialog container when there's no autofocus, which I agree generally makes more sense. See https://github.com/whatwg/html/issues/1929.
  • I think we want to move focus back to the triggering element when the dialog is dismissed, but I don't think a spec issue has been raised for that yet, at least not one I can find at https://github.com/whatwg/html/labels/topic%3A%20dialog
You need to log in before you can comment on or make changes to this bug.