Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)

As described in #1585 (comment) as well as in ARIA WG meetings 1 and 2, what implementors have done for ARIA reflection does not appear to match what is in the spec.

In particular, default/implicit values for missing attributes are not being reflected, and no validation is taking place. When an attribute is not present in the DOM, the reflected value is null. Thus as it currently stands, I believe we have 0 implementations for the IDL interface as spec'ed in ARIA 1.2.

What is currently implemented seems consistent with the properties being a nullable DOMString. Therefore, unless there is a strong belief that what is in the spec now (attributes are a non-nullable DOMString) is correct and that the implementations are wrong, the thing to do might be to update ARIA 1.2 to reflect (pun intended) reality.

@cyns

@cyns is drafting some changes externally.

Does the group need a test page need to be developed for IDL testing?

Here's the PR #1611

@annevk

Therefore, unless there is a strong belief that what is in the spec now (attributes are a non-nullable DOMString) is correct and that the implementations are wrong, the thing to do might be to update ARIA 1.2 to reflect (pun intended) reality.

Probably worth to ping @annevk who raised #1058.

@saschanaz

Was an effort made to get implementations to change here? Are there tests? This change was made only a year ago too.

Furthermore, it's not clear to me that the current text works as reflecting only supports nullable strings if the attribute is an enumerated attribute and meets the requirements thereof. See also the discussion in the issue @saschanaz referenced.

Google WG members looked into changing the implementations, but it's a non-trivial amount of work with no clear user benefit.

As such, we don't believe the engines need to change, so we'd like to take the WHATWG-recommended approach that you and others helped develop: update the spec to match what is already working in the implementations.

But what exactly is that? The PR doesn't appear to do that as far as I can tell. It relies on reflect, but reflect doesn't handle this type for numerous ARIA attributes.

@cyns

Update: linked #1611 in the sidebar, which is the correct PR.

…but the only substantive IDL change in this PR is to add the nullable ? to the existing DOMString entries like ariaLabel which matches current browser behavior.

The diff won't change any of the other still-commented FrozenArray<Element> attributes that it seems like you're concerned about, like ariaLabelledByElements. The diff also adds some examples. HTH. (@cyns please verify I recall correctly)

It doesn't really, ariaLabel isn't an enumerated attribute as far as I know, so DOMString? doesn't work if you say "reflect".

@domenic

cc @domenic

@annevk

@annevk wrote:

as far as I know, so DOMString? doesn't work if you say "reflect".

When we first proposed adding IDL to ARIA, the standard version of IDL didn't include reflect at all. Since it's been a moving target, we appreciate your help in this area.

For the following HTML element:

<div aria-label="foo"><!-- No role. This is just an example element for the output below. --></div>

This is the console output in WebKit, and IIRC, it matches other engines.

> $0.ariaLabel
< "foo"
> $0.getAttribute("aria-label")
< "foo"
> $0.setAttribute("aria-label", "")
< undefined
> $0.getAttribute("aria-label")
< ""
> $0.ariaLabel
< ""
> $0.removeAttribute("aria-label")
< undefined
> $0.ariaLabel
< null

IIRC @joanmarie and @cyns were attempting to match the existing implementations, which treat these attributes like nullable, reflected DOMStrings, as demonstrated above. If there is a better syntax to express this in the current version of IDL, please advise. Thanks.

I have a conflict for the first hour and it's rather late after that, but I can probably make that work. Agreed though that what's really needed here is for someone to write a proposal.

TPAC ARIA Meeting has started.

@annevk

@annevk @domenic is this the type of text you are looking for?
“If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is in its missing value default state then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value in a transparent, case-preserving manner.”

@annevk

And @annevk FWIW we believe your relationship comment is already addressed.

@annevk

That's along the right lines. An issue is that "missing value default state" only applies to enumerated attributes, and nullable DOMString reflection is already defined for enumerated attributes in https://html.spec.whatwg.org/#reflecting-content-attributes-in-idl-attributes

As @annevk pointed out in #1598 (comment) , the attributes we're dealing with here are not enumerated attributes. So that condition doesn't hold, and thus the spec text you propose doesn't really work as written.

When do you want null to be returned?

@domenic

@domenic wrote:

the attributes we're dealing with here are not enumerated attributes

I previously proposed "Return the value of the attribute if present and null otherwise" but I don't believe it's been answered why that simpler phrasing wouldn't work for these non-enumerated reflected strings.

@annevk implied there's no relationship established between the name of the getter and the name of the attribute, but I believe that's already addressed by ARIA Section §10.2

If one or both of you could join the call (going on now) it may be easier to work out the disconnect.

@annevk

"Return the value of the attribute if present and null otherwise" would work. @annevk's response was that you failed to define the setter behavior, but if you combine that with the rest of #1598 (comment) it would be fine.

Again, I don't think a call is necessary here. Proposing spec text and reviewing it, as we're doing asynchronously, works best for me. It would be even better if it was done in pull request form so we could use the normal code review tools.

revising the proposed language:
"If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is not present then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value in a transparent, case-preserving manner."

LGTM with a slight modification: "If a reflecting IDL attribute is a nullable DOMString attribute" should be "If a reflecting IDL attribute is a nullable DOMString attribute whose content attribute is not an enumerated attribute", so as to not conflict with the existing definition in https://html.spec.whatwg.org/#reflecting-content-attributes-in-idl-attributes

if you combine that with the rest of [jnurthen's draft] it would be fine.

Thanks for clarifying. I think this was the bit we were blocked on.

updates per discussion in #1598

updates to IDL section per discussion in #1598 (#1633)

Navigation Menu

Repository navigation

Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?) #1598

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?) #1598

Description

Activity

cookiecrook commented on Sep 2, 2021

jongund commented on Sep 7, 2021

cyns commented on Sep 9, 2021

saschanaz commented on Sep 17, 2021

annevk commented on Sep 20, 2021

cookiecrook commented on Sep 23, 2021

annevk commented on Sep 27, 2021

cookiecrook commented on Sep 27, 2021

annevk commented on Sep 28, 2021

annevk commented on Sep 28, 2021

cookiecrook commented on Sep 28, 2021

20 remaining items

annevk commented on Oct 22, 2021

cookiecrook commented on Oct 28, 2021

jnurthen commented on Oct 28, 2021

cookiecrook commented on Oct 28, 2021

domenic commented on Oct 28, 2021

cookiecrook commented on Oct 28, 2021

domenic commented on Oct 28, 2021

jnurthen commented on Oct 28, 2021

domenic commented on Oct 28, 2021

cookiecrook commented on Oct 28, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions