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

minutes: HTML Accessibility TF meeting 2010-02-25

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 25 Feb 2010 17:32:41 +0000
To: public-html-a11y@w3.org
Message-Id: <20100225173152.M12661@hicom.net>

minutes from the 25 February 2010 HTML Accessibility Task Force 
Teleconference are available as hypertext at:


as an IRC log at:


and as plain text following my signature -- as usual, please log any 
errors, clarifications, corrections, mis-attributions, and the like 
by replying-to this announcement on-list...  i will be posting on the 
topic of my unminuted remarks on first needing to ascertain the answer 
to the question of "summarizing text" as an attribute versus an 
element (especially since i got 2 positive comments upon my unminuted 

note that one action item was assigned at today's HTML A11y TF telecon:

   * ACTION-21: Chaals - coordinate concrete proposal for use of
   imagemap in CANVAS 
   * http://www.w3.org/WAI/PF/HTML/track/actions/21


                                   - DRAFT -

                 HTML Accessibility Task Force Teleconference

25 Feb 2010


   See also: IRC log [http://www.w3.org/2010/02/25-html-a11y-irc]


          Cynthia_Shelly, Denis_Boudreau, Eric_Carlson, Gregory_Rosmaita,
          John_Foliot, Jon_Gunderson, Marco_Ranon, Matt, Michael_Cooper,
          MikeSmith, Rich, Stevef, Wendy, chaals, kliehm

          Laura_Carlson, Ben_Caldwell, Geoff_Freed, Markku_Hakkinen,
          Joshue_O'Connor, Kelly_Ford




     * Topics
         1. Introductory Stuff
         2. MultitrackAPI Proposal
         3. TextAssociations proposal
         4. Survey results for CANVAS change proposal
         5. results for summary-details change proposal:
     * Summary of Action Items

Introductory Stuff

   MS: will have scribe rotation list ready for next week
   ... put agendum item on media accessibility -- move to front of agenda
   and address briefly
   ... want to give summary and next steps

   <MikeSmith> agenda:

   MS: experiencing IRC problems - please stand by


MultitrackAPI Proposal

   MS: draft is up-to-date; ready for us to take to TF as a whole for a
   survey; only hold up is survey not yet put together, will be soon

   <MikeSmith> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI

   MS: plan: discuss MultitrackAPI Proposal next week; have survey out at
   beginning of week then discuss on call next week
   ... if have comments or something new to say about draft proposal,
   please take to list


TextAssociations proposal

   MS: please read proposal -- if anything new to say that hasn't been
   said, please post comments to list A.S.A.P.
   ... will be putting together a survey for TextAssociationsAPI for
   beginning of next week so can discuss at next week's call
   ... any questions or comments?

   JF: has been fair amount of discussion on which type of timestamp
   format; a lot of back-and-forth, but no decision; boils down to SRT,
   SMIL tags, etc. - no resolution yet -- anyone with substantive thoghts
   or comments please post

   MS: thanks JF
   ... talked with sylvia today; asked slyvia for some text for basis for
   survey on issue of format
   ... will be reflected in surveys -- probably need discussion; format
   issue clearly needds resolution
   ... for those who haven't weighed in on format discussion, review
   thread if possible to ensure that if you do post something it is
   something new and substantive
   ... comments that lead to action items are encouraged


Survey results for CANVAS change proposal

   s/TOPIC: survey results for canvas change proposal/TOPIC: survey
   results for canvas change proposal:

   MS: approach suggest with documented results, look for
   ... question on canvas simpler than summary versus details survey
   ... want to find points of consensus

   RS: agreement in principle: need ability to: 1) have solution where
   a11y test tool can test when runs into CANVAS; 2) make use of HTML
   components as much as possible (reduces burden on author); 3) need to
   be able to associate a representation of what is in canvas in terms of
   structural info; need to be explicit as to what UA does when
   encounters an a11y implementation for CANVAS
   ... AT (assistive tech) also key
   ... SteveF asked about area/imagemaps -- in HTML5 removed all document
   structural info that one could use in HTML4
   ... imagemap approach would require change in HTML5
   ... advantages to using subtree -- already used for fallback content,
   how do we do binding to convey semantics and structural info
   ... first question for TF: 1) use what is in adom proposal (what is in
   subtree is what author designated as a11y implementation); or 2)
   imagemap / use of AREA - would involve changing HTML5 changes to HTML5

   SF: regards to areas of agreement -- what does that exactly mean
   ... reply to RichS: imagemaps don't supplant use of subtree in
   complicated situations, but in simple situations where someone wants
   some hotspots on a CANVAS, seems lilke ideal solution; pluls for dev
   because easy to do and provides community a way to add text
   alternatives and labesl to hotspots, plus keyboard nav/focus built-in
   ... if follow imagemap will help; problem with subtree issue is
   dichotomy between "fallback" -- is CANVAS available or not available;
   need means of differentiation

   MS: points of agreement -- lot more agreement in survey responses than
   in most surveys
   ... easy for people to note points of disagreement -- looking for
   points of agreement

   <chaals> [The imagemap proposal actually comes from Lachlan Hunt (at
   least that's who showed me the light)]

   MS: sounds as if there need to be some refinements made to proposal
   based on feeddback from survey results -- is that accurate, Rich?

   RS: 2 changes in my mind are easy to make: 1) address DSinger's
   comment on what UA must do if adom is set (include in subtree map for
   API); if false, don't do it; made that change
   ... added part about support of a11y API suggested by Sylvia
   ... agree with SF, imagemap can be good solution for some cases,
   however, it has changed in HTML5
   ... Maciej assumed canvas children always exposed to AT
   ... includes not exposing for currently existing canvas elements --
   how to control currently existing canvas implementations

   <richardschwerdtfe> Therefore I will propose adopting this proposal
   with one of the following changes:

   <richardschwerdtfe> A) Allow <canvas> children to always be exposed to
   AT, even if adom is not set; OR

   <richardschwerdtfe> B) Provide a rationale for not exposing this
   content to AT in some cases (this would likely include not exposing it
   for any currently existing <canvas> elements).

   RS: immediately above are maciej's comments
   ... don't know how one would handle point B

   MS: need clarification from maciej, then
   ... have been changes made; planning other specific changes

   RS: made 2 changes that cynthia and dsinger asked me to address
   ... possibility: imagemap in HTML4 allowed document structure in
   imagemap; with additional placement info, allows one to have same tree
   one has as if in subtree; realize we need to have document structure
   to assist author -- wahty is easier: imagemap (as in HTML4)

   <chaals> [ <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image
   map --> i.e. you can have as many area elements, and as much of
   whatever other HTML, as you want ]

   <MikeSmith> s/syliva/cynthia/

   MS: sounds like a bigger question -- take to list for discussion,

   <chaals> [from HTML 4.01 definition of the map element]

   <Zakim> chaals, you wanted to suggest another interpretation of what
   we agree on

   CMN: agree on functionalities; think adom attribute is a bad idea --
   doesn't provide functionality haven't already got
   ... need to hammer out scenarios -- what can be done with imagemaps
   and other approaches to making content accessible
   ... quick note to steve - bug in latest Opera beta
   ... agree that need to be able to navigate canvas; need to put stuff
   inside canvas; need to put a11y info in CANVAS
   ... completely disagree with adom model - but can achieve everything
   without that attribute; can do much better if HTML4 def of imagemap
   restored to keep things accessible
   ... don't think extra work is that daunting;
   ... adom very hard to explain; if shift imagemap to 4.01 capabilities,
   would be the biggest win; adom doesn't buy anything more

   MS: chaals, concrete alterante proposal?

   CMN: don't do this!!!!
   ... related to issue of what are we trying to achieve; concrete
   proposal for use of imagemaps if returned to HTML 4.01 powere

   MS: where is concrete proposal?

   <scribe> ACTION: Chaals - coordinate concrete proposal for use of
   imagemap in CANVAS [recorded in

   <trackbot> Created ACTION-21 - - coordinate concrete proposal for use
   of imagemap in CANVAS [on Charles McCathieNevile - due 2010-03-04].

   CMN: can have both adom and imagemap

   <MikeSmith> MikeSmith: I want to try to close off discussion on this
   by :35 minutes after

   RS: ok - one thing that may be confusing about adom is
   misunderstanding that this is a validity problem

   CMN: happens because RS keeps saying "testing needs place to pick up
   ... experience suggests that means adom will be *used* as an
   accessibility conformance statement

   MS: one approach is to say: based on survey and call discussion, might
   have critical mass within TF to go ahead with proposal
   ... subgroup spent time on this; task force review; don't want to risk
   wasting time by putting forward prematurely
   ... on other hand, could say "ready for discussion with larger group"
   this can procede in parallell with other efforts

   CMN: object to that - don't do it

   SF: chaals, given we have situation where subtree supposed to be
   fallback and alternate to CANVAS - how to sheild those users from
   having to deal with subtree content if unusable

   CMN: shield users from getting into subtree? imagemap/usemap more
   power than adom -- adom says use this map with this mapping -- can be
   hidden inside CANVAS or OBJECT element
   ... if object isn't rendered, get block content -- that falback could
   be an imagemap -- help one identify part of the subtree as part of
   current interaction, while leaving other stuff out
   ... imagemap designed to be interactive with canvas as rendered and
   fallback content; can use imagemap as part of fallback content or have
   imagemap and fallback content

   MS: running out of time on topic;

   RS: 1 question: imaegmap a solution - instead of adom have "navigate
   sub-tree"? alows someone to use that as a11y implementation and would
   direct test tool to include what is in subtreee -- might be the
   superior approach -- opens up option of use of imagemap

   CS: sounds like might be close enough to do an ammendment on this -
   can we close now and not have to cylce back next week

   CMN: need more discussion and more examples

   MS: yes, more examples; not going to get resolution on call -- have to
   discuss other survey results
   ... can have rest of discussion list today and tomorrow

   RS: be at HTML WG after this -- what is timespan?

   MS: need another couple of days for discussion; making effort to get
   done; had great discussion on list and on TF call today;

   CS: one more week -- need to have written up 48 hours before cal

   RS: i will convey that to HTML WG


results for summary-details change proposal:


   MS: look at points of agreement

   CS: goal of proposal was to break log jam; been going round-and-round
   on summary for years; ran into stalemate of sorts; 1 group adamantly
   against summary use another adamantly for summary
   ... PF's initial position was summary as existed in HTML4 good enough
   -- restore HTML4 verbiage and move on to other things; hasn't resulted
   in clean break
   ... proposal stemmed from discussions in TF; JOC, GJR & WC
   collaborated; CS worked with WC
   ... if better access to structure of table, what is use case for
   summary that aren't covered by ian's proposals
   ... ability to have text that is hidden from "mainstream" users but
   available for AT users who can't perceive table -- equivalent to
   visual info provided by gestalt view of table
   ... other use case: no text that isn't obvious to mainstream
   ... run into both situations: need for summary or text equivalent that
   can't be accomodated by design; also used hidden text to achieve ends
   ... goal -- find a middle point that everyone could live with -- i
   don't love it fully myself, but is an attempt at consensus


   MS: try to see where we have agreement so far


   MS: seems as if this was point of disagreement with proposal, but
   consensus around <button> element

   CS: <button> element piece can be moved into separate change proposal
   ... another goal was to provide clear migration path -- will help with
   ... clear path from summary attribute to details element with summary
   child that is completely different form summary attribute text seems
   ... funtionality of summary in details element is button - use all the
   time outside of forms
   ... big piece is if move from summary to details having summary
   element in details going to be a big problem

   MS: something we are not yet in complete agreement about
   ... seems that we need to evaluate rationales and methods; very open
   to discussion

   CS: agree don't have agreement to do it; agreement that needs to be
   done, though

   MS: position of <DETAILS> - child of <CAPTION> , child of <TABLE> or
   child of both - no consensus yet
   ... some implementation issues brought up around TABLE algorithm

   CS: if can figure out way to have in caption without having caption
   taking place in flow; would expect would be many circumsatances in
   which want visible caption and an invisible summary

   MS: clearly need more discussion
   ... points of agreement: @noflow comments mention that it is
   presentational (open to debate)

   CS: to be clear goal is to find something everyone can live with

   MS: defend proposal against objections

   CS: happy to do that
   ... most interesting about DETAILS piece is that corrects semantics of
   DETAILS; noflow attribute moves behaviour of interactive elements in
   UA where it belongs
   ... show up on hover or focus feature of many details-like objects
   currently implemented

   MS: fundamentals of proposal were most disagreement -- rest of
   questions focus on DETAILS itself assuming that what is proposed is
   something to do
   ... "do you support replacing summary with details" - perhaps should
   have been more fine grained
   ... hard to make yes/no questions on some of these issues
   ... response is that there a number of people in TF who disagree with
   this approach
   ... not clear from survey whether opposed to proposal itself or having
   actual HTML5 spec suggest it as means of providing same sort of info
   that summary attribute is used for
   ... according to WAI guidelines core purpose is to provide summary of
   structural info in table
   ... not clear if completely opposed to replacing summary

   <MikeSmith> a?

   <Zakim> oedipus, you wanted to say it seems that there is disagreement
   over summarizing attribute versus element

   <JF> +1 to Greg's point re: elements vs attributes

   <dboudreau> must admit i also buy Greg's point there

   MS: element versus attribute is clear concern -- can't put further
   structural info into attribut value and have processed by UA or most
   tools -- can't put structure in there
   ... if taking complex table and describing with attribute value,
   without ability to use markup ????? [blocked by typing]

   MM: against proposal full stop; makes process too complicated; dilutes
   purpose of summary to begin with
   ... looks like something hacked together with no control over

   s/MMs: looks/MM: looks/

   MS: sounds as if not opposed to some means to do this as alternative
   to using summary attribute

   MM: if had to chose right now, support LauraC's proposal

   CS: already tried that

   MM: decision process there for this case -- not going to get consensus
   this way

   MS: know about those who commented in survey that are opposed to this
   completely; need proposal for keeping @summary attribute or for
   alternate element

   CS: based on HTML4 or 5?

   MS: HTML4
   ... worthwhile to encourage anyone who disagree to come up with
   alternative alternative?

   MM: would support another proposal with requirement that something be
   visible should NOT affect discussion -- drives proposals off the
   tracks -- onerous requirement

   <dboudreau> personnaly, my main beef is that it would be visible by

   CS: sticking point for those who don't want @summary

   MM: sticking point for me in opposite direction

   MS: no TF agreement on details proposal -- high level disagreement
   (attribute versus element)
   ... need to go back to discussion on list about this; i need to
   discuss with janina what we can do to facillitate consensus in TF

   CS: can't do any more on this until after SXSW

   MS: sounds like most work needs to be done by those opposed to it;
   might want to designate someone to update your proposal and
   ... five minutes over; pick up again next week -- in meantime need
   further discussion on list
   ... anyone who hasn't look at proposal, please do and if something
   original to add, please post to list

   MS: next week Janina will chair


Summary of Action Items

   [NEW] ACTION: Chaals - coordinate concrete proposal for use of
   imagemap in CANVAS [recorded in

   [End of minutes]
Received on Thursday, 25 February 2010 17:33:09 UTC

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