Concerns of moving HTML-AAM solely to Web Platform

There is a proposal for the Web Platform WG to take over sole 
development of the HTML-AAM, tracked at:

https://github.com/w3c/charter-html/issues/133

One thing this accomplishes is it is an example of encouraging 
technology WGs to take ownership of the accessibility requirements for 
their spec. But the more I think of it, the more it concerns me. Many of 
my concerns are not specific to the HTML-AAM or the Web Platform WG, but 
relate to what this decision could mean for our other AAMs. Some factors 
that WG participants may not encounter often, but should be considered, are:

  * We have to consider the impact of precedent - if the ARIA WG stops
    work on one technology-specific AAM, it is less clear whether it
    should continue work on the others, or whether there should be a
    messy "we develop some but not others" case-by-case approach.
  * There is value in keeping the AAMs as a suite consistent with each
    other, which is much easier when the ARIA group has oversight over
    them all.
  * Because the AAMs are an important part of the web accessibility
    strategy of which ARIA is a part, the ARIA WG has a keen interest in
    ensuring that these documents are produced, but it cannot do that if
    the documents are not part of its chartered scope.
  * We recognize that technology-specific AAMs have important
    implications for the technologies, which is why it is important for
    them not to be developed solely by the ARIA WG, but in collaboration
    with the technology WG. But the same principle applies in reverse.
  * In the case of HTML, we are aware of expertise and interest at the
    moment to develop this document within the Web Platform WG. But
    there is no guarantee that energy will persist, and without the AAM
    in the ARIA WG scope we would be unable to ensure it comes to
    completion if the effort stalls. This concern is greater for other
    WGs, which is one reason I am very worried about precedent.
  * Editorially we have tools and procedures in the ARIA WG to link the
    AAMs to core specs and support editorial consistency; that will be
    harder to support if the work is done outside of the ARIA editorial
    space.
  * The HTML AAM, and the other AAMs, are currently part of the ARIA WG
    charter, which has been reviewed and approved by the Advisory
    Committee. Removing it from the ARIA WG could create charter
    problems for the ARIA WG.

My understanding of the desire from Web Platform to end the joint 
deliverable status is because of the W3C Process overhead and 
administrative burden of managing joint work. But I do not see these as 
significant concerns:

  * We have already been developing this document jointly, without the
    need for a joint task force or anything - the editors have simply
    collaborated as needed on it, and brought questions to the wider WGs
    as needed.
  * The document has already gone through the First Public Working Draft
    process, so the remaining Process requirements involve the Director
    and are not higher with two WGs are developing the document.
  * Under the staff reorganization plan, there won't be separate Domain
    Leads to approve FPWD Transition Requests, I believe Philippe will
    be responsible for all of that, so there is no Process cost any
    longer to having two groups work on it as far as I am aware.
  * There is some need for chairs, editors, and staff contacts to work
    together, but that would be needed anyways if there is going to be
    meaningful cross-group review. I have tried to absorb as much of
    that burden as I could, to reduce it from other groups.
  * The Web Platform WG has said it would give the ARIA WG sufficient
    review time at transitions. But if that time is truly sufficient, I
    do not think it will be any shorter than the time frames needed for
    joint publication mechanics, so I don't see a time benefit in the
    proposal.

It's also been brought up that the ARIA in HTML is already not a joint 
deliverable. I think that is a different situation, it's a more 
straightforward case of one language describing how another language 
relates to it. In the case of accessibility API mappings, there are more 
complex interactions between the features of the two languages, so a 
closer relationship in development of the specs is needed.

All in all, I see many risks to removing the HTML-AAM from the ARIA WG 
scope, and do not perceive the proposed benefits. Therefore I am very 
reluctant for the ARIA WG to support this change.

Michael