HTML Accessibility Task Force Teleconference

26 Aug 2010


See also: IRC log


Eric_Carlson, John_Foliot, Michael_Cooper, Mike, Janina, Gregory_Rosmaita, Jon_Gunderson, Steve_Faulkner, kliehm, Ben_Caldwell, Paul_Cotton, Joshue, Marco_Ranon
Denis_Boudreau, Laura_Carlson, Kenny_Johar, Sylvia_Pfeiffer


<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

Actions Review

<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

bug triage subteam report

<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


<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.

ARIA mappings subteam update

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


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

media subteam update

<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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/08/26 16:04:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]