See also: IRC log
<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
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
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
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
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
<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
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?
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 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
[ADJOURN]
<JF> have a great week all
MS: next week Janina will chair
<dboudreau> take care all
present= IPCaller
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]