- From: Ben Caldwell <caldwell@trace.wisc.edu>
- Date: Thu, 26 Aug 2010 11:18:22 -0500
- To: public-html-a11y@w3.org
26 August 2010 HTML Accessibility Task Force Minutes:
HTML Version: http://www.w3.org/2010/08/26-html-a11y-minutes.html
HTML Accessibility Task Force Teleconference
26 Aug 2010
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0235.html
See also: [3]IRC log
[3] http://www.w3.org/2010/08/26-html-a11y-irc
Attendees
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
Chair
Mike_Smith
Scribe
Ben
Contents
* [4]Topics
1. [5]Actions Review
2. [6]bug triage subteam report
3. [7]ARIA mappings subteam update
4. [8]media subteam update
* [9]Summary of Action Items
_________________________________________________________
<MikeSmith> trackbot, start meeting
<trackbot> Date: 26 August 2010
<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
http://www.w3.org/WAI/PF/HTML/wiki/Bugs/New_A11Y_Bug_Snapshot
MC: Marco, Martin and I have met 3 times and have reviewed a number
of bugs.
<Marco_Ranon> thanks
<kliehm>
http://www.w3.org/WAI/PF/HTML/wiki/Bugs/Bugs_Awaiting_A11yTF_Key
word_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.
JS: 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.
<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 sub-team 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.
It 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
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.
--
Ben Caldwell |<caldwell@trace.wisc.edu>
Trace Research and Development Center<http://trace.wisc.edu>
Received on Thursday, 26 August 2010 16:19:02 UTC