RE: [TIME-SENSITIVE] Issue with Core AAM advancing to Recommendation

Our plan to move name calc forward after core is a clear statement that we do not intende to have normative dependency on name calc in core. In other words, we intend for their normative requirements to be independent. So, I agree with your change to revise core AAM so those statements are not normative. I hate to ask what that means from a process perspective since that is a normative change to core AAM.

Matt

-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Monday, December 4, 2017 2:09 PM
To: ARIA Working Group <public-aria@w3.org>
Subject: [TIME-SENSITIVE] Issue with Core AAM advancing to Recommendation

Hi all.

After reviewing the transition request of the Core AAM 1.1 specification from Proposed Recommendation to Recommendation, the Director pointed out a couple of problematic items:

1. Section 5.6.1 states, "When computing an accessible name or
   accessible description, user agents MUST conform to the section
   titled Text Alternative Computation of the Accessible Name and
   Description Computation and API Mappings specification."

2. The table in section 5.8.1 begins with, "User agents MUST notify
   assistive technology of state changes as defined in the table below."
   The table below has a row for aria-described by and another for
   aria-label + aria-labelledby which says "See the Name and Description
   Change Events section in [ACCNAME-AAM]."

Because the above statements are made in normative content, we currently have a normative dependency from Core AAM 1.1 to AccName. And AccName has not entered CR yet. This is problematic because W3C Process does not allow normative references to uncompleted work like this from a W3C Recommendation. Furthermore, because the accessible name and description calculation was not a separate specification during the 1.0 cycle, we don't even have an earlier AccName Recommendation we can point to. The Director is seeking an explanation from us about these issues and the intent of the Working Group. I'll share with you my personal opinion; then I'd like to hear yours.

With respect to the first item (section 5.6.1), I agree 100% with the spirit of the statement: It is extremely important that names and descriptions be computed correctly and consistently. Therefore, we have a specification which defines exactly how to perform those computations.
And we expect user agents to conform to that specification. But that computation is not what the Core AAM is all about. Furthermore, implementing the mappings defined in the Core AAM can be done independently of implementing the Accessible Name and Description Computation. Thus the "MUST conform" statement in 5.6.1, while consistent with our expectations, does not belong in section 5.6.1 as written because it sets a normative dependency where one is neither needed nor desired.

Possible solution: Because the intent of that statement is merely to reference AccName so that implementors are aware of it and implement it in addition to Core AAM, we should change the first statement to a non-normative, see-also-style reference.

My feelings regarding the second statement (5.8.1) are essentially the
same: The table in section 5.8.1 lists properties where change notifications are likely expected. If we fail to include mention of aria-label, aria-labelledby, and aria-describedby, implementors might not be aware that those notifications are also expected. Therefore, the rows in that table point to the other spec.

Unfortunately, the placement of this reference combined with the wording at the start of section 5.8.1 requires that we know and test platform name-change and platform description-change events as part of Core AAM.
We haven't yet obtained those events because they are contained in AccName, and finishing AccName 1.1 was expected to be done after ARIA
1.1 and Core AAM 1.1 become Recommendations.

Possible solution: Section 5.8.1 already contains a non-normative, see-also-style reference in its second paragraph, namely: "See the Name and Description Change Events section of the Accessible Name and Description Computation document regarding how different accessibility APIs expose changes to accessible name and accessible description properties." I think we could modify that statement to list the properties (aria-label, aria-labelledby, aria-describedby) that we want to ensure are not missed. Then we don't have a need to list those properties in the table below.

As I've suggested before, limiting AccName to a platform-independent, computation-only specification would clear up these sorts of issues. And I think this is desirable going forward (i.e. for the 1.2 cycle). But right now, today, we have normative dependencies that I believe are unintentional. If you all agree, then we can present that to the Director. If you disagree, then we have some things to sort out and more conversations to have. :) Either way, your responses on-list within the next couple days with your perspectives would be greatly appreciated.

Thanks in advance!
--joanie

Received on Wednesday, 6 December 2017 06:29:15 UTC