[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 Monday, 4 December 2017 22:09:14 UTC