See also: IRC log
<MikeSmith> trackbot, start meeting
<trackbot> Date: 26 August 2010
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Scribe_List
<Joshue> I'm changin bridge nos
<oedipus> mike, you sound like you are being held hostage
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Scribe_List
<scribe> scribe: Ben
<MikeSmith> action-54?
<trackbot> ACTION-54 -- Judy Brewer to follow up that NCAM files can be used in HTML5 testbed -- due 2010-08-25 -- OPEN
<trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/54
<MikeSmith> action-47?
<trackbot> ACTION-47 -- Steve Faulkner to file a bug with HTML 5 about making autocomplete consistent with ARIA, per comment 289 http://www.w3.org/WAI/PF/Group/comments/update?comment_id=289 -- due 2010-07-29 -- OPEN
<trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/47
<MikeSmith> action-47 due 2010-09-02
<trackbot> ACTION-47 File a bug with HTML 5 about making autocomplete consistent with ARIA, per comment 289 http://www.w3.org/WAI/PF/Group/comments/update?comment_id=289 due date now 2010-09-02
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Alt_tech_appendix
<MikeSmith> action-28 due 2010-09-02
<trackbot> ACTION-28 - prepare text for SteveF's guidance document about future of data-mining using RDFPic methodology outlined in post to list due date now 2010-09-02
<MikeSmith> action-28 due 2010-09-09
<trackbot> ACTION-28 - prepare text for SteveF's guidance document about future of data-mining using RDFPic methodology outlined in post to list due date now 2010-09-09
<oedipus> action-28: http://www.w3.org/WAI/PF/HTML/wiki/Alt_tech_appendix
<trackbot> ACTION-28 - prepare text for SteveF's guidance document about future of data-mining using RDFPic methodology outlined in post to list notes added
http://www.w3.org/WAI/PF/HTML/wiki/Bugs/New_A11Y_Bug_Snapshot
<Marco_Ranon> (sorry for the delay - usual issues dialling in)
MC: Marco, Martin and I have met 3 times and have reviewed a number of bugs.
<Marco_Ranon> thatnks
<kliehm> http://www.w3.org/WAI/PF/HTML/wiki/Bugs/Bugs_Awaiting_A11yTF_Keyword_Decision
MC: we talked about process, request for Paul regarding prioritiziation. we have reviewed bugs identified by laura as bugs the task force shoudl take up
<kliehm> http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html
<kliehm> http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0124.html
MC: trying to be strict about those that the task force really needs to deal with. details of that are in the reccs we sent. next step for subteam is to go through all bugs in a resolved (particularly needs info) state and, whenever possible, provide the information needed ourselves. Process will be to feed that info back through the TF before adding it.
will be cases where we'll need to ask for help from individuals on the task force. this project will be the main focus in the subgroup for a while and it's likely to take a fair bit of time. will try to do it in a strategic and prioritised manner.
<kliehm> http://www.w3.org/WAI/PF/HTML/wiki/Bugs/New_A11Y_Bug_Snapshot_20100821
JF: may be related, but noticed a whole slew of new accessibility related bugs. what is process for dealing with new bugs as they arrive?
<paulc> Probably all the new bugs are sub-cases from 10066?
MC: Intention to process new bugs is there. Would be willing to take advice about relative priority. Should we look at new bugs first or should we focus on "needs info" bugs?
think we nee to focus on needs info first
SF: New bugs are largely in regards to ARIA in HTML5 proposal. Understanding is that there will be push from HTML chairs to process those.
MC: Assume some will end up in needs info state.
SF: there is new one related to longdesc that may be worth looking at soon
<paulc> The Editor has processed 15 of the 30 A11Y bugs recently.
<paulc> I suggest the sub-group prioritize looking at those processed items first.
MC: trying to minimize the set of bugs that should go to the TF, many bugs that are important and we hope individuals will continue to work on them, but they don't rise to the level of requiring the resources of the entire TF.
<paulc> Finding the NEEDSINFO or WONTFIX bugs that the TF needs to look at and possibly escalte is a high priority.
MC: Are there any concerns with what we're suggesting or the process?
<kliehm> http://www.d.umn.edu/~lcarlson/html5bugchart/20100821/
PC: My interest as co-chair is that I want to know how much of a long haul we have to get to last call. Understanding how many issues we have and how many are likely to require our attention in the short term is a high priority.
expect that the editor will continue to process remaining accessibility bugs. haven't seen any efforts of TF to accept the reccs. from the subgroup
PC: want to know what the numbers are
<JF> +1 to Mike's suggestion
MC: proposal would be that the TF accept the reccs on those 18 bugs that should be TF bugs. This is cathing up on bugs that have been entered over the past year. Add them to the list, then from here on focus initially on needs info and other bugs in hopes of decreasing hte overall count.
<kliehm> @Mike, that would have been my question: TF decides or delegates it to us?
<Zakim> MikeSmith, you wanted to say that we could resolve on the call today to give the bug-triage subteam authority to tag bugs with a11ytf keyword
MC: The more resources we put on it, the faster we can reduce the count.
MS: If we chose to, I'd propose that we can resolve on the call today to give the bug triage team the authority to go ahead and tag the issues based on their assessment.
Would be useful to have some more people involved in the bug triage calls.
<paulc> I suggest we make this a "default action" ie the sub-group does the analysis, reports their results, tags the bugs with A11Y and TF members can push back if they want.
MS: Does anyone object to authorising the bug triage group to go ahead and tag the issues?
MC: Not comfortable with one person doing this, but am more comfortable with 4.
Janina: I think it's a good idea. Certainly we should track the activity, but we should enable people to take on tasks.
MS: Point of contention is not going to be what gets accepted, but I can imaging that there will be some issues that aren't tagged and taken up by the TF are going to want to ask the subteam to reconsider.
MC: Agree, we have tried to
provide rationale for why the TF should not take an issue
up.
... Do we want to go as far as authorizing the group to go
ahead and add needs info responses as well?
... Somewhat scarier to delegate that to the subteam.
PC: Are you talking about needs info as issues that have come back from the HTML WG?
MC: Yes.
... Talking about trying to provide the information needed.
PC: Agree that it is more complex. Suggest that the group be very conservative with this. If your conservative approach leads you to be confident in a response, okay to go ahead.
JS: Am willing to trust the
subteams decisions, especially if decisions are being tracked.
Not too concerned if someone on subteam disagrees.
... Would maybe look for, this is what we propose, if no
objections in x (resonable timeframe) then that's what we'll
do.
PC: Should be looking to expedite in any way possible processing needs info and other issues that need reply. Reason is that for every day we don't, we're adding a day to the timeline.
MC: Would you like us to go in reverse chronological order so that recent ones are processed more quickly?
PC: No, would analyse them and use judgement to prioritise.
<Marco_Ranon> unmute me
<Marco_Ranon> q
<Joshue> zaki, unmute me
<Marco_Ranon> zaki, unmute me
<Joshue> +q to say I will lend a hand if ya like
<kliehm> agreed
<Zakim> Joshue, you wanted to say I will lend a hand if ya like
MC: We can talk about best way to operate as we grow. Would like to find ways to better distribute the efforts.
Joshue: can lend a hand if you like
MS: Also some of the details about how to prioritise are good. Sounds like we have a plan there. Second part of what you wanted to do was to to through some specific bugs.
<kliehm> I'll try to recruit a few people at a11yLDN unconference September 21 in London.
MC: May be OBE if okay to go ahead and implement previous reccs.
MS: If people have additional comments, please raise them.
SF: There was a discussion with the chairs. We have updated the proposed text in response. Chairs wanted to break down proposal into various bugs. That has been done (about 10 different bugs in regards to our proposal). That doesn't cover all the bugs, but it does cover some of them. Unsure what will happen if some of them are rejected.
PC: You're right that it hasn't
been discussed. Our plan is to expedite these bugs and process
them within a week.
... Chairs are meeting later today and we are expecting
everyone to be responsive to requests to expedite these.
SF: Some issues that aren't as
clear cut, so unsure what will happen with some parts of the
proposal.
... Changes to organization, conformance checking,
implementation etc. that we'd like to have reviewed.
PC: I'll reflect that when chairs discuss later today.
JS: TF should be aware that there has bee some questions going on and another approach is being explored. The other approach is to say that the whole section (3.2.6) is so riddled with issues that it really doesn't make sense to fix it item by item. Would be easier in many ways to start with an entirely new baseline draft and look at that item by item. Really a question of how you choose what the baseline is for discussion.
Is is being discussed at a number of different levels.
PC: Biggest argument I've heard for why people would not be in favor of publishing separately is that the text we're talking about impacts validation. In the past when we've talked about removing things from the spec is that some believe that anything that impacts validation should remain in the spec. We're not saying no, but could get into a difficult dialogue based on that criteria.
SF: My understanding is that we would progress this in a way that could be integrated back into the HTML5 spec.
JS: question to me is what is the best way to integrate these issues and get into last call. addressing issues with existing draft may be the harder way to go
SF: what comes out of this first
round of bugs will help us decide whether it's better to
continue with current process or not
... don't want to get back to a situation where we have
hundreds of bugs to deal with.
MS: Want to point out that everyone does not want to waste time on this. Any approach is worth considering if it seems like it will save us time.
<oedipus> phone died - can't find adapter
MS: One of the bugs points out that there isn't enough info in the current spec to be able to write a schema that can be used by a validator to do ARIA conformance checking. So, I think one of the people who has the most insight on this is Henri. If we can get him to weigh in and try to help us identify a quicker way forward, I think that's what we should do as an action to move forward. Would help if others can informally ask him to spend some time looking at
this.
SF: The document we produced provides every HTML element and attribute (hopefully) that has mappings to ARIA. Should be possible for conformance checkers to use this.
<Zakim> MikeSmith, you wanted to suggest that we try to get a high-level assessment from Henri on this
<JF> welcome and thanks janina
MS: Some offline discussion that it would be useful to have some extra help. Janina has volunteered to help out and co-facilitate.
JS: Was never the intent that
John should have to carry the load on this, trying to go back
to original plan of having multiple facilitators.
... We've announced a user reqs document that is ready for
people to review.
... Next big (very big) milestone is nest week. We expect to be
presented with a technical prioritisation that looks at the
dependency chain of the needed technologies. That will help us
know what decisions can be made and when as well as which can
be solved first. Expect to have this by next Wednesday's
meeting.
<Joshue> Good plan!
MS: Comments? Questions?
JF: If people can look at user needs document we feel it's fairly mature, but are still open to feedback and comments.
<JF> bye all
<Joshue> Bye!
MS: Should probably put this at the top of next week's agenda. It remains a high (if not the highest priority) at this point.
zakim close this item
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Ben Inferring ScribeNick: Ben Default Present: Eric_Carlson, John_Foliot, Michael_Cooper, Mike, Janina, Gregory_Rosmaita, Jon_Gunderson, Steve_Faulkner, kliehm, Ben_Caldwell, Paul_Cotton, Joshue, Marco_Ranon Present: Eric_Carlson John_Foliot Michael_Cooper Mike Janina Gregory_Rosmaita Jon_Gunderson Steve_Faulkner kliehm Ben_Caldwell Paul_Cotton Joshue Marco_Ranon Regrets: Denis_Boudreau Laura_Carlson Kenny_Johar Sylvia_Pfeiffer Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0235.html Found Date: 26 Aug 2010 Guessing minutes URL: http://www.w3.org/2010/08/26-html-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]