1628418 - implement ARIA reflection

Status: RESOLVED FIXED

(Core :: Disability Access APIs, task, P3)

Description

[alexander :surkov (:asurkov)]

Spec lives here https://w3c.github.io/aria/#idl-interface
Mozilla position here https://github.com/mozilla/standards-positions/issues/211

So no IDRefs attributes and nullable ARIA attributes (https://github.com/w3c/aria/issues/1058) at this point. Do I understand correctly these issue are not considered a stopper for prototyping?

Comment 1

[Anne (:annevk)]

Implementing this behind a preference is totally fine. Even enabling on Nightly. It would be good to email an Intent to prototype as per https://wiki.mozilla.org/ExposureGuidelines though. For shipping we should sort out the remaining issues (including reflecting all as strings or using more appropriate types).

Comment 2

[alexander :surkov (:asurkov)]

(In reply to Anne (:annevk) from comment #1)

Implementing this behind a preference is totally fine. Even enabling on Nightly. It would be good to email an Intent to prototype as per https://wiki.mozilla.org/ExposureGuidelines though.

Filed https://groups.google.com/forum/#!topic/mozilla.dev.platform/FWdTtWSFzE0

For shipping we should sort out the remaining issues (including reflecting all as strings or using more appropriate types).

sure, totally makes sense

Comment 3

[alexander :surkov (:asurkov)]

Implementation notes:

• add AccessibilityRole and AriaAttributes interfaces from https://w3c.github.io/aria/#idl-interface to https://searchfox.org/mozilla-central/source/dom/webidl
• implement methods on nsINode, similar to https://searchfox.org/mozilla-central/source/dom/base/nsINode.cpp#1917
• enable wpt test https://searchfox.org/mozilla-central/source/testing/web-platform/meta/dom/nodes/aria-attribute-reflection.tentative.html.ini#1

Olli, does it sound about right?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Sounds right. And worth to check what has been implemented in other browsers.

Comment 5

[Anne (:annevk)]

The Intent to prototype mentioned Element, but I don't think we should expose this beyond HTML, SVG, and Math (and potentially XUL) elements. I.e., it should match the HTMLOrForeignElement mixin or be more tightly scoped.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Anne (:annevk) from comment #5)

The Intent to prototype mentioned Element, but I don't think we should expose this beyond HTML, SVG, and Math (and potentially XUL) elements.

Why? If I get it right, then ARIA is not scoped to any particular markup, and if so, it seems reasonable to keep ARIA Reflection of the same scope.

Out of curiosity, HTML/SVG/Math (+XUL) define practically everything. If it gets scoped, then what left out of the scope?

I.e., it should match the HTMLOrForeignElement mixin or be more tightly scoped.

which mixin would be define the best scope then?

on implementation level, does it mean this AriaAttributes.webidl change (https://w3c.github.io/aria/#AriaAttributes)?

-Element includes AriaAttributes;
+HTMLOrForeignElement includes AriaAttributes;

Comment 7

[alexander :surkov (:asurkov)]

(In reply to alexander :surkov (:asurkov) from comment #6)

on implementation level, does it mean this AriaAttributes.webidl change (https://w3c.github.io/aria/#AriaAttributes)?

-Element includes AriaAttributes;
+HTMLOrForeignElement includes AriaAttributes;

I suppose

HTMLElement includes AriaAttributes;
MathMLElement includes AriaAttributes;
SVGElement includes AriaAttributes;

Comment 8

[Anne (:annevk)]

I didn't realize ARIA included Element includes AriaAttributes. I guess this is more of a design question then, but thus far only id, class, and slot have been made "superglobal" attributes by the DOM Standard and everything else is more restricted to not step on the toes of those designing custom vocabularies too much.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Anne (:annevk) from comment #8)

I didn't realize ARIA included Element includes AriaAttributes. I guess this is more of a design question then, but thus far only id, class, and slot have been made "superglobal" attributes by the DOM Standard and everything else is more restricted to not step on the toes of those designing custom vocabularies too much.

So shall I stick to the original plan then? and should I file a github issue against the spec to rise the concern?

Comment 10

[alexander :surkov (:asurkov)]

Implementation question: nsGenericHTMLElement has handy methods like SetHTMLBoolAttr [1] to implement attribute reflection, and which are implemented as wrappers around Element::SetAttr. Curious, if SetHTMLBoolAttr and such should be moved to Element, and AriaAttribute implementation as well?

[1] https://searchfox.org/mozilla-central/source/dom/html/nsGenericHTMLElement.h#748

Comment 11

[Anne (:annevk)]

If you could file an issue that'd be great. Does Firefox currently support setting ARIA attributes on arbitrary elements? (E.g., an element created with document.createElementNS("some random string", "some-name");)

Comment 12

[alexander :surkov (:asurkov)]

(In reply to Anne (:annevk) from comment #11)

If you could file an issue that'd be great.

yep, filed one https://github.com/w3c/aria/issues/1239

Does Firefox currently support setting ARIA attributes on arbitrary elements? (E.g., an element created with document.createElementNS("some random string", "some-name");)

yep, setting role='button' on such elements makes it a button for accessibility, Chrome makes same thing.

Comment 13

[alexander :surkov (:asurkov)]

Olli, could you take a look at comment #10 please?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Moving helper methods from nsGenericHTMLElement to Element, if needed, sounds ok to me.
And AriaAttribute stuff of course depends on the spec.

Comment 15

[alexander :surkov (:asurkov)]

Attachment: Bug 1628418 - ARIA reflection: implement AccessibilityRole interface

Comment 16

[alexander :surkov (:asurkov)]

Attachment: Bug 1628418 - ARIA reflection: implement AriaAttributes interface

Depends on D71169

Comment 17

[alexander :surkov (:asurkov)]

Attachment: Bug 1628418 - ARIA reflection: update WPT tests

Depends on D71771

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7da3a631f4cf
ARIA reflection: implement AccessibilityRole interface r=smaug
https://hg.mozilla.org/integration/autoland/rev/a0d04f7917bd
ARIA reflection: implement AriaAttributes interface r=smaug
https://hg.mozilla.org/integration/autoland/rev/067ed9e7c7b3
ARIA reflection: update WPT tests r=smaug

Comment 19

[alexander :surkov (:asurkov)]

Attachment: Bug 1628418 - ARIA reflection: update wpt test expectation

Depends on D71772

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/56590914ab61
ARIA reflection: update wpt test expectation r=MarcoZ

Comment 21

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/7da3a631f4cf
https://hg.mozilla.org/mozilla-central/rev/a0d04f7917bd
https://hg.mozilla.org/mozilla-central/rev/067ed9e7c7b3
https://hg.mozilla.org/mozilla-central/rev/56590914ab61

Comment 22

[Leo Balter]

Hi! This feature seems to remain under a flag while it's already available by default in Chrome and Safari. Do you have any estimate for moving this to be on by default? Thanks!

Comment 23

[Anne (:annevk)]

Jamie, do you know if we have a bug that tracks shipping this?

I'm a bit concerned that some of the specification issues still haven't been resolved, e.g.:

• https://github.com/w3c/aria/issues/1110
• https://github.com/w3c/aria/issues/1239

Not sure why the other browsers decided to ship when the design still has flaws like those.

Comment 24

[James Teh [:Jamie]]

We don't have a bug to track shipping (yet), but the reason it hasn't been shipped is precisely because of those open spec issues. We're in a bit of a bind now, though, because multiple browsers have shipped it without those issues being resolved. That means resolving those spec issues is likely to cause web compat issues. We know this is already being used in the wild; see bug 1785412.