Re: Minutes from 12 March 2015 Meeting

As requested during the call, can someone provide the URL for the PF
meeting minutes for this week?

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>

On 12 March 2015 at 16:06, Shane McCarron <shane@aptest.com> wrote:

> Draft minutes from the meeting are at
> http://www.w3.org/2015/03/12-html-a11y-minutes.html
>
> A text version is below.
>
>
> W3C
> - DRAFT -
>
> HTML Accessibility Task Force Teleconference
>
> 12 Mar 2015
>
> See also: IRC log
>
> Attendees
>
> Present
> janina, Judy, Joanmarie_Diggs, LJWatson, Liam, ShaneM, Plh, IanPouncey,
> JF, SteveF, +1.617.319.aaaa, [IPcaller], darobin, Cynthia_Shelly,
> Rich_Schwerdtfeger
> Regrets
> Chair
> janina
> Scribe
> ShaneM
> Contents
>
> Topics
> Agenda review and edits
> CSUN news?
> Work Plan CfC - results
> http://lists.w3.org/Archives/Public/public-html-a11y/2015Mar/0012.html
> Proposed Concurrent CfC Procedure
> http://lists.w3.org/Archives/Public/public-html-a11y/2015Mar/0015.html
> Potential Other Consensus Procedure Changes
> "ARIA in HTML" Issues from PF
> Summary of Action Items
> <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
> Agenda review and edits
>
> janina: Agenda is largely as Chaals proposed. A couple of corrections.
>
> CSUN news?
>
> Apparently nothing special to report.
>
> Work Plan CfC - results
> http://lists.w3.org/Archives/Public/public-html-a11y/2015Mar/0012.html
>
> <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.
>
> Proposed Concurrent CfC Procedure
> http://lists.w3.org/Archives/Public/public-html-a11y/2015Mar/0015.html
>
> 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
> Potential Other Consensus Procedure Changes
>
> 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.
>
> "ARIA in HTML" Issues from PF
>
> 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.
>
> Summary of Action Items
>
> [End of minutes]
> Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
> $Date: 2015-03-12 16:02:43 $
> Scribe.perl diagnostic output
>
> [Delete this section before finalizing the minutes.]
> 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]
>
> --
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.
>