- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 25 Feb 2010 17:32:41 +0000
- To: public-html-a11y@w3.org
aloha!
minutes from the 25 February 2010 HTML Accessibility Task Force
Teleconference are available as hypertext at:
http://www.w3.org/2010/02/25-html-a11y-minutes.html
as an IRC log at:
http://www.w3.org/2010/02/25-html-a11y-irc
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
comments...
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
Agenda:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0522.html
See also: IRC log [http://www.w3.org/2010/02/25-html-a11y-irc]
Attendees
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
Chair
Mike_Smith
Scribe
Gregory_Rosmaita
Contents
* Topics
1. Introductory Stuff
2. MultitrackAPI Proposal
3. TextAssociations proposal
4. Survey results for CANVAS change proposal
5. results for summary-details change proposal:
http://www.w3.org/2002/09/wbs/44061/20100225_summary/results
* 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:
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_replaceme
nt_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_replaceme
nt_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_fo
r_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?
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
MS: next week Janina will chair
[ADJOURN]
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]
_________________________________________________________________
Received on Thursday, 25 February 2010 17:33:09 UTC