W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2010

minutes: HTML Accessibility TF telecon 2010-04-29 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 29 Apr 2010 18:17:08 +0100
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-Id: <20100429171440.M55895@hicom.net>

minutes from the 29 April 2010 HTML A11y TF teleconference are available
as hypertext at:


as an IRC log at:


and as plain text following this announcement -- please log any errors,
omissions, mis-attributions, and/or clarifications by replying-to this
announcement on-list...

thanks to John Foliot for scribing, gregory.



                             - DRAFT -

            HTML Accessibility Task Force Teleconference

29 Apr 2010


  See also: IRC log: http://www.w3.org/2010/04/29-html-a11y-irc


         John_Foliot, Eric, Janina, Michael_Cooper, kliehm,
         Gregory_Rosmaita, Jim_Allan, Janina_Sajka, Marco, Kelly_Ford,
         Sean_Hayes, Paul_Cotton, Rich, Ben, Cynthia_Shelly,
         Steve_Faulkner, Geoff_Freed, David_Bolter

         Laura_Carlson, Sylvia_Pfeiffer, Denis_Boudreau




    * Topics
        1. Action Item Reviews
        2. Canvas Subgroup Update
        3. Media Subgroup
        4. Summary Proposal
        5. CfC on the Zero Edits Resolution
        6. Issues 90, 91, 93, 95, 96, 97
        7. Sub-Group Reports
        8. Missing @alt
        9. Deadlines for TF Deliverables
       10. MCooper's Bug Review
    * Summary of Action Items

  <trackbot> Date: 29 April 2010

  <janina> Meeting: HTML-A11Y telecon

  <janina> Chair: Janina_Sajka

  <janina> agenda: this

  <JF> scribe = jf

  <oedipus> scribe: John_Foliot

  <oedipus> scribenick: JF

Action Item Reviews

  JS: tweak to agenda - review of open issues - UI issues

  action item review

  <trackbot> Sorry, couldn't find user - item

  action 25 - Steve F

  <trackbot> Sorry, couldn't find user - 25

  will leave open - steve not on call

  <kliehm> ACTION-25?

  <trackbot> ACTION-25 -- Steve Faulkner to post notice to a11y TF
  about http://dev.w3.org/html5/alt-techniques/ and how to make
  comments -- due 2010-04-22 -- OPEN

  <trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/25

  will re-visit Issue26 later in the call

  subteams: Canvas

Canvas Subgroup Update

  RS: awaiting responses - nothing heard over the last 2 weeks
  ... will 'shake the tree' on outstanding Canvas issues this week
  ... affecting deadline - needs more comments



  RS: concern of exposing this level of API
  ... Caret issues still needs resolution
  ... proposal exists - question is how does this get mapped to A11y

  <inserted> scribenick: oedipus

Media Subgroup

  JF: had lenghthy but productive call yesterday; touched on
  Javascript API for Text Associations; talked about timestamp format;
  don't have concise and formal rfequirements stateement -- spread
  over multiple docs, JF has action item to distill into something
  clear and cohesive
  ... playing catch-up; will submit document to TF when finished so
  can base future work
  ... discussed media requirments versus feature reqs
  ... need to address a11y in <video> and <audio> - urgency as is
  being implemented without a11y
  ... media in HTML5 - introduces multiple layers of complexity
  ... short term needs and longer term needs and reqs; roadmap for
  media work; very productive call; tough on attendees -- australians
  up early, europeans up late
  ... time was 3PM Vancouver time; workable -- will have series of
  calls over next few weeks;
  ... will perhaps later move to every-other-week

  SF: WHAT WG stuff -- where does that fit into what is being done in
  media subgroup

  JF: underscores sense of urgency; implementation outside of our
  control - have to focus on what is being currently implemented; need
  to re-review WHAT WG req documents -- seems to be a pretty good
  start but have to check to see if included everything; will consider
  and use in collating document


  JF: encourge TF members to review the WHAT WG materials

Summary Proposal

  JS: Wendy not on call

  JS: propose we defer on this

CfC on the Zero Edits Resolution

Issues 90, 91, 93, 95, 96, 97

  JS: one vote recorded against
  ... no-one else has commented

  cyns: silence equals agreement?

  JS: essentially, yes

Sub-Group Reports

  JS: suggestion is to vote on the call
  ... not required to respond to the email - email offered the
  opportunity to register your voice

  MC: essentially silence DOES equal concurance
  ... removes the ability to have an objection later down the road

  <oedipus> GJR does not object to closing CfC for issues 98, 91, 93,
  95, 96, 97

  <janina> RESOLUTION: The HTML-A11Y Task Force supports the zero-edit
  change proposal at 
  We note this proposal closely tracks our previously submitted

  <janina> ISSUE-90 figure, ISSUE-91 aside, ISSUE-93 details, ISSUE-95

  <janina> ISSUE-96 progress, and ISSUE-97 meter at:

  JS: per request of group from last week, that we come up with a
  formal language here
  ... JS is there discussion? Is there opposition?
  ... declare that we accept this, and JS will formally forward this
  to the WG Chairs

Missing @alt

  JS: almost closed this last week, lacked formal language
  ... rectivated discussion on list this week
  ... 2 comments emerged

  <richardschwerdtfe> need to drop off

  JS: introduction of a "missing" atribute
  ... not sure if we want to further perfect the original proposal
  ... do we need to re-open?

  <inserted> scribenick: oedipus

  JF: responded late this morning before call -- discussing 2 issues
  on list - 1 is introduction of new attribute that is indicator that
  author explicitly declined to use alt text; second is crowd-sourcing
  or metadata mining as repair -- that is going back down the image
  hueristics issue which we voted down; need to de-link 2 issues;
  support specific indicator for missing @alt - indicates author
  provided opportunity to provide @alt text and did not; crowd-so


  JF: approved matt's statement on Issue 66 to strike OCR from text --
  to me, crowd-sourcing and data-mining are similar

  JS: personal statement (not wearing chair's hat) -- may have
  negative copyright implications - should stay clear of that; if not
  in spec, doesn't mean can't happen -- putting in spec gives far more
  credence than we are in position to accept

  KF: personally, agree with JS 100% -- dangerous thing to do

  <inserted> scribenick: JF

  JS: JS - anyone wishing to speak in favor of crowd-sourcing?

  Cyns: adding it to UAAG might be a good idea, but not the spec

  GJR: it could be added to SteveF's guidance document

  JS: appears consensus of call that crowdsourcing not be included in
  the spec
  ... JS leaves open the question what to do with the 'Flickr' problem

  GJR: would like to use SteveF's document to point out how
  crowd sourcing might work with a tool such as the w3c open source
  tool RDFPic

  JS: a "missing' attribute would not be objected to, but we leave to
  the HTML WG to decide
  ... not sure if it is important to hold up consensus of current
  ... appears that we have a good recommendation

  Cyns: perhaps vote on the existing proposal, and suggest a sperate
  Change Proposal for any new attribute
  ... i.e. @missing or equiv

  JS: I believe that this might be the better way forward


  SF: agrees that this kind of guidance could go into the guidance
  document he is working on

  GJR: yes, could add the metadata stuff he floated on the list to
  document steve is working on as well


  JS: steve's document will include both practical guidance and a look
  at future possibilities

  GJR: will contribute proposed Appendix text for SteveF's textual
  alternatives "module"

  <oedipus_> ACTION: Gregory - prepare text for SteveF's guidance
  document about future of data-mining using RDFPic methodology
  outlined in post to list [recorded in

  <trackbot> Created ACTION-28 - - prepare text for SteveF's guidance
  document about future of data-mining using RDFPic methodology
  outlined in post to list [on Gregory Rosmaita - due 2010-05-06].

  <oedipus_> plus 1 to approval now with addendum later

  <janina> RESOLUTION: The HTML-A11Y Task Force supports the change
  proposal at
  to implement WAI Consensus Guidance that a missing text
  alternative should be an error in conformance checkers. We expect the error
  text will reference additional guidance on text alternatives in WCAG
  support materials.

  proposal from cyns is to vote on previous/existing alt text
  proposal, and ask Laura et al to work on @missing or equiv

  <oedipus> plus 1 to approval now with addendum later

  JS: any discussion? any objections on adoption of the Change

  <inserted> scribenick: oedipus

  <inserted> RESOLUTION: The HTML-A11Y Task Force supports the change
  proposal at
  to implement WAI Consensus Guidance that a missing text alternative
  should be an error in conformance checkers. We expect the error text
  will reference additional guidance on text alternatives in WCAG
  support materials.

  <inserted> ScribeNick: JF



  JS: not just the a11y TF being put under pressure
  ... HTML WG Chairs are pushing all TFs and groups
  ... heading towards a Last Call
  ... deadlines can be positive - they force decisions - no need to
  continue talking
  ... and highlights real open issues
  ... as long as we are reasonable in moving forward
  ... agree to work with deadlines, as long as we remain in control
  ... TF needs to start thinking seriously about deadlines
  ... example - media is still too wide open, however canvas is well
  along and finding a deadline for that might be easier

  GJR: one thing to ask the WG is to remember that we are replacing
  some things that have been remove - we are being asked to
  re-engineer some things, and that takes time

  JS: aware that some old battles appear to be being re-fought

Deadlines for TF Deliverables

  JS: suggesting late May for Canvas resolution (20th or 27th)
  ... Wendy not on call to discuss Summary, but Proposal exist to
  re-install @summary as found in HTML4 to act as a place holder
  ... to remove 'pressure' for now, with understanding that we are
  working on a more comprehensive solution

  Cyns original proposal was poorly received by the WG, which is why
  she went back to it originally

  PC: as a result to that significant feedback, Cyns went back to the
  drawing board, which is why Proposal B emerged - in another

  Cyns: Proposal B doesn't seem to be any less controversial than the
  orignal propsoal
  ... if we can get a position to re-instate the orignal @summary,
  that would buy time
  ... but don't feel that this will move forward based upon previous

  PC: good question - if there was a bug that stated re-instate HTML4
  accessibility issue (@summary) then that might work - asking for
  more guidance

  might be feasible as an operational issue, but might not give us
  amuch actual guidance

  Cyns: Cyns - what that would give us is taht we could stop arguing
  about it, and focus on real engineering work (canvas , ARIA
  mappings, etc.) - allows us to focus engineering resources on the
  hard bits

  not on the emotional battles that many consider to be old news

  + 1 greg

  <oedipus> GJR believes first question to be answered vis a vis
  summary is: attribute or element

  JS: Wendy's work is on improving table analysis to reduce the need
  for a summary mechanism

  SF: might be seen as a backwards step
  ... won't move issue forward

  <Zakim> oedipus, you wanted to say that we still have competing
  summary proposals

  Cyns: *if* we could do this just for summary, might find reception

  KF: agrees with most of what cyns said, however if should not
  propose something predicated upon something that may or may not
  happen in the future

  <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Table

  <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Table_Summary

  Cyns: put back HTML4 text, work will continue, it may or may not be
  fruitful replacing some of the use-cases of summary

  GJR: points out we have competing proposals summary as attribute
  versus summary as an element
  ... suggest we decide which thing it should be: attribute or element
  ... gives us a clear path on whether we continue with the HTML4
  perspective or as a new work effort

  Cyns: would like to maintain status quo, only because it works today
  - use as a deffering move
  ... then address from an engineering issue down the road

  JS: is there an objection here?








  JS: We have a consensus on direction - JS and Cyns will work on
  language for a Recommendation for next week to formally address this

  for next week to formally address

  JS: HTML to ARIA mapping meetings on Tuesdays 3:00 PM Boston time


  JS: other interested parties invited to participate
  ... we appear to have real action and next steps to all existing

MCooper's Bug Review

  Action26 on Michael - remaining UI bugs

  <MichaelC> Discussion on open bugs

  MC: reviewed open bugs, and is 'stuck' because bugs discuss mor
  about what Use Agents should do
  ... agrees that something should be said, but not sure if the spec
  is the right place to say it
  ... 2 response today
  ... Laura and Ian so far

  <oedipus> cooper's bug post:

  <oedipus> laura's reply:

  <oedipus> hixie's reply:

  <oedipus> hixie: "If there are UI-specific requirements in the spec,
  please file bugs. In most cases, those are mistakes. (There's a few
  special cases where I have included UI requirements; those are
  generally either for accessibility or security reasons, and even
  those should generally only be "SHOULD"-level requirements.)"

  MC: would like to propose to take Ian's interpretation - these are
  User Agent issues - and proposes to close them
  ... they should not be spec bugs
  ... they are interface issues + we have other issues we are working

  Cyns: what to do if we disagree


  <oedipus> hixie: "The distinction is between what is UI-agnostic UA
  behaviour and what is UI-specific UA behaviour."

  SF: does this take into account things like Drag and Drop?

  agrees that they should perhaps not be spec'ed, but they need to be
  referenced to guidance, etc.

  MC: 1 criteria to use is to understand expected UI behavior

  ie in Drag and Drop - not sure that it is complete enough to be

  having gone through the exercise, can see that this might be

  Cyns: not comfortable with Ian's blanket assertion that this doesn't
  apply to the spec

  JS: next steps?

  MC: with some of the bugs, it is clear what to do. those that are
  unclear to be put out and considered case-by-case

  Cyns would prefer that

  +1 from SF, and myself

  JS: thanks all


Summary of Action Items

  [NEW] ACTION: Gregory - prepare text for SteveF's guidance document
  about future of data-mining using RDFPic methodology outlined in
  post to list [recorded in

  [End of minutes]

Received on Thursday, 29 April 2010 17:17:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:10 UTC