HTML Accessibility Task Force Teleconference

25 Feb 2010


See also: IRC log


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


<trackbot> Date: 25 February 2010

<JF> Morning Michael

GJR joins in steveF's plus 1 to rich's most recent post

<dboudreau> <---- 515.312

<dboudreau> hi hi :)

<scribe> scribe: Gregory_Rosmaita

<scribe> scribenick: oedipus

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: http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0522.html

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: http://www.w3.org/2002/09/wbs/44061/20100225_canvas/results

MS: approach suggest with documented results, look for points-of-agreement
... 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, please;

<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 http://www.w3.org/2010/02/25-html-a11y-minutes.html#action01]

<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 on"
... 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: http://www.w3.org/2002/09/wbs/44061/20100225_summary/results

<cyns> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Details_element_as_a_replacement_for_summary_attribute,_Feb_15,_2010

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

<cyns> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Details_element_as_a_replacement_for_summary_attribute,_Feb_15,_2010

MS: try to see where we have agreement so far

<cyns> http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010

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 education
... clear path from summary attribute to details element with summary child that is completely different form summary attribute text seems dangerous
... 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 specification

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?

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

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


<JF> have a great week all

MS: next week Janina will chair

<dboudreau> take care all

present= IPCaller

Summary of Action Items

[NEW] ACTION: Chaals - coordinate concrete proposal for use of imagemap in CANVAS [recorded in http://www.w3.org/2010/02/25-html-a11y-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/02/25 17:13:12 $

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)

WARNING: Bad s/// command: s/TOPIC: Actions Review/TOPIC: survey results for canvas change proposal: http://www.w3.org/2002/09/wbs/44061/20100225_canvas/results
FAILED: s/syliva/cynthia/
Succeeded: s/won't happen/means adom will be *used* as an accessibility conformance statement/
FAILED: s/MMs: looks/MM: looks/
Succeeded: s/TOPIC: Actions Review/TOPIC: survey results for canvas change proposal/
Succeeded: s/MMS: looks/MM: looks/
Succeeded: s/2 changes that sylvia/2 changes that cynthia/
Succeeded: s/Actions Review/Survey results for CANVAS change proposal/
Found Scribe: Gregory_Rosmaita
Found ScribeNick: oedipus
Default Present: John_Foliot, Stevef, Gregory_Rosmaita, Eric_Carlson, Michael_Cooper, MikeSmith, Rich, Marco_Ranon, +1.514.312.aaaa, Denis_Boudreau, Matt, Cynthia_Shelly, kliehm, Jon_Gunderson, [IPcaller], Wendy, chaals
Present: Cynthia_Shelly Denis_Boudreau Eric_Carlson Gregory_Rosmaita John_Foliot Jon_Gunderson Marco_Ranon Matt Michael_Cooper MikeSmith Rich Stevef Wendy chaals kliehm
Regrets: Laura_Carlson Ben_Caldwell Geoff_Freed Markku_Hakkinen Joshue_O'Connor Kelly_Ford
Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0522.html
Found Date: 25 Feb 2010
Guessing minutes URL: http://www.w3.org/2010/02/25-html-a11y-minutes.html
People with action items: chaals

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]