Thank you Leonie for the additional clarification.
----- Original message -----
From: Léonie Watson <email@example.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, firstname.lastname@example.org
Cc: email@example.com, You agreed to what?!?! <firstname.lastname@example.org>
Subject: Re: On HTML AAM deliverable
Date: Thu, Sep 1, 2016 10:00 AM
Thanks for your help with this discussion Rich, I appreciate it.
Without wishing to be awkward about it, we need to be clear that a joint
deliverable really isn't an option for WebPlat. If we have any joint
deliverables in our charter, it will result in an FO being raised.
We believe that doing the work in one place makes the most sense, and
that wide review is sufficient to gather feedback from the relevant WGs.
We are happy to be the WG that handles the work, or the WG that provides
the feedback through wide review.
My personal preference is for WebPlat to be the parent WG. It would send
out a positive message across the W3C, and would disabuse people of the
notion that accessibility has to happen within accessibility space -
which as we know is not a sustainable path.
@LeonieWatson tink.uk Carpe diem
On 01/09/2016 14:05, Richard Schwerdtfeger wrote:
> We will decide on today's ARIA call and put it out for CFC. The people
> that actually work on the specification appear to prefer that the
> deliverable remain joint but will work with whatever the group decides.
> The core issues as I see it:
> - The current process of joint deliverable is perceived to take too long
> by some.
> - Accessibility resources with the skills to do this work are very limited.
> More on the second bullet:
> Not every accessibility professional understands accessibility at this
> level in applications. There is value in joint ownership as people come
> and go in the working groups. SVG has very few skills in this areas and
> it is unlikely to operate without the help of the ARIA WG. HTML is less
> dependent today as they have the critical skills needed. Furthermore,
> both the SVG and HTML AAMs both reference ARIA core.
> We will try to reach an acceptable resolution for the ARIA working group
> today and put it up for CFC. I would very much like to reduce the
> serialized approval process which I think is the crux of the issue as
> none of the people working on these AAM specifications are hindered by
> the other. We work collectively as needed and we don't enforce tools to
> be used on either group. After we go beyond ARIA 1.1 we will also be
> using github for all the issue and defect tracking.
> Rich Schwerdtfeger
> ----- Original message -----
> From: Philippe Le Hegaret <email@example.com>
> To: firstname.lastname@example.org
> Subject: On HTML AAM deliverable
> Date: Thu, Sep 1, 2016 7:37 AM
> jb: Is there an update?
> rs: Will discuss again on Thursday's ARIA call
> ... Most people seem to be OK with giving Web Platforms exclusive
> ... Except that we do need adequate review time
> ... So, we're trying to figure that out. How much time ahead of CR
> publication, for instance
> ... Generally, people work on the doc and don't worry about ownership
> ... Any group could lose people and then the doc loses staff
> mc: Not sure the editors care either way, either that we leave it as is,
> or that we move it over
> ... Don't believe the joint status has imposed any burden
> ... Actually the proposed review time is greater than what we
> currently have
> ... I'm confident in current staffing on this doc, just worried about
> the future
> ... If there's no problem today, why remove our buffer?
> jb: Noting current status is joint, and PLH recommending keep it that
> way for now
> rs: Can PLH send an email to that effect?
> I left it as a joint deliverable in the proposed Web Platform Working
> Group in order to get the charter out to AC review sooner rather than
> later. I didn't want to hold the entire charter review on this issue.
> The deliverable should be associated with the group(s) actually working
> on the document. This means that the chair(s) and team contact(s) for
> those groups are accountable for the progress of the deliverable.
> Having a deliverable listed in a charter for the only purpose of
> ensuring proper review is not the approach I'd like to push forward in
> the future. We ought to do better than that when it comes down to wide
> reviews. Listing a deliverable in a charter carries patent commitments
> and call for exclusions, publication requirements, ties it to 2 group
> decision policies, etc. We must not do reviews at the last minute (cf
> recent i18n alarms) and any group is welcome to push back on a
> transition if they don't believe they received enough reasonable time to