Minutes: 26 August 2010 HTML Accessibility Task Force

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


           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




      * [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
    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:

    <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


    MC: Marco, Martin and I have met 3 times and have reviewed a number
    of bugs.

    <Marco_Ranon>  thanks


    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



    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.


    JF: may be related, but noticed a whole slew of new accessibility
    related bugs. what is process for dealing with new bugs as they

    <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

    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

    <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

    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

    <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

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

    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
    ... We've announced a user reqs document that is ready for people to
    ... 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