Re: Minutes from 12 March 2015 Meeting

They would be working group private until they are reviewed.  They wont be
public until next week.

On Thu, Mar 12, 2015 at 11:39 AM, Steve Faulkner <>

> As requested during the call, can someone provide the URL for the PF
> meeting minutes for this week?
> --
> Regards
> SteveF
> HTML 5.1 <>
> On 12 March 2015 at 16:06, Shane McCarron <> wrote:
>> Draft minutes from the meeting are at
>> 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
>> Proposed Concurrent CfC Procedure
>> 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
>> <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
>> 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
>> 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
>> 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:
>> People with action items:
>> [End of scribe.perl diagnostic output]
>> --
>> Shane McCarron
>> Managing Director, Applied Testing and Technology, Inc.

Shane McCarron
Managing Director, Applied Testing and Technology, Inc.

Received on Thursday, 12 March 2015 16:56:15 UTC