See also: IRC log
<trackbot> Date: 12 March 2015
<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0013.html
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0047.html
<scribe> scribe: MichaelC
<richardschwerdtfeger> : httpsagenda://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0013.html
js: do we want to be co-publishers of this?
it´s up for CfC to FPWD in HTML
it was previously a sole deliverable from them
but now the modularization approach they´re taking changes the calculus
and among other things causes them to republish as FPWD
while PF always can review specs post publication, as part of our spec review role
it can be easier to address some issues pre publication
on docs of close interest like this
which is what the HTML A11Y TF had been doing
rs: my view is PF owns ARIA
but also don´t want to be heavy handed
and we have plenty to do
so I can live with just reviewing the published draft
js: also exploring a process by which they notify us of publication with a certain ¨scream to stop¨ window
and publication proceeds automatically if we don´t scream
but they´re moving to a more rapid publication cycle
it´s possible to publish daily, which makes that idea difficult
rs: really don´t want to review everything that goes out
but also don´t want to discover big holes or coordination issues 5 years down the road
cs: ... like getting rid of difference between editor and heartbeat
makes sense for us not to try to change their process too much
maybe we could schedule regular review on our part
or subscribe to the changes
rs: no way could review every day pre publication
cs: don´t think they would want that either
if we subscribe to the github changes, we can have a standing agenda item to look them over
rs: maybe we just lay down an expectation that if we raise big issues, things stop until addressed
but otherwise, we don´t stand in way of publication
js: so that is pre-publication approval, just with a lighter touch
cs: don´t think they´ll like that
jc: they will view that as obstructionist
we can trust editor of this doc with a11y stuff
cs: how about we just ask ¨if issues found, address in X weeks¨
so gating publication doesn´t work, but ask for reasonable turnaround on issue processing
js: careful not to mix personalities with process
personnel could change for any reason
cs: nonetheless, we should ask for good issue processing
jc: which is how W3C should operate in general
js: in perfect world, we would never have had the issues that led to needing to create HTML A11Y TF
rs: of course if they have reasons, e.g., editor vacation, they can request extension on issue resolution time frame
cs: as we often request of others
js: these proposals are fine
but what if we don´t get satisfactory resolution on an issue we raise?
cs: an escalation path does make sense to define
js: which can go all the way to Formal Objection
cs: but how often do we really need to avail of that?
jc: concern that we come in anticipating conflict
happens a lot, particularly with WAI inputs
some of it is that we take an obstructionist approach from the start
if I did that at my company, I would be sidelined immediately
and lose effectiveness
cs: agree
we should assume good will
think the chairs are fair
the process for picking chairs is fair
rs: let´s take the work on ARIA in SVG
PF doesn´t sign off on that
although I keep PF updated on progress
js: we don´t sign off on SVG or HTML spec
but modules of close interest, we might request sign off for those
cs: we have a bad reputation coming out of the longdesc situation
we need to take active steps to rectify that
also there has been a generational shift in development methodology
we can´t use the waterfall approach any longer
some of the HTML principals are trying to adapt to that
js: want to avoid repenting at leisure
cs: there has been cultural shift towards repenting at leisure
rs: hypothetical, what if we were to define a CSS module without involving the CSS WG?
js: they would tell us to fly a kite
and ask us to bring it to them
jc: we provide specific language in ARIA about host language adoption
js: we were forced into that
rs: my big worry would be if they create new ARIA roles
various: they wouldn´t want to do that
jc: nothing there redefines ARIA
they´re documenting applicability to HTML
they want to move forward in agile way
don´t want us to be a bottleneck
cs: one reason we bottelneck is we´re so overloaded, we ask to review gate then take a while to get to it
that´s a bad reputation
js: not sure if that´s justified
there are other reasons this happens
cs: whether or not it´s justified, it´s the perception of us
that we need to address
we need to work on being more collaborative, and work with them on procedures
js: but not all their procedures are best approach in our view
cs: no, but a lot of stuff happens outside of that forum as well
jc: another viewpoint - I haven´t heard of complaints with how Privacy and I18N work
there is good will, understanding that there are real issues, requests for review
and a general sense of ¨we´re all working together to make the Web work better for everyone¨
if we can all work together, then we´re all part of the W3C team
as opposed to this tedious group on the side that doesn´t understand the issues
that´s the reputation right now
cs: yes; whether or not it´s fair, that is the rep
rs: so I think, if there is a real issue, we flag it and take it up
and otherwise don´t worry about things
cs: trust the process
js: should we close the HTML A11Y TF?
cs: I like the forum for telecons, since the HTML WG doesn´t do that
(it´s just status update meetings)
the A11Y TF is a forum to brainstorm issues
js: main HTML WG has formal process not to make decisions
jc: partly because of wide time zone issues, need to include everyone
js: not hearing any requests to drop deliverables though
cs: which is a different question to the fate of the TF
js: if TF closes, need to sort ownership of deliverables
the one under question now is more an exception
mc: act in a trusting manner, people often try to earn it
jc: in a large organization it´s just not possible to complete projects if a11y must sign off on every thing
so reality is things can be overlooked
that´s a normal part of process, and a reason that things are not considered final
the living standard model makes it easy to address things when they´re uncovered
js: yes to all that, but we´re not asking for the moon in sign-offs
looking for a balance to help assure reasonable sign-offs where needed
jc: the concern seems to be what happens where we disagree
for that, we don´t need extra sign-off process
we need the escalation path
most of the time, valid issues will be resolved amicably when raised
cs: giving clear guidance and authority to the developers can work better
mk: WDs can cycle with opportunities to address, right?
js: at issue is First Public Working Draft
which if it´s solely published by HTML, stays solely with them ever after
mk: we´ll find issues at some point in the process
things don´t just go to Rec right away
mc: the process does allow FPWD to CR on very short time frame, and that is happening sometimes
something for us to worry about indeed
but, that isn´t the situation here with this doc
mk: we´d be reviewing this either way
if it´s a joint doc, will we review sooner or better?
js: no, but want ability to hold up when problems found
jc: but that´s what´s gotten us our rep
cs: another cultural shift is that expert review is less favored
people want to know how to address the issues themselves rather than wait for fly-by experts
bg: I´m not in HTML WG, so wouldn´t know to review things if they came up
is there a way to make sure reviews solicited
js: there may be a charter obligation to proactively solicit reviews
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
js: yes, that´s another issue we need to sort
@@
jc: how about just put it on an X months review cycle
can look at the diff from last review to present
js: most of the time this will work
the question is what happens when it doesn´t
rs: there is process for that
js: which is escalation to Formal Objection
which is very heavy handed, but we´ve had to use it
mc: even threat of that can motivate resolving
though it´s also a negative image issue
js: yes, that escalation path is full of negatives
want the publication sign-off because it is *less* negative than that
bg: @@
js: yes, that´s a mistake
mk: so is this a charter scope issue?
they wouldn´t make normative statements about ARIA, since it´s outside their scope
js: but in a hybrid situation, it could happen
as HTML modularizes further, think this will be a wider issue for W3C
mk: not clear on what hybrid issues would be unaddressed by charters
mc: it is certainly possible to exceed charter scope, through simple error, and for that not to be noticed by reviewers
so question there is, how can that be caught
rs: we can keep an eye on bugs etc.
mk: a respectful relationship will help
js: there is some general ARIA introductory information we want to have heavy input on
and there will be authoring guidance that we´ll be very interested in
rs: think if we use the bug tracker well, we can find / resolve most issues
in fact, we all talk to each other anyways
so not feeling the need for sign-off on top of that
have to recognize HTML is modularizing because it´s so huge
js: agree it´s a good thing
cs: not every bug will get fixed, or as fast as we want, and that is ok
js: but then we´re in situation that some advice about ARIA they give is different from what we give
cs: not necessarily, sometimes it leads to clarification on our end
js: that doesn´t negate our issues
cs: across WAI, we need to change from being the super-special-expert that forces changes through
to somebody with expertise providing guidance, like anyone else
mk: is the probability of problem significantly higher of it is not a joint publication?
I don´t see that
the specific people and working relationships has greater impact
js: that changes over time
mk: yes, but even more, that is the bigger variable affecting things
cs: and right now, things are ok on that front
I heard this morning that they were offended we felt we needed this
<Zakim> MichaelC, you wanted to mention criticality
<richardschwerdtfeger> jc: My position is we don’ t need to included in the joint publication of ARIA in HTML
mc: some a11y issues are critical
we can´t just accept ¨sorry, didn´t get to that¨ or ¨it was too hard to deal with¨
we have to push those hard
others we might not push as hard
have to figure out how we´ll sort things
and use prioritization features in the bug system as part of the tool
cs: yes
<richardschwerdtfeger> Proposall: 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.
<richardschwerdtfeger> 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.
<mattking> +1
<richardschwerdtfeger> +1
<joanie> +1
<fesch> +1
<richardschwerdtfeger> cynthia: +1
<richardschwerdtfeger> mc: abstain
<richardschwerdtfeger> js: abstain
<richardschwerdtfeger> jcraig: +1
<richardschwerdtfeger> bg: abstain
RESOLUTION: The ARIA Task Force believes PF does not need to be a co-publishers of the ARIA in HTML specification but will exercise due diligence in filing bugs where they find issues.
cs: let´s look at this as taking a leap of faith, trying to be good citizens
hope they will hear we are trying to address the perception of obstructionism from us
jd: this is ready to close
mk: yes
RESOLUTION: close action-1440
rs: I have action to draft introductions
Core AAM and SVG AAM published
ARIA 1.1 sent text
can I close?
js: think you can
MC and I would like to do some wordsmithing
rs: it covers the basics of explaining what it´s all about
RESOLUTION: close action-1470
close action-1470
<trackbot> Closed action-1470.
action-1548?
<trackbot> action-1548 -- Joanmarie Diggs to Write revised proposal for aria-current based on today’s meeting for issue 587 -- due 2015-01-29 -- PENDINGREVIEW
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1548
jd: MK wrote notes, LW said looks good, but nobody else responded
mk: feedback in meeting is to make note part of text
jd: will look at APG minutes
<richardschwerdtfeger> http://www.w3.org/2015/02/19-aria-minutes.html
<joanie> action-1548
<trackbot> action-1548 -- Joanmarie Diggs to Write revised proposal for aria-current based on today’s meeting for issue 587 -- due 2015-01-29 -- PENDINGREVIEW
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1548
<sorting through details of discussion>
jd: ok, will clean up
jd: started work on this
but some broken links, have gotten it straightened out, but need more follow up
rs: extending due date
jd: have pushed a branch with proposal
working to incorporate feedback
<richardschwerdtfeger> http://rawgit.com/w3c/aria/action-1349/aria/aria.html#aria-placeholder
rs: ...present the hint?
jd: used what was in HTML 5 spec
not clear what´s really right there
I did lots of shoulds and should nots and notes because I was trying to interpret feedback
open to better suggestions
not sure what is user agent bug vs spec bug
can cross check and edit accordingly
mk: if user deletes field value, placeholder should re-appear
fe: why is that ARIA?
mk: because they´re doing their own placeholder
jd: can I just say ¨make it work like native¨?
rs: recommend not