See also: IRC log
<trackbot> Date: 12 March 2015
<janina> Hi, Leonie, yes, for today
<janina> It's essentially what Chaals posted, somewhat re-arranged
<janina> Sure. Mostly different order.
<janina> Additional item is "Potential Other Consensus Process Changes"
<janina> PF has been discussing whether we can move closer to HTML'as auto publish heartbeats
<janina> I wanted to explore that a bit further. This comes up from the CfC on "ARIA in HTML" which everyone seems to agree is FPWD ready, but which PF wants to copublish
<janina> Thanks, Shane
<scribe> Scribe: ShaneM
janina: Agenda is largely as Chaals proposed. A couple of corrections.
Apparently nothing special to report.
<darobin> Zakim. [ is me
janina: done with the list of
deliverables and work statement edits.
... we need to pull the deliverables from the work statement so
that they are easily referenceable. Liam can you do that?
liam: we now have one list but it is not in a separate place. can do it.
janina: we should let the co-chairs know that all interested groups to use the central list.
janina: the language is designed
so that we *can* do a concurrent CfC, but sometimes it may
still be useful to do separate ones just to assess
buy-in.
... the groups seem to hold off on starting a CfC until things
are pretty settled.
... Note that the current process means it will take at least
two weeks.
<LJWatson> +1 to the proposed change.
<Zakim> SteveF, you wanted to note that for heartbeta publications in HTML there is no CFC needed
SteveF: Heartbeat publications in HTML don't need a CfC any longer.
janina: yes - we will discuss that next.
<MarkS> +1
<plh> +1
janina: It seems like there is agreement. We will need to do a CfC to adopt this change.
+1
<darobin> +1
janina: FPWD requires consensus.
Moving to CR requires consensus. Heartbeat publications do not
require it in the html working group.
... the PFWG has not adopted this change yet.
... current process requires a week minimum.
... Proposal that a heartbeat would be announced in advance so
that people would have a chance to chime in. Not quite the same
as HTML.
<Zakim> darobin, you wanted to mention Echidna/automated publication
darobin: W3C now has an automated
publishing system. Groups that opt in can get things
automatically published as a heartbeat.
... document users have complained that there is confusion
between editors drafts and published heartbeats.
... would be nice to eliminate editors drafts altogether,
instead having frequent automatic heartbeats.
janina: we have discussed this in
PF
... because of the PF horizontal review stuff frequent
heartbeats are going to make it challenging to track documents
as they evolve.
... PF knows to look at FPWD, but we don't know when we need to
apply time later in the process.
SteveF: There are problems with
PF documents. ARIA authoring practices, for example, there are
many URLs. Some are a couple of years old.
... when I am referencing things I want the most recent
version.
... we need to ensure that content is not stale.
janina: we need to have URIs be reliability and stability.
Judy: Note that PF name change will not effect document URIs.
<Zakim> ShaneM, you wanted to ask about process rules for Echidna
ShaneM: do we need to adopt the new process rules to use Echidna?
darobin: Yes. HTML WG has adopted it for the HTML spec already.
<Zakim> darobin, you wanted to point out that Echidna still has dated specs
darobin: Echidna still generates
dated versions of specs. It is possible to get to a stable
point and issue a call for wide review against a dated
version.
... this would be a point where horizontal review would take
place.
janina: the issue is how do we know when changes are substantive or editorial. The length of the diff is one way.
LJWatson: The benefit of frequent heartbeats is clear to the consumers. Heartbeats are just small steps on the way to the milestones we use for reviews anyway.
SteveF: document is essentially a
set of requirements for conformance checker implementors and
authors as to when and how to use aria attributes
... same requirements that were in the HTML specification in
the WAI-ARIA section.
... as part of M12N, was asked to split off this content into a
separate document.
... HTML 5 implementation requirements on browsers will be in
the ARIA mapping specification (HTML-AAM)
janina: no disagreement that this
was already in HTML 5
... and that it is probably ready for FPWD.
... PF would like to be a co-publisher of these two documents
because they are a significant amount of work on the part of
the PFWG.
... there has been contention in the past, and PF if concerned
that we remain in the loop so that there isn't contention in
the future.
... moreover need to speak with one voice. If we go to the
point of putting this document into the horizintal review
process it would change the charater of the relationship
between PFWG and HTMLWG.
... that didn't work very well. We created this task force to
help ensure things work better, and they now do.
... Particularly as things relate to ARIA, we want to help
ensure work remains smooth.
<Zakim> darobin, you wanted to point out that this has already been removed from HTML
darobin: HTML has a vested
interest in getting this published quickly. M12N needs close
coordination. It would be easy for documents to go out of
sync.
... we would end up being forced to reference the editors draft
instead of a published draft if the document(s) are not
published with similar frequencies.
... I appreciate that things were problematic several years
ago, but we are no longer there. There is a much friendlier
relationship.
<MarkS> +1 to healthy working relationship
darobin: we should not be constrained by things that happened years ago.
janina: the fix is this task force.
<richardschwerdtfeger> +1 to healthy relationship
LJWatson: we have indeed moved a long way. the publication of ARIA in HTML by the HTMLWG sort of underlines the success of this task force.
SteveF: What are the issues from the PF?
janina: no disagreement that
people want it published. The question is what is the long term
status of this document.
... there is a consensus developing in the PF that we would
like to be co-publishers.
<SteveF> can we have a link to the PF minutes?
JF: We are moving toward M12N. Robin said that "this has already been removed from HTML". I am confused about what it means when something is part of HTML or not. I thought extension specifications were supposed to be "part of HTML".
darobin: It has been removed from
the giant specification. That large document is too hard to
review, to maintain, etc.
... it has been moved to a separate document. It has not been
removed from the HTML language.
richardschwerdtfeger: A concern is that someone could create a new role, for example. We worry about taxonomy impacts. That's the sort of thing that the PFWG is concerned about with the ARIA in HTML document. It is about tight coordination.
janina: and we need to keep synchronized with the other ARIA documents too.
<SteveF> note to rich, aria in html doc does not define any roles, states or properties
<darobin> and if it did we'd hit SteveF
richardschwerdtfeger: Google has also asked us to create some way to do things for web components with regard to ARIA.
<JF> +1 to clarity in talking points
Judy: M12N is about evolving the
HTML specification. SteveF is working on ARIA stuff as a module
because it is his particular interest.
... and yes, W3C needs to get its talking points in order. We
are NOT removing things from HTML the language.
... HTML and ARIA are both evolving. SVG is going to be
evolving. Unless we are closely coordinating we are going to
have a mess later on.
... there are valid concerns about timing and synchronization.
We should be able to work that out on a coordination level.
CynS: The concern is more about being part of the product design team, as opposed to a reviewer after the fact.
<Zakim> darobin, you wanted to point out that PF can be copublishers with the document still in Echidna (at least when Echidna gets fixed to support that)
CynS: we want to work together, not throw things over the wall. Doing it in PF feels like a natural way to handle that.
darobin: There is currently a bug in Echidna that makes it impossible to jointly publish a document right now. But that will get sorted.
janina: What I want to suggest is
that HTML could view this positively. Tight coordination and
synchronization should may be easier as a result of M12N.
... SVG might need to do something similar.
LJWatson: This information as
been in the HTML monolith all along. Why are we concerned now
that it is separate.
... it doesn't take any more reviewing or coordination.
<Zakim> JF, you wanted to agree with the optics taht Leonie is talking about
janina: because the subject area continues to evolve.
JF: Yes this has been taken out of the big document. I think that is concerning.
plh: PF expecting to be an author to any document that talks about ARIA is not going to work. HTMLWG had a similar problem with HTML extensions.
<SteveF> john note I am taking out a large section of the monolith at the moment http://rawgit.com/stevefaulkner/elements-html/master/index.src.html
plh: at the end of the day, PF created ARIA. Now other groups are taking and running with the idea. There will be some coordination problems. It shouldn't mean that PF becomes a co-publisher for every document that uses ARIA.
<Zakim> darobin, you wanted to note that the expectation is that this would actually make things easier to review and sync, compared to the monolith and to also mention that we are looking
darobin: monitoring the monolith
was challenging. With M12N it makes it easier to track for
reviewing and synchronizing.
... We would like to remove pretty much everything from HTML
into smaller specifications.
Judy: nothing is being taken out
of HTML. Things are being split into separate, tightly related
documents.
... the ARIA coordination stuff. When ARIA is getting embedded
we need some ways to ensure it develops well.
... Maybe we need to offload some of the coordination from the
TF to some off-line mechanism.
<SteveF> suggests best way to ensure it gets embedded well is people providing technical feedback on modules
Judy: maybe PF develops a PF
feature that ARIA feels is critical, and HTML doesn't like it,
what happens. Or the converse?
... maybe co-authorship isn't the right word?
plh: the task force is to help
with the coordination. If some group disagrees with what goes
into a spec then that is what this is for.
... because this is on github you can get notifications on
every edit on a per-module basis.
Judy: we know its more effective to handle A11Y at the design stage. Notifications are nice, but influence before the edits / publication is more effective.
janina: Working together ahead of publication is more effective.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/cn/can/ Succeeded: s/It should be fairly obvious when horizontal reviews are necessary./Heartbeats are just small steps on the way to the milestones we use for reviews anyway./ Found Scribe: ShaneM Inferring ScribeNick: ShaneM Default Present: janina, Judy, Joanmarie_Diggs, LJWatson, Liam, ShaneM, Plh, IanPouncey, JF, SteveF, +1.617.319.aaaa, [IPcaller], darobin, Cynthia_Shelly, Rich_Schwerdtfeger Present: janina Judy Joanmarie_Diggs LJWatson Liam ShaneM Plh IanPouncey JF SteveF +1.617.319.aaaa [IPcaller] darobin Cynthia_Shelly Rich_Schwerdtfeger Found Date: 12 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/12-html-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]