16:20:07 RRSAgent has joined #aria
16:20:07 logging to http://www.w3.org/2015/03/12-aria-irc
16:20:09 RRSAgent, make logs member
16:20:10 Zakim has joined #aria
16:20:11 Zakim, this will be WAI_PF
16:20:11 ok, trackbot; I see WAI_PFWG()12:30PM scheduled to start in 10 minutes
16:20:12 Meeting: Protocols and Formats Working Group Teleconference
16:20:13 Date: 12 March 2015
16:20:22 RRSAgent, make log public
16:20:26 chair: Rich
16:20:35 meeting: W3C WAI-PF ARIA Caucus
16:26:08 WAI_PFWG()12:30PM has now started
16:26:15 +Rich_Schwerdtfeger
16:29:32 https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0013.html
16:29:38 +??P4
16:29:44 zakim, ??P4 is me
16:29:44 +janina; got it
16:30:53 +Joanmarie_Diggs
16:30:57 https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0047.html
16:31:52 +fesch
16:31:58 +??P9
16:32:08 fesch has joined #aria
16:35:06 zakim, who's here?
16:35:06 On the phone I see Rich_Schwerdtfeger, janina, Joanmarie_Diggs, fesch, Michael_Cooper
16:35:08 On IRC I see fesch, Zakim, RRSAgent, richardschwerdtfeger, newtron, asurkov, LJWatson, ed, janina, MichaelC, joanie, trackbot
16:35:58 scribe: MichaelC
16:36:15 : https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0013.html
16:36:26 s/:/agenda:/
16:36:48 topic: ARIA in HTML
16:37:11 js: do we want to be co-publishers of this?
16:37:19 it´s up for CfC to FPWD in HTML
16:37:26 it was previously a sole deliverable from them
16:37:41 +James_Craig
16:37:42 but now the modularization approach they´re taking changes the calculus
16:38:07 and among other things causes them to republish as FPWD
16:38:39 while PF always can review specs post publication, as part of our spec review role
16:38:42 +Cynthia_Shelly
16:38:45 q?
16:38:48 q+
16:38:51 it can be easier to address some issues pre publication
16:38:56 on docs of close interest like this
16:39:04 which is what the HTML A11Y TF had been doing
16:39:14 rs: my view is PF owns ARIA
16:39:22 but also don´t want to be heavy handed
16:39:29 and we have plenty to do
16:39:39 so I can live with just reviewing the published draft
16:40:06 + +1.650.738.aaaa
16:40:16 js: also exploring a process by which they notify us of publication with a certain ¨scream to stop¨ window
16:40:16 and publication proceeds automatically if we don´t scream
16:40:24 but they´re moving to a more rapid publication cycle
16:40:40 it´s possible to publish daily, which makes that idea difficult
16:40:48 rs: really don´t want to review everything that goes out
16:41:01 q?
16:41:06 ack richardschwerdtfeger
16:41:13 but also don´t want to discover big holes or coordination issues 5 years down the road
16:41:13 cs:
16:41:29 cs: like getting rid of difference between editor and heartbeat
16:41:50 makes sense for us not to try to change their process too much
16:42:05 maybe we could schedule regular review on our part
16:42:08 or subscribe to the changes
16:42:22 rs: no way could review every day pre publication
16:42:40 cs: don´t think they would want that either
16:42:54 if we subscribe to the github changes, we can have a standing agenda item to look them over
16:43:24 rs: maybe we just lay down an expectation that if we raise big issues, things stop until addressed
16:43:33 but otherwise, we don´t stand in way of publication
16:44:05 js: so that is pre-publication approval, just with a lighter touch
16:44:06 cs: don´t think they´ll like that
16:44:14 jc: they will view that as obstructionist
16:44:25 we can trust editor of this doc with a11y stuff
16:44:43 cs: how about we just ask ¨if issues found, address in X weeks¨
16:45:02 so gating publication doesn´t work, but ask for reasonable turnaround on issue processing
16:45:16 js: careful not to mix personalities with process
16:45:25 personnel could change for any reason
16:46:10 cs: nonetheless, we should ask for good issue processing
16:46:16 jc: which is how W3C should operate in general
16:46:26 js: in perfect world, we would never have had the issues that led to needing to create HTML A11Y TF
16:47:13 rs: of course if they have reasons, e.g., editor vacation, they can request extension on issue resolution time frame
16:47:18 cs: as we often request of others
16:47:27 js: these proposals are fine
16:47:48 but what if we don´t get satisfactory resolution on an issue we raise?
16:47:59 cs: an escalation path does make sense to define
16:48:05 js: which can go all the way to Formal Objection
16:48:13 cs: but how often do we really need to avail of that?
16:48:57 jc: concern that we come in anticipating conflict
16:49:14 happens a lot, particularly with WAI inputs
16:49:30 some of it is that we take an obstructionist approach from the start
16:49:33 +Matt_King
16:49:40 if I did that at my company, I would be sidelined immediately
16:49:43 and lose effectiveness
16:49:48 cs: agree
16:50:05 we should assume good will
16:50:05 think the chairs are fair
16:50:11 the process for picking chairs is fair
16:50:22 rs: let´s take the work on ARIA in SVG
16:50:29 PF doesn´t sign off on that
16:50:51 although I keep PF updated on progress
16:51:04 js: we don´t sign off on SVG or HTML spec
16:51:21 but modules of close interest, we might request sign off for those
16:51:39 cs: we have a bad reputation coming out of the longdesc situation
16:51:49 we need to take active steps to rectify that
16:52:12 also there has been a generational shift in development methodology
16:52:17 we can´t use the waterfall approach any longer
16:52:32 some of the HTML principals are trying to adapt to that
16:52:38 js: want to avoid repenting at leisure
16:52:49 cs: there has been cultural shift towards repenting at leisure
16:53:13 rs: hypothetical, what if we were to define a CSS module without involving the CSS WG?
16:53:22 js: they would tell us to fly a kite
16:53:28 and ask us to bring it to them
16:53:45 jc: we provide specific language in ARIA about host language adoption
16:53:51 js: we were forced into that
16:54:09 rs: my big worry would be if they create new ARIA roles
16:54:14 various: they wouldn´t want to do that
16:54:22 jc: nothing there redefines ARIA
16:54:36 they´re documenting applicability to HTML
16:54:49 they want to move forward in agile way
16:54:55 mattking has joined #aria
16:54:59 don´t want us to be a bottleneck
16:55:15 cs: one reason we bottelneck is we´re so overloaded, we ask to review gate then take a while to get to it
16:55:22 that´s a bad reputation
16:55:32 js: not sure if that´s justified
16:55:37 there are other reasons this happens
16:55:46 cs: whether or not it´s justified, it´s the perception of us
16:55:49 that we need to address
16:57:06 we need to work on being more collaborative, and work with them on procedures
16:57:17 js: but not all their procedures are best approach in our view
16:57:37 cs: no, but a lot of stuff happens outside of that forum as well
16:58:16 jc: another viewpoint - I haven´t heard of complaints with how Privacy and I18N work
16:58:18 there is good will, understanding that there are real issues, requests for review
16:58:30 and a general sense of ¨we´re all working together to make the Web work better for everyone¨
16:59:11 if we can all work together, then we´re all part of the W3C team
16:59:30 as opposed to this tedious group on the side that doesn´t understand the issues
16:59:37 that´s the reputation right now
16:59:48 cs: yes; whether or not it´s fair, that is the rep
17:00:06 rs: so I think, if there is a real issue, we flag it and take it up
17:00:11 and otherwise don´t worry about things
17:00:14 cs: trust the process
17:00:31 js: should we close the HTML A11Y TF?
17:00:41 cs: I like the forum for telecons, since the HTML WG doesn´t do that
17:00:50 (it´s just status update meetings)
17:01:08 the A11Y TF is a forum to brainstorm issues
17:01:27 js: main HTML WG has formal process not to make decisions
17:01:39 jc: partly because of wide time zone issues, need to include everyone
17:01:59 js: not hearing any requests to drop deliverables though
17:02:09 cs: which is a different question to the fate of the TF
17:02:22 js: if TF closes, need to sort ownership of deliverables
17:02:37 the one under question now is more an exception
17:03:56 mc: act in a trusting manner, people often try to earn it
17:04:32 jc: in a large organization it´s just not possible to complete projects if a11y must sign off on every thing
17:04:40 so reality is things can be overlooked
17:04:57 that´s a normal part of process, and a reason that things are not considered final
17:05:18 the living standard model makes it easy to address things when they´re uncovered
17:05:38 js: yes to all that, but we´re not asking for the moon in sign-offs
17:05:50 looking for a balance to help assure reasonable sign-offs where needed
17:05:58 jc: the concern seems to be what happens where we disagree
17:06:10 for that, we don´t need extra sign-off process
17:06:14 we need the escalation path
17:06:33 most of the time, valid issues will be resolved amicably when raised
17:07:32 cs: giving clear guidance and authority to the developers can work better
17:08:06 mk: WDs can cycle with opportunities to address, right?
17:08:15 js: at issue is First Public Working Draft
17:08:34 which if it´s solely published by HTML, stays solely with them ever after
17:10:27 mk: we´ll find issues at some point in the process
17:10:36 things don´t just go to Rec right away
17:10:52 mc: the process does allow FPWD to CR on very short time frame, and that is happening sometimes
17:11:11 something for us to worry about indeed
17:11:11 but, that isn´t the situation here with this doc
17:11:21 mk: we´d be reviewing this either way
17:11:31 if it´s a joint doc, will we review sooner or better?
17:12:05 js: no, but want ability to hold up when problems found
17:12:09 jc: but that´s what´s gotten us our rep
17:12:23 cs: another cultural shift is that expert review is less favored
17:12:54 people want to know how to address the issues themselves rather than wait for fly-by experts
17:13:26 bg: I´m not in HTML WG, so wouldn´t know to review things if they came up
17:13:51 is there a way to make sure reviews solicited
17:14:10 js: there may be a charter obligation to proactively solicit reviews
17:14:34 mc: we review TR each week and would notice updates, but if they publish daily, will be very hard to know when a review is genuinely needed
17:14:43 js: yes, that´s another issue we need to sort
17:14:56 @@
17:15:05 jc: how about just put it on an X months review cycle
17:15:16 can look at the diff from last review to present
17:15:24 js: most of the time this will work
17:15:32 the question is what happens when it doesn´t
17:15:36 rs: there is process for that
17:16:18 js: which is escalation to Formal Objection
17:16:29 which is very heavy handed, but we´ve had to use it
17:16:43 mc: even threat of that can motivate resolving
17:16:50 though it´s also a negative image issue
17:17:11 js: yes, that escalation path is full of negatives
17:17:27 want the publication sign-off because it is *less* negative than that
17:17:41 bg: @@
17:17:54 js: yes, that´s a mistake
17:18:11 mk: so is this a charter scope issue?
17:18:32 they wouldn´t make normative statements about ARIA, since it´s outside their scope
17:18:44 js: but in a hybrid situation, it could happen
17:19:20 as HTML modularizes further, think this will be a wider issue for W3C
17:19:59 mk: not clear on what hybrid issues would be unaddressed by charters
17:21:19 mc: it is certainly possible to exceed charter scope, through simple error, and for that not to be noticed by reviewers
17:21:38 so question there is, how can that be caught
17:22:42 rs: we can keep an eye on bugs etc.
17:22:52 mk: a respectful relationship will help
17:23:57 js: there is some general ARIA introductory information we want to have heavy input on
17:24:13 and there will be authoring guidance that we´ll be very interested in
17:24:27 rs: think if we use the bug tracker well, we can find / resolve most issues
17:24:44 in fact, we all talk to each other anyways
17:25:08 so not feeling the need for sign-off on top of that
17:25:17 have to recognize HTML is modularizing because it´s so huge
17:25:26 js: agree it´s a good thing
17:26:07 cs: not every bug will get fixed, or as fast as we want, and that is ok
17:26:32 js: but then we´re in situation that some advice about ARIA they give is different from what we give
17:26:46 cs: not necessarily, sometimes it leads to clarification on our end
17:27:34 js: that doesn´t negate our issues
17:27:55 cs: across WAI, we need to change from being the super-special-expert that forces changes through
17:28:12 to somebody with expertise providing guidance, like anyone else
17:28:18 q+ to mention criticality
17:28:34 mk: is the probability of problem significantly higher of it is not a joint publication?
17:28:38 I don´t see that
17:28:46 the specific people and working relationships has greater impact
17:28:51 js: that changes over time
17:29:11 mk: yes, but even more, that is the bigger variable affecting things
17:29:11 cs: and right now, things are ok on that front
17:29:13 ack c
17:29:25 I heard this morning that they were offended we felt we needed this
17:29:43 ack me
17:29:43 MichaelC, you wanted to mention criticality
17:29:58 -James_Craig
17:30:41 jc: My position is we don’ t need to included in the joint publication of ARIA in HTML
17:31:52 mc: some a11y issues are critical
17:32:05 we can´t just accept ¨sorry, didn´t get to that¨ or ¨it was too hard to deal with¨
17:32:18 we have to push those hard
17:32:25 others we might not push as hard
17:32:31 have to figure out how we´ll sort things
17:32:43 and use prioritization features in the bug system as part of the tool
17:32:50 cs: yes
17:33:52 Proposa: The ARIA Taske Force believes PF should not be a co-publishers of the ARIA in HTML specification but will be due diligent in filing bugs where they find issues.
17:34:06 s/Proposa/Proposall/
17:35:11 Proposa: The ARIA Taske Force believes PF does not need to be a co-publishers of the ARIA in HTML specification but will be due diligent in filing bugs where they find issues.
17:35:51 +1
17:36:05 +1
17:36:11 +1
17:36:12 +1
17:36:43 cynthia: +1
17:36:58 mc: abstain
17:37:02 js: abstain
17:37:10 jcraig: +1
17:38:14 bg: abstain
17:38:53 RESOLUTION: The ARIA Task Force believes PF should not be a co-publishers of the ARIA in HTML specification but will exercise due diligence in filing bugs where they find issues.
17:40:20 s/should not/does not need to/
17:41:27 cs: let´s look at this as taking a leap of faith, trying to be good citizens
17:41:49 hope they will hear we are trying to address the perception of obstructionism from us
17:42:49 topic: Action 1440 landmarks section uses "region of page"
17:42:57 jd: this is ready to close
17:43:08 mk: yes
17:43:21 RESOLUTION: close action-1440
17:43:35 topic: Action 1470 Draft introductions to ARIA 1.1, Core-AAM, and SVG-AAM
17:43:46