See also: IRC log
<trackbot> Date: 07 April 2010
<janina> Birmingham is now on the conference bridge
<MikeSmith> silvia, you can skype me at sideshowbarker
<Zakim> oedipus, you wanted to ask if we are going to break down the "summary issue" as we did yesterday with longdesc, starting with "attribute versus element" and competing proposals or
<kliehm> scribe: Martin_Kliehm
<kliehm> scribenick: kliehm
<MichaelC> agenda: http://www.w3.org/WAI/PF/HTML/ftf_2010-04
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media
issue 9
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_Sub-Group
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Multimedia_Q%26A
silvia: looking forward to an
agreement on the issues above to move forward, doesn't need to
be final.
... positive signals from browser vendors
janina: we are proposing recommendations at this f2f meeting for the Thursday telcon
<MichaelC> Task Force consensus procedures
<silvia> anyway - don't wait for me - that particular tangent need be discussed at another time
<oedipus> s///
Dick Bultermann: main concern I have is that declarative support for accessibility is lacking while scripting support is more advanced.
<oedipus> http://dev.w3.org/html5/spec/video.html#media-elements
<silvia> Just a side note: this concern is not with the "Multitrack API" but with the "Media Textassociations" document
dick: regarding multitrack most proposals suggest new elements to fix problems, that seems to be a non-sustainable solution.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations#Proposal
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations#File_Formats
dick: the issue is not just what
codecs people need, but also alternative presentation modes for
people with different disabilities.
... There are general solutions like SMIL's content control, or
DAISY that already provide a starting point that needs to be
tailored for the special needs of HTML.
... It's been in IE 5.5 and several versions of DAISY.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
<oedipus> http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0009.html
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/MediaSpecificElements
dick: I sent to some of you a description of the SMIL content control model.
silvia: has seen the first draft
of the document mentioned by Dick. There's a concern that a
single timeline is insufficient.
... Also more concerns we haven't dealt with at this TF. We've
done work on the declarative and JavaScript API. In the
JavaScript API there's just one timetrack, still it's possible
to use different languages.
<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5758
silvia: There is a single timeline and a timing model in HTML that is sufficient for synchronization.
<oedipus> http://dev.w3.org/html5/spec/video.html#time-ranges
<oedipus> http://dev.w3.org/html5/spec/video.html#location-of-the-media-resource
dick: As an example in MPEG4 there are different means to switch certain tracks on and off, but in other codecs those tracks exist in separate files that need to be synchronized.
<oedipus> http://dev.w3.org/html5/spec/webappapis.html#timers
dick: For the moment synchronization is implicit, but we need an explicit model that can be done in very little time.
<silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
silvia: First topic is the media multitrack proposal.
<Sean> silvia we lost audio
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_Sub-Group
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI#Draft_Proposal
<MichaelC> meeting: HTML Accessibility Task Force Face to Face, Day 2
<silvia> maybe I can share the list of topics here
<martin_kliehm> (lost connection)
<martin_kliehm> scribenick: martin_kliehm
<silvia> 1. http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
<silvia> 2. http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations
<silvia> 3. caption file format
<silvia> 4. more general synchronisation of media elements
<kliehm> Dick: several concerns, for example who is the trackmaster, video stream or text file?
<kliehm> scribenick: kliehm
Eric Carlson: I think that granular level of control is beyond the scope of the first implementation.
Dick: We need a perspective for future development.
Janina: When would we get to that level of control? HTML6?
Eric: With the movement we've seen in the last few years I'd be surprised if it took as long as the transition from HTML4 -> HTML5.
<oedipus> http://www.w3.org/TR/ttaf1-dfxp/
<oedipus> TTML 1.0
<oedipus> http://www.w3.org/ns/ttml/
<Zakim> Sean, you wanted to say TTML allows spatial control
Sean asking about TTML spatial control.
<Sean> +1 to getting structure in the discussion
Silvia: audio and video in HTML5 is a given and as a first step we should be trying to make that accessible now.
<oedipus> http://dev.w3.org/html5/spec/video.html#video
Silvia: I believe what Dick suggests can be added on top, but should be addressed in a separate subgroup.
<oedipus> http://dev.w3.org/html5/spec/video.html#audio
<oedipus> http://dev.w3.org/html5/spec/video.html#media-elements
Janina: concern if the spec would be continued to be worked on in that area, Eric confirmed that work will continue. Still we need to discuss the future perspective.
<oedipus> AUDIO and VIDEO lack accessible markup: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5758
Silvia: Dick paints a bigger picture, we need to solve the simple things first. We shouldn't stop to push those ideas forward though, Dick is doing an excellent job driving it forward.
Sean: It would be nice to re-architecture the audio/video model to include accessibility from the beginning, but we wouldn't reach a result. The HTML WG would drop the suggestion in horror.
Eric: Agrees. The current state is the result of work in the last three years. It's very unlikely that the current implementation will be re-shaped in the way Dick proposes.
<oedipus> GJR notes that bug 5758 is datestamped 2008-06-15 (2008-06-15 )
[discussion of lack of response by WG regarding video accessibility suggestions in the last two years]
<oedipus> aurlien levy on video lack of a11y (2007) http://lists.w3.org/Archives/Public/public-html/2007Jul/0136.html
<janina> In a moment. You're next on q
Eric: Start and end time, loops and more was shipped in WebKit but removed by request.
Dick: I will work with Silvia on the Track API if that's the focus at the moment.
<silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
Silvia asking about point of view on JavaScript API
Dick: If somebody pauses the video the timing should be clarified that the video stream is the timing master and the captions are slaves. Also when the video ends but the track is longer, they should stop, too.
[lost conncetion again]
Sean: The role is read only, you're not applying it by JavaScript.
<oedipus> http://webkit.org/
Eric: The JavaScript API supplies script access to caption tracks, whether they are internal or external. Thus custom controls can access different caption tracks.
<oedipus> http://planet.webkit.org/
<oedipus> janina, i will ping Kenny Johar who said he would review the Multitrack API
Janina: Has there been a discussion to standardize API access on controls?
Eric: That is part of the existing JavaScript API.
<oedipus> janina, i am emailing Kenny Johar to review the Media stuff
Silvia, Eric: The default controls are hooked up to the system accessibility APIs so that they are keyboard navigable.
Dick: Concerned that number of attributes are boolean. controls=false === controls=true is confusing. Also you cannot turn controls off.
Eric: boolean attributes are a given, changing them would never fly with the HTML WG.
Silvia: That's been in HTML4 and previous versions, it's a fundamental concept.
[strong agreement we shouldn't try to change this]
<oedipus> agree with sean
Eric: The spec doesn't say
anything about the look and position of the controls.
... For example the placement of captions can be
significant.
<oedipus> -> Dick Bulterman's Initial version of Synchronization issue http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0082.html
<oedipus> http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0082.html
<Joshue> MK: What about the stylability of form controls via CSS or say we have no consensus? They should be stylable.
<Joshue> EC: This is an issue that we shouldn't be concerned with but we may need to escalate it elsewhere.
<janina> qq?
<oedipus> http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/thread.html#msg31
<silvia> 2. http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations
<oedipus> maciej comment: http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0039.html
Silvia: I hear we have an basic agreement on the first proposal (Multitrack API). Dick will email a few clarifications.
<Zakim> MikeSmith, you wanted to point out that bugs should be raised for both of these proposals
Mike Smith: As a first step we should submit bugs for the proposals in Bugzilla.
<Marco_Ranon> 5 minutes to first scheduled break
<oedipus> MikeSmith, would the new bugs complement or subsume bug 5758? (http://www.w3.org/Bugs/Public/show_bug.cgi?id=5758)
<oedipus> MikeSmith, silvia volunteered to file bugs
<eric_carlson> oedipus: I think the new bugs compliment 5758
<silvia> I'll make a reference to that bug
<oedipus> silvia, i talked to Kenny Johar about working on the Media Sub-Group -- his schedule should sync with yours as far as telephone time is concerned
<silvia> where is he located?
<oedipus> victoria
Janina: Perhaps we need a face-2face meeting at TPAC for media.
Silvia, Michael Cooper said yesterday TPAC 2010 will be in Lyon, France.
<silvia> ah, cool!
Silvia: I'd like to reconfirm we can perfectly associate captions, audio transcriptions and external text with audio/video. What we can't do at the moment is that DAISY level of access.
<oedipus> GJR notes that DAISY is interested in ensuring that the next iteration (ZedAI and ZedNext) can be rendered in HTML5-capable browsers
<Sean> To be clear, there is no declarative way of doing DAISY. The JS API would allow it
<oedipus> GJR notes that DAISY is considering/working on a profile for use with HTML5
Janina: Accessible captions are just the beginning, internationalization might also be an issue.
Mike: The TF could ask implementors if DAISY would be an option for the next version. We should have our concern on record and expect improvement.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Multimedia_Q%26A
Eric: Asking implementors is one way, also people who understand accessibility should phrase the requirements.
<oedipus> -> Accessibility Needs (Multimedia Q&A) http://www.w3.org/WAI/PF/HTML/wiki/Multimedia_Q%26A
<oedipus> http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/att-0082/HTML5_Synchronization.html
Dick: I have more fundamental problems with the second proposal, just sent out a draft to the group. There are mutually exclusive concerns that should be addressed.
<Sean> Yes lets do media now while we are all available
Silvia: I could write a response to Dick's concerns.
Dick: I can trim the document down to just the basic concerns.
<MikeSmith> silvia, will you be back on later at all?
<Sean> What is the agenda after the break?
<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2010-04
<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2010-04#agenda
<silvia> if there is more media discussion I can be back
<silvia> but I'd rather spend some time with our friends now
<MikeSmith> next is drag & drop
<Sean> OK. I have to go do some other stuff now.
<silvia> thanks, no need for my presence then :)
<janina> Birmingham paging Oedipus
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute
<oedipus> -> drag and drop in HTML5 http://dev.w3.org/html5/spec/editing.html#dnd
<oedipus> http://dev.w3.org/html5/spec/editing.html#dnd
<oedipus> -> drag and drop events model in HTML5 http://dev.w3.org/html5/spec/editing.html#drag-and-drop-processing-model
<oedipus> http://dev.w3.org/html5/spec/editing.html#drag-and-drop-processing-model
<MichaelC> scribe: Marco_Ranon
RS: currently no guidance on DnD
<oedipus> -> @draggable http://dev.w3.org/html5/spec/editing.html#the-draggable-attribute
<oedipus> http://dev.w3.org/html5/spec/editing.html#the-draggable-attribute
RS: several functionalities for mouse, need to make sure we have keyboard equivalents
<oedipus> -> ARIA drag and drop http://www.w3.org/WAI/PF/aria/states_and_properties#attrs_dragdrop
<oedipus> http://www.w3.org/WAI/PF/aria/states_and_properties#attrs_dragdrop
RS: no time for DnD, maybe Gez can work on this?
<oedipus> HTML5 Section 7.9.1 "To make an element draggable is simple: give the element a draggable attribute, and set an event listener for dragstart that stores the data being dragged."
<oedipus> HTML5 Section 7.9.1 "The event handler typically needs to check that it's not a text selection that is being dragged, and then needs to store data into the DataTransfer object and set the allowed effects (copy, move, link, or some combination)."
SF: current specs is not mouse-centric
RS: need to provide cleare
guidance for keyboard access
... s/cleare/clear
<oedipus> HTML5 section 7.9 "This section defines an event-based drag-and-drop mechanism. This specification does not define exactly what a drag-and-drop operation actually is."
RS: a couple of weeks to review current status, need to write specs ready text
<oedipus> HTML5 7.9 "On media without a pointing device, the user would probably have to explicitly indicate his intention to perform a drag-and-drop operation, stating what he wishes to drag and what he wishes to drop, respectively."
JS: will email Gez
... back to ALT and then longdesc
<oedipus> missing @src and @alt SHOULD be accorded the same priority
<Joshue> +q
JS: laura's change proposal calls for error for missing ALT. my proposal is to leave it as it is, but add a note
SF: document with no @alt shouldn't be conformant
<oedipus> role="presentation" should mark the only exception where @alt is not absolutely needed
quick break for people to check-out
<oedipus> missing @src and missing @alt SHOULD be accorded the same priority stroke error/conformance error
<oedipus> IMG without @src is invalid and unusable
<oedipus> IMG without @alt is invalid and unusable
I'm for error for both @alt and @src
<oedipus> me too
For me the main point with @alt is to refer to WCAG documents in error messages
<oedipus> we are discussing ALT in relation to IMG (and perhaps FIGURE)
<oedipus> there is no control over the content of a <p> </p>
<oedipus> for a stab at a uniform approach to HTML5's media specific elements: http://www.w3.org/WAI/PF/HTML/wiki/MediaSpecificElements
<oedipus> conformance is in the eye of the validator
<oedipus> steve, in your example the alt text for the logo should be the logo (for example, alt="W3C") and a title should be used if one wants to mark the image as a logo
<oedipus> janina, MikeSmith is still in the queue ahead of me
we are all back
<janina> Yes, g
MS: currently specs allow to omit
@alt for IMG
... a warning has more chances to be accepted by the WG than
error
... don't want to have warning for @src
RS: a warning is appropriate
<Zakim> oedipus, you wanted to say that missing @src and missing @alt should be accorded the same priority stroke level of error/conformance reporting
<Joshue> +q
<Zakim> MichaelC, you wanted to say the spec could as easily define behaviour for when src is not present, as just say it must be present; if it did that, we'd have equal treatment
GR: @alt and @src should be on the same level
MC: agree with GR
<Joshue> -q
<Joshue> +q to ask how would a missing src effect UA Heuristics?
MC: html5 wants to define error handling, it could be the same for @src
<oedipus> sean expressed interest in fleshing out and exploring my initial stab at a uniform approach to HTML5's media specific elements: http://www.w3.org/WAI/PF/HTML/wiki/MediaSpecificElements
DB: we should do the same for
VIDEO and other kind of media
... a warning would be OK
<oedipus> the difference in this case is that IMG has to be backwards-compatible - new specific media elements are a different kettle of fish
<Joshue> -q
<Joshue> +q to ask regarding conformance checkers - if they currently throw up no error if no alt is present, and missing source throws up an error are we suggesting upgrading @alt to the equivalent warning/error status?
<oedipus> joshue, i am, at least
SF: people might add dummy ALT just to shut up the validator
RS: could flag a warning and then have a full series of accessibility checks
<oedipus> you can put garbage into any element and into many attributes - the argument is specious
<Zakim> Joshue, you wanted to ask regarding conformance checkers - if they currently throw up no error if no alt is present, and missing source throws up an error are we suggesting
<oedipus> NO, NO, NO!!! we are concerned with ALL developers, not just those who will use an a11y conformance checker
JOC: we would need to upgrade @alt to equivalent to @src
<Joshue> Regarding the behaviour in conformance checkers.
<oedipus> PROPOSED RESOLUTION: @alt and @src in regard to IMG must be accorded equal importance in validation/conformance
MS: changing to a warning would be the way forward to unblock the stalemate on @alt
JS: we agree on the change proposal but not on the behaviour of the validator
<oedipus> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
<oedipus> what meaning does IMG without @src have? none - it is an error
MS: @src shouldn't be a warning
<oedipus> PROPOSED RESOLUTION: @alt and @src in regard to IMG must be accorded equal importance in validation/conformance
<chaals> [-1 but won't block consensus]
<oedipus> obsolete but conforming is an OXYMORON - it makes no logical sense whatsoever
<oedipus> http://dev.w3.org/html5/spec/obsolete.html#obsolete-but-conforming-features
<oedipus> http://dev.w3.org/html5/spec/obsolete.html#warnings-for-obsolete-but-conforming-features
<oedipus> you can't automatically check that hyperlink text is meaningful, either
<oedipus> @alt required unless role="presentation" -- that should be checkable
<oedipus> that's a tool limitation, not something that should drive the spec
<oedipus> the tool should comply to the spec, not the other way around
MS: currently validator libraries don't enumerate missing attributes
5 minutes to lunch break
MS: generating a warning and pointing to a11y guidance should be what we need to do
<oedipus> what about missing @src?
MS: i'm currently working on the validator to improve output
<oedipus> warning is a yield sign; error is a stop sign, symbollically speaking
MS: we could have a 'conforming with warning' class
<Joshue> If there was more context aware error recovery/advise from the conformance checker then we would be closer to conformance == a11y.
JS: can we change to error to warning?
GR: still want equivalent level for @alt and @src
<MikeSmith> http://dev.w3.org/html5/spec/obsolete.html#obsolete
<oedipus> http://dev.w3.org/html5/spec/obsolete.html#warnings-for-obsolete-but-conforming-features
<oedipus> http://dev.w3.org/html5/spec/obsolete.html#obsolete-but-conforming-features
<oedipus> obsolete but conforming is an oxymoron
<MikeSmith> current non-normative statement in spec: For example, a validator could report some pages as "Valid HTML" and others as "Valid HTML with warnings".
<oedipus> how can any page be valid without warnings? if the argument is that @alt shouldn't be an error because the content of @alt can be fudged, so, too can many other attributes and containers which produce "Valid" garbage
JS: are we OK with warning plus label such documents as valid with warning (or a better phrase)?
<oedipus> GJR votes for equal status for @src and @alt in regards to IMG
<oedipus> PROPOSED RESOLUTION: @alt and @src in regard to IMG must be accorded equal importance in validation/conformance
<MikeSmith> .me notes Janina's citation of the phrase "progress not perfection"
<richardschwerdtfe> Proposal: Modify Laura's change proposal to have the conformance checker normatively emit a warning as opposed to an error. This warning must refer to the appropriate WCAG document and section that provides remedial guidance to the author.
<oedipus> no, unless @src is accorded the same treatment as @alt
<oedipus> either or
<richardschwerdtfe> +1
<Stevef> +1
<kliehm> +1
<eric_carlson> +1
<Joshue> +1
<MikeSmith> MikeSmith: +1
<MichaelC> +1
+1 (although not in my ideal world)
<janina> +1
<chaals> +1
<MichaelC> +1 for Dick
<oedipus> minus 1
RESOLUTION: Modify Laura's change proposal to have the conformance checker normatively emit a warning as opposed to an error. This warning must refer to the appropriate WCAG document and section that provides remedial guidance to the author.
<oedipus> The optimist thinks that this is the best of all possible worlds; the pessimist knows it is.
Note: this a resolution that the majority of the people can leave with but not prefer
yes
<kliehm> s/live/leave/
<cyns> I'm getting a message that the #2119 passcode is not valid.
<cyns> ok. thanks.
<Laura> WAI CG consensus document had absolutely no reference to "warnings". We discussed that point ad nausium. The WAI CG consensus document is all about what is valid period.
<Laura> It says and I quote,
<Laura> <img> is only valid when at least one of the following is true:
<Laura> * @alt is present (empty or non-empty) OR
<Laura> * @aria-labelledby is present (non-empty only) OR
<Laura> * the <img> is located within a <figure> that has a non-empty <figcaption> OR
<Laura> * @role="presentation"
<Laura> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
<Laura> If the task force rejects the WAI CG consensus recommmendation, we
<Laura> should do back to WAI CG and have further deliberations with them.
<Laura> If the task force rejects the WAI CG consensus recommmendation, we
<Laura> should go back to WAI CG and have further deliberations with them.
<Laura> good idea. how long is the break?
<Laura> okay
<Laura> The change proposal now says exactly what WAI CG recommended: http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#With_Suggested_Text
<Laura> okay thanks
<Laura> +1
<cyns> Zakim IP caller is me
<oedipus> plus 1 (but i think laura is going to have to repropose it when we resume)
<Laura> yes
<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2010-04#agenda
<oedipus> "Modify Laura's change proposal to have the conformance checker normatively emit a warning as opposed to an error. This warning must refer to the appropriate WCAG document and section that provides remedial guidance to the author."
<Laura> WAI CG consensus document had absolutely no reference to "warnings". We discussed that point ad nausium. The WAI CG consensus document is all about what is valid period.
<oedipus> Note: this a resolution that the majority of the people can leave with but not prefer
<Laura> It says and I quote,
<Laura> <img> is only valid when at least one of the following is true:
<Laura> * @alt is present (empty or non-empty) OR
<Laura> * @aria-labelledby is present (non-empty only) OR
<Laura> * the <img> is located within a <figure> that has a non-empty <figcaption> OR
<Laura> * @role="presentation"
<Laura> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
<Laura> If the task force rejects the WAI CG consensus recommmendation, we
<Laura> should go back to WAI CG and have further deliberations with them.
<oedipus> cyns, http://www.w3.org/2010/04/07-html-a11y-minutes.html#item03
<inserted> Scribenick: oedipus
consensus with caveat
"Note: this a resolution that the majority of the people can leave with but not prefer" from minutes
[LC and CS express concern over ALT agreement to be taken to TF in general]
JS: this meeting makes recommendations to TF; TF has to approve before moved to HTML WG
MC: noted in minutes that there were reservations
CS: oppose statement that this meeting agrees with this
MC: take to wider TF without rehashing same discussion?
JS: don't know if we can part of my concern this morning
MC: hear what you are saying - there will be opportunity to discuss
CS: don't want to block progress, but this worries me a lot
JS: a lot of concern; my mind came down to progress, not perfection -- quantify remaining inequality
CS: can live with it if give @src equal treatment
JS: MS, can we talk about this for a minute
MS: yes
JS: Dick, slippery slope argument
i/scribenick: oedipus/LC and CS
JS: why missing @alt and @src equality not practical
DB: at very abstract level, i
might agree, but at practical level don't
... have fundamental concerns
... concerns discussion too linked to IMG - conversation needs
to be on higher ground - spending a lot of time on error or
warning is moot because at semantic level where need to make
diff not going to help at all
... example of bad programming
... useless info -- effort should go into helping how to help
people do things better, organize business case
LC: i've seen it work; i use it
in my work
... to students a warning or an error makes a BIG
difference
CS: makes big difference to programmers as well
DB: warning already sends signal
LC: can turn off warnings
DB: agree on abstract level -
when designed SMIL required @alt otherwise XML error and doc
wouldn't render - result was people ignoring what is moral
enforcement issue
... laudable goal, but for practical purpose, no
inforcement
... equating @alt to @src is a WHOLE different aqrgument, and
don't think much of a leg for that argument to stand on - @alt
triggering category-A warning is not the way to go
MC: don't know WAI CG feeling
LC: had consensus a year ago
JS: prior to the TF PF had a Caucus on HTML
LC: worked for it on months
DB: would rather put eneregy into ensuring @alt on all media -- would be bigger win than matter of principle
CS: not matter of principle, but practicallity -- have had multiple cases where statement "is not valid HTML" ends argument -
DB: understand, but whole different issue than saying @alt and @src should be treated equally
CS: if no @src have broken image, if don't have @alt have broken image
DB: not always true
<Joshue> There are implications as this issues crosses other domains, not just IMG.
<MikeSmith> a?
<MikeSmith> q*
DB: just because an element is schenduled, there can be side effects to document if no @src - not with HTML5 unfortunately
CS: prefer both errors; could live with warning if @src was warning as well; more accurate to say is an error
<Laura> +1 cyns
JS: what else is warning and not error?
CS: things that are equivalent - other attributes if missing tag are broken
if don't provide HREF for a link that is an error
MS: captioning example is a judgement call - grey area in which some reasonable people might take position that this is case that could be classed as judgement call
CS: please explain
... captions aren't judgement call, but whether captions are
available cannot be determined by markup validation
<richardschwerdtfe> mike who?
MS: strongly advise against going to HTML WG with proposal to make @src a warning is practiaclly speaking effect will be to further polemicize discussion
CS: that's fair -- but then should not be saying @alt is a warning
MS: 2 separate things
CS: can live with it if treated same, prefer if both errors
plus 1 to CS
GJR wanted to say that the request is that they be treated equally, whether warning or error, with preference for error
LC: read minutes and still can't understand decision
MC: trying to get out of deadlock - a lot on agenda
GJR moves to move on to next agendum
CMN: this is point of contention
- some in a11y community can live with this, some strongly
object -- all 14 of us isn't a representative group -- perhaps
time to throw proposal up on the wall
... in end, only request to change HTML5 document, not a final
decision of the HTML WG
[MC and CMN discuss process]
CMN: everyone would like it to be an error, many can live with it if warning
MC: seems that whatever we send forward there will be objections, and we will log them as we move forward
MS: once goes to wider HTML WG will likely be formal objections to what the TF suggests
MC: created TF so could get general consensus on issues and take them to HTML WG
JS: what is the bottom line that PFWG can accept
CS: possible way forward is to take this back to WAI CG as Laura suggested
JS: can re-constitute that -- not opposed to that -- said this morning need discussion inside of WAI and not just PF
CS: would like to get wider position for WAI
MC: quantifying equality
... did our best to come up with something acceptable for WG
and accepted a level of inequality and WG should know that
s/equality/inequality
<chaals> [Actually, I note that I actually consider there is some merit in the case that a warning is *better* for its effect in not promoting dummy alt text. But then, I figure a warning is another flavour of error, too]
<Joshue> Scribe: Joshue
Chaals: Well, are we going to
fight the HTML group for longdesc?
... We are not going to change ARIA 1.0, so we could go to HTML
and say give us longdesc or not.
<oedipus> http://www.w3.org/html/wg/wiki/LongdescRetention
Chaals: We can say that we want @longdesc reinstated to complete issue 30, or drop it etc.
CS: Should we discuss this in isolation or go through our other items and rank them.
<oedipus> http://www.w3.org/html/wg/tracker/issues/30
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
<oedipus> http://www.w3.org/html/wg/wiki/LongdescRetention
CS: I will fight for @alt but not
this.
... We can't consider this item in isolation.
JS: How much work is left on this, and it is not contraversial and we get a resolution etc are we done?
CS: There could be flamewars etc.
Chaals: We could decide to go down that road, it may have less overhead.
<general agreement>
Chaals: This is about whether we want it in the spec.
CS: Well, if we don't do this on
the list etc but arguing about it is not effective.
... We can't just throw it over and not discuss it.
JS: Yes, but we cannot control
what individuals will do.
... We can control what the group will do.
CS: I mean, five minutes spent on this is five minutes too long.
Chaals: I have spend very little
time on this.
... I won't give much time to this in the future, I can accept
the conforming with a warning idea (Maciej) and explain/clarigy
on list.
CS: You also have <canvas> etc.
Chaals: Yup
<general joviality>
CS: Complete the <canvas> image map, that is your priority.
JS: We don't disagree.
... The other option is that we say nothing.
CS: I am fine saying that we accept Maciejs proposal.
JS: If we are ok with it, then we don't have to say anything.
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
CS: I don't think we should open up to discuss this on the list.
JS: The point is that these issues are hashed out by the group.
<chaals> s/discuss this/discuss this much/
<oedipus> obsolete but conforming is a term that makes orwell spin at warp speed in his grave
s/CS: I don't think we should open up to discuss this on the list./
CS: I am concerned that there is other stuff that needs to be done.
JS: We should just talk about the
issues and make out recommendations etc
... We have been discussing this, prioritisation/management
etc.
... We do need to check out things and move on.
<oedipus> s/CS: I don't think we should open up to discuss this on the list.//
CS: If we can resolve @longdesc without an overlong discussion then fine.
RS: You have to approach these things appropriately.
Yes, +1 to Cyns as we went around the houses ad nauseum with @summary
RS: We need to just agree a way forward etc and let the process do its thing.
MS: So what action does the TF need to decide today?
<cyns> Just to make my point clear, we need to message that we will spend 'x' hours on this and no more. We'll submit the proposal and follow the process. If this becomes controversial, we will not get back to the item for some time, as we need to work on other issues more urgently.
<oedipus> preview of longdesc flame wars: http://www.w3.org/html/wg/wiki/LongdescRetention
RS: I am not a big fan of @longdesc (for reasons already stated). We don't have this functionality in ARIA today, and until we do we need a bridge in the meantime, so we need a form in @longdesc until we have an ARIA 2 equivalent.
JS: Is there an issue?
RS: We didn't agree that we want to deprecate @longdesc?
MS: We did but it wasn't explicitly ARIA.
GJR: We did say in 2007 that we prefer native solutions.
JS: Lets test, do we have concensus?
<oedipus> are we talking about: http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc
<oedipus> or http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
RS: Was the proposal going to state that it was deprecated?
Chaals: <gives an overview of Maciejs proposal>
<Stevef> emails to public html about @summary 2700 approx , emails to public html about longdesc 1000 approx
<Zakim> oedipus, you wanted to ask which proposal we are currently discussing
<MikeSmith> http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
JS: Lets test concensus on Maciejs proposal.
<MikeSmith> Maciej's "Longdesc Conforming With Warning" proposal
JS: Any objection?
<cyns> this looks good to me
<oedipus> maciej: "Most of the time, when an author chooses to use longdesc, it would be valuable to encourage her to consider aria-describedby instead. It would be a positive benefit if the validator could do that encouragement. However, it would be unfortunate if in the process we harmed the few who were validly relying on longdesc and made good use of it."
<oedipus> maciej: "We can strike a balance by making longdesc conforming, but requiring it to trigger a validator warning. That way, sites that use it won't have to be changed right away. But authors using it will be warned of the common mistakes in using longdesc, and encouraged to use the superior aria-describeby mechanism."
<Laura> I have to go. Will try to get call back later.
CS: Accepting the proposal is fine with me.
<Laura> Thank you, Gregory. Bye.
MS: Any objections?
<oedipus> lukewarm objection
<oedipus> GJR prefers chaals' over maciej
GJR: I would prefer Chaals
MC: Me 2
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc
Chaals: Don't fire the warning etc
RS: I am happier with this.
CS: I dont want to spend time supporting it.
<oedipus> chaals: "This has been a controversial topic. It is clear that longdesc is relevant only to a fraction of images on the Web, and that it is only provided in a few of the cases where it is actually relevant. It is also clearly subject to bogus values to a large extent (perhaps the majority of the time). And its use is relatively limited, even by those who might be expected to appreciate it."
<oedipus> chaals: "However, it has been implemented multiple times successfully. The fact that there is bad data associated might account for low overall usage, but has relatively little impact on implementations, which can readily choose to simply ignore values which are not URIs, or even to present the value to the user, and relatively little impact on the user, who can still benefit from a *good* usage."
MS: There will be arguments and we will have to choose to respond.
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc
CS: A part of my objection on alt is that there are many other minor warnings that I don't consider @alt a part of.
<richardschwerdtfe> da da da da
<chaals> Proposed Resolution: This group recommends that ISSUE-30 be resolved by adopting the Change proposal to restore longdesc. Rather than waste a lot of time in discussion, the group is prepared to accept the alternative proposal to make longdesc produce a warning (which implies agreeing on a reasonable warning)
<chaals> s/waste/spend/
<richardschwerdtfe> ya ya'
<cyns> Proposed resolution: While the group prefers the proposal that restores longdesc, we are prepared to accept the alternative proposal to produce a warning (assuming we can agree to warning text)
<chaals> [the resolution doesn't change any of yesterday's agreed points, which should be reflected in the change proposal]
<cyns> While the group prefers the proposal that restores longdesc, we are prepared to accept the alternative proposal to produce a warning (assuming we can agree to warning text)
<chaals> Proposed RESOLUTION: While the group prefers the proposal that restores longdesc without warning we are prepared to accept the alternative proposal to produce a warning (assuming we can agree to warning text)
<cyns> and add links to the 2 proposals
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc
<oedipus> or http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
<discussion and fine tuning>
<MikeSmithX> alternate PIN: 583503
<chaals-> RESOLUTION: While the group prefers the proposal that restores longdesc without warning we are prepared to accept the alternative proposal to produce a warning (assuming we can agree to warning text)
<chaals> Scribe: Chaals
<MikeSmith> http://dev.w3.org/html5/alt-techniques/
<Stevef> change proposal split out and modify parts of Section 4.8.2.1 the img element http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209
MS: Document that SteveF has been working on for a while.
SF: To do with proposals about what to do with alternative text - relates to the current HTML5 draft
<MikeSmith> abstract: "This document contains author conformance requirements for use of the alt attribute in HTML5 and best practice guidance for authors of HTML documents on providing text alternatives for images.
<MikeSmith> abstract: "This document contains author conformance requirements for use of the alt attribute in HTML5 and best practice guidance for authors of HTML documents on providing text alternatives for images"
SF: There are a whole bunch of
examples about how to provide an appropriate alt value.
... a bunch of people have tried to get changes to the spec,
but the cost of getting changes made was too high.
... there was also an idea that we should just move the author
conformance stuff out of the main doc. I could live with it in,
but I think it is better out on its own as guidance for
developers.
... There was still a lot that people disagreed with in this
section of the spec.
... I think we should be giving people guidance - but we have
to recognise that "Best Practise" isn't completely agreed. E.g.
should a company logo have a text alternative that includes the
word "logo"?
<oedipus> indicate a logo either through @title or @role (role="logo")
SF: I don't think it should, but nor should a text alternative that does be non-conforming.
<oedipus> <img alt="W3C" title="W3C logo" role="logo" src="w3c.png">
SF: Tried to cover all the use
cases in the current draft.
... Also trying to provide information about how to associate
text alternatives.
... And trying to make it reasonably reader-friendly.
... Each example discusses benefits and drawbacks, with
reference to what actually works today.
<Zakim> cyns, you wanted to say that I strongly agree with the idea of moving this text out fo the spec. Will this be submitted to WCAG as HTML5 techniques?
CS: I like the document. Strongly agree with moving it out of the main spec. Are you planning to submit this to WCAG as HTML5 techniques?
SF: Yes. The document this came out of originally was submitted already a year ago, but they haven't reappeared yet. So I don't think that's the high priority - would rather complete the document first, and ask for it to be published as an HTML WG document.
CS: Agree that getting this done first makes sense. Think it is odd that this lives in HTML not WCAG.
SF: Likely to be easier to get support from HTML.
JS: But risks scattering advice from different domains.
SF: About providing text alternatives in general - not just accessibility.
RS: Where would you go to find how to meet accessibility requirements? HTML or WCAG?
MC: There is no reason W3C can't provide the resources that encompass the various use cases.
RS: Will this be in WCAG format?
SF: Happy to provide each case as a technique...
RS: Don't want you to write it twice in two different formats
<oedipus> <p><img src="shalott.jpeg" alt=""></p> should be <p><img src="shalott.jpeg" alt="" role="presentation"></p>
MC: WCAG techniques are stored in a special XML format.
<Joshue> Chaals: Submit them all as techniques.
<Joshue> Chaals: Its good to publish these as HTML.
<oedipus> CMN: submit them all as individual techs; good to publish as part of HTML; good to have wcag group review them; submit each tech to wcag
<oedipus> RS: look at WCAG first
<oedipus> CMN: if interested in writing HTML docs, look in HTML doc suite
<oedipus> SF: advantage of having directly in the spec
EC/CMN: It's good to have stuff in HTML so people look at it, before pushing them to go to look at WCAG.
SF: Ian claims people won't follow links in order to learn more
[CMN thinks that is true, but mostly because they will never read the HTML5 spec in the first place]
<oedipus> [plus 1 to CMN's rumination]
MK: There is the H:TML document which provides techniques for authors
MS: It's not really authoring techniques, it's a reference
SF: Lachy was working on an authoring guidance document, but no progress.
MK: Such guidance would belong in that document, but not in the spec.
MS: I don't think a functional specification for implementors should also include how-to information for authors.
<oedipus> http://dev.w3.org/html5/html-author/
<oedipus> -> HTML Authoring Techs last updated 23 March 2009 http://dev.w3.org/html5/html-author/
MS: There is a sweet spot about how much guidance to provide, and the HTML 5 spec goes beyond a reasonable expectation of what should be there.
<kliehm> http://dev.w3.org/html5/markup/
MS: It is not the best place to put the information. And if the spec says one thing and others say different things elsewhere we get problems to resolve.
RS: We didn't want to have the guidance in the same spec as the language in ARIA. I am all for taking it out of the HTML5 spec.
<Zakim> MichaelC, you wanted to say what gets published where is something the WAI CG will want to discuss
MS: I think it makes sense for SteveF to maintain this in the HTML5 area.
MC: Think WAI-CG will have an interest in where these things go. I don't see why they can't be a co-publication, but I don't think we should get stuck on where it should be.
<richardschwerdtfe> prosody mike :-)
MS: Sam Ruby in particular has
been encouraging people to step up and edit stuff. Providing
this document will facilitate showing that we are serious about
doing that.
... and hopefully it will help encourage others to write these
kinds of documents too.
<Zakim> cyns, you wanted to say if it's going to be a big issue to move it to WCAG entirely, it's ok to maintain this doc, as long as these techniques eventually find their way into WCAG
CS: Think that so long as this stuff is available from both HTML and WCAG I am fine with it.
<oedipus> http://dev.w3.org/html5/alt-techniques/#conformance
SF: I added conformance
requirements, so that this document can be normative. But I
would prefer not to have them, and that the spec got cleaned
up, including removing problematic conformance requirements
from the spec.
... Ian has submitted bugs on this document, which has helped
to clarify and resolve stuff.
<oedipus> steveF, nice job on http://dev.w3.org/html5/alt-techniques/#captcha
MS: Summary - people think this is useful, there is no apparent objection to continuing it where it is for now.
SF: It is a document for people to look at. Development is based on consensus.
MS: This and other HTML docs are all in the group's bug tracking system
SF: Feedback welcome...
<scribe> ACTION: Steve to post notice to a11y TF about http://dev.w3.org/html5/alt-techniques/ and how to make comments [recorded in http://www.w3.org/2010/04/07-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-25 - Post notice to a11y TF about http://dev.w3.org/html5/alt-techniques/ and how to make comments [on Steve Faulkner - due 2010-04-14].
<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2010-04#agenda
[Rich, Steve leave the meeting]
<MikeSmith> http://lists.w3.org/Archives/Public/public-html/2010Apr/0072.html
<MikeSmith> Removal of other semantic elements
<MikeSmith> http://lists.w3.org/Archives/Public/public-html/2010Apr/0189.html
<MikeSmith> new semantic elements/attributes) - Chairs Solicit Alternate Proposals or Counter-Proposals
<MikeSmith> ISSUE-90, ISSUE-91, ISSUE-93, ISSUE-95, ISSUE-96, ISSSUE-97
MC: Wasn't there a proposal to submit a no-change proposal?
EC: Someone has volunteered to do that
MC: Don't see where our interest is here.
<oedipus> http://dev.w3.org/html5/spec/semantics.html#the-figure-element
<oedipus> http://dev.w3.org/html5/spec/semantics.html#the-figcaption-element
MS: I don't think figure in the
spec has any particular browser behaviour. It's a landmark that
is useful.
... there was a lot of argument about the content model.
Shelley said it should be just images, but people suggested
that almost anything could be a figure.
... People want the language to be descriptive not
prescriptive.
<oedipus> http://dev.w3.org/html5/spec/semantics.html#the-aside-element
MS: Not sure there is browser behaviour associated - maybe on certain types of devices but UA isn't expected to do anything with it.
<oedipus> aside def: "The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography."
<oedipus> aside def: "The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page."
MS: but details has specific behaviour associated.
<oedipus> http://dev.w3.org/html5/spec/interactive-elements.html#the-details-element
MS: progress and meter have behaviour associated too.
<oedipus> http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-progress-element-0
<oedipus> http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-meter-element-0
MC: Shelley wants to remove figure because it is confusing
<MichaelC> Remove figure proposal
<Zakim> cyns, you wanted to say that details makes a control for a behavior that is frequently done in script
<oedipus> aside is WAY to vague a catch-all
CS: Agree figure and nav have
different behaviour. In general I am in favour of more
semantically rich tags.
... details, progress, meter are UI controls.
... what details does is frequently done (badly and
inaccessibly) in script. Having native elements for these is,
IMHO, a huge win.
JS: And specifically useful for accessibility
CS: Yes, because authors often roll their own without getting teh accessibility right, and it is expensive.
<oedipus> http://dev.w3.org/html5/spec/semantics.html#the-figcaption-element
<Sean> +??P6 is Sean
CMN: Figure associates stuff. In general, semantic ellements that have no behaviour aren't used well (HTML is full of examples) but more semantic elements that do have behaviour are useful
<oedipus> ISSUE-90, ISSUE-91, ISSUE-93, ISSUE-95, ISSUE-96, ISSSUE-97
Proposed RESOLUTION: The TF opposes the change proposals to remove the elements listed above.
MS: Please spend the time now to
read the proposal if you haven't done so.
... (before we resolve anything)
<oedipus> based upon the currently available information...
http://www.w3.org/html/wg/wiki/ChangeProposals/removefigure
http://www.w3.org/html/wg/wiki/ChangeProposals/removeaside
http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails
http://www.w3.org/html/wg/wiki/ChangeProposals/removehidden
http://www.w3.org/html/wg/wiki/ChangeProposals/removeprogress
http://www.w3.org/html/wg/wiki/ChangeProposals/removemeter
s/listed above/listed below/
<oedipus> recurring theme "The details element, and other like it, such as progress, are the wrong direction for the W3C to take, and for the HTML WG to pursue. WAI-ARIA is to accessiblity, as behavior is to JavaScript, as CSS is to style, as RDFa/Microformats/Microdata is to semantics, as HTML is to page structure"
CS: The thrust is that figure and aside are typesetting conventions not used in the web. I disagree - browsers on small screens can use these to linearise helpfully, and think that is valuable.
MS: Think the proposals for aside and figure are similar. I think the native semantics for these are better than annotation+style+ARIA
<oedipus> plus 1
CS: Magnifiers have a valid use case for changing layout based on the semantics.
MS: Shelley claims details is trivial to do in Javascript.
CS: It isn't trivial
MS: Indeed. A native implementation will be much better than a huge collection of different scripts that sort of do it (or even do it reasonably well)
CS: There are things without
elements, like accordions - I'd like to see elements for those
too, rather than removing this one.
... from an interaction design perspective she might have a
point that these are similar.
... Not so strong on keeping the hidden attribute
<oedipus> sean has comment re: figure and figcaption
<Zakim> cyns, you wanted to say that i expect the landmark elements will eventually have browser behavior, particularly on small-screen devices
<Zakim> Sean, you wanted to say if we want the figure to be equivalent to aria-labelledby we would need figcaption to be available outside <figure>
SH: complete equivalence between figure and aria-labelledby would require the figcaption can go anywhere and have a pointer to the caption
MS: Docbook does that.
JO'C: Having the close association is useful for AT where the element isn't actually supported.
<oedipus> http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute
CMN: Hidden does what the ARIA equivalent does, and seems useful to me.
<oedipus> "All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified."
<MikeSmith> http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute
CMN: I think it is a good thing, although I could live without it given we will get it in aria.
CS: [says about the same]
<oedipus> "The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if someth
<oedipus> key point: " if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers"
<oedipus> note: "Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes."
EC: It's like display:none but without the nasty side effects.
MC: It is slightly different from aria-hidden...
<oedipus> remember HTML5 hidden applies to ALL elements
JS: Not sure this has an accessibility impact...
CS: There is some impact (but not a lot).
<oedipus> http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-progress-element-0
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/removeprogress
MS: One of the core arguments about progress is whether it improves accessibility.
<oedipus> this is ISSUE 96
[The same arguments are repeated - people want the native semantics]
JO'C: Ditto meter...
<oedipus> http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-meter-element-0
<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/removemeter
<oedipus> "From an accessibility perspective, using the progress element isn't simpler than the ARIA values. The min and max values, whether ARIA or progress element, are statically assigned in the associated element, and the current value is updated based on the progress of the element. What does differ is that the progress element does have a visual indicator that is automatically updated. Unfortunately, though, it's a visual indicator we have no control over. Wh
SH: For the progress element, there are things that don't work as well as the aria approach
CS: Yes, but sit should be improved, not removed.
MK: Not convinced any of these
new elements will be used widely. They may end up unloved like
kbd, but they are useful and I wouldn't remove them.
... Shouldn't it be noted that the hidden attribute is
read-only?
MC: Sure.
CS: So we have some bugs to file on these elements, but we don't want them to be removed.
Proposed RESOLUTION: The TF opposes the change proposals to remove the elements listed above. We maintain the work item to check them and make them good.
s/good/better/
<oedipus> plus 1
<oedipus> to ensure that they are in harmony
<janina> +1
<janina> Chocalate is best
s/better/better harmonised with ARIA semantics/
<cyns> +1
<oedipus> plus 1 to resolution, plus 1000 to chocolate
RESOLUTION: The TF opposes the change proposals to remove the elements listed above. We maintain the work item to check them and make them good.
<MichaelC> s/good/better/
s/opposes/proposes to oppose/
<MichaelC> s/better/better harmonized with ARIA semantics/
["proposes to oppose" subject to what the TF agrees following its process]
<MikeSmith> scribe: MikeSmith
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Display
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Focus
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Labels
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Semantics
MichaelC: look through the bugzilla bug lists for each of these
<oedipus> with sound events, there needs to be sharing of audio device - many software synths allow WAV files, for example, whilst simultaneously processing speech
<cyns> irc crashed on me. url of bug?
<chaals> [chaals leaves meeting]
<oedipus> -> a11y tagged bugs http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML+WG&keywords_type=allwords&keywords=a11ytf+a11y_display
MichaelC: these are issues that were raised as a result of PF discussion
janina: I expect we will bring a good number of them forward, if not all
MichaelC: I think we need a
person to go through these and sort them out.. and maybe that's
me
... what I can do is figure our where they originated from
<cyns> have to step out for 15 minutes
MichaelC: after I check on who
originated them, I can then make a personal recommendation to
the TF on what actions, if any, to take for each
... even if we assign these to people, we are then left to also
figure out how to get people to carry through on the
work
<MichaelC> ACTION: cooper to review bugs for display, focus, labels, and semantics to 1) find originator, 2) propose disposition (work on, leave as is, push back on current status), 3) assign work items to people (possible originators) [recorded in http://www.w3.org/2010/04/07-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-26 - Review bugs for display, focus, labels, and semantics to 1) find originator, 2) propose disposition (work on, leave as is, push back on current status), 3) assign work items to people (possible originators) [on Michael Cooper - due 2010-04-14].
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Work_Topics
<cyns> back now
<oedipus> FYI http://www.w3.org/html/wg/wiki/AsideHeaderFooterDoubts
<kliehm> logging out to fetch my train to airport
<oedipus> note longdesc for IFRAME is eliminated
<kliehm> s/fetch/catch/
<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8747
<oedipus> -> semantics bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=8747
<Marco_Ranon> for Gez? http://www.w3.org/Bugs/Public/show_bug.cgi?id=7721
<MichaelC> action-26: Also Drag & Drop - Gez being asked to take on 7721
<trackbot> ACTION-26 Review bugs for display, focus, labels, and semantics to 1) find originator, 2) propose disposition (work on, leave as is, push back on current status), 3) assign work items to people (possible originators) notes added
<oedipus> thanks to RNIB and all facillitators
<oedipus> happy trails, y'all
<cyns> talk to you all next week
indeed, much thanks to RNIB and to Sally for excellent hosting arrangements
[adjourned]
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) Succeeded: s/ok, thanks// Succeeded: s/I've dropped out// FAILED: s/Mike is caling you back// Succeeded: s/Mike is caling you back// Succeeded: s/Mike is calling you back// Succeeded: s/thinks/things/ Succeeded: s/as/ask/ Succeeded: s/@alt/@src/ Succeeded: s/cjhecks/checks/ Succeeded: s/duke// FAILED: s/live/leave/ Succeeded: s/RESOLUTION: Adopt Laura's change proposal in full. It is the same as WAI CG// FAILED: i/scribenick: oedipus/LC and CS FAILED: s/equality/inequality/ Succeeded: s/etc/or say we have no consensus/ FAILED: s/discuss this/discuss this much/ FAILED: s/CS: I don't think we should open up to discuss this on the list.// Succeeded: i/consensus with caveat/Scribenick: oedipus FAILED: s/CS: I don't think we should open up to discuss this on the list.// FAILED: s/waste/spend/ FAILED: s/listed above/listed below/ FAILED: s/good/better/ FAILED: s/better/better harmonised with ARIA semantics/ FAILED: s/good/better/ FAILED: s/opposes/proposes to oppose/ FAILED: s/better/better harmonized with ARIA semantics/ FAILED: s/fetch/catch/ Found Scribe: Martin_Kliehm Found ScribeNick: kliehm Found ScribeNick: martin_kliehm WARNING: No scribe lines found matching ScribeNick pattern: <martin_kliehm> ... Found ScribeNick: kliehm Found Scribe: Marco_Ranon Inferring ScribeNick: Marco_Ranon Found ScribeNick: oedipus Found Scribe: Joshue Inferring ScribeNick: Joshue Found Scribe: Chaals Inferring ScribeNick: chaals Found Scribe: MikeSmith Inferring ScribeNick: MikeSmith Scribes: Martin_Kliehm, Marco_Ranon, Joshue, Chaals, MikeSmith ScribeNicks: kliehm, martin_kliehm, Marco_Ranon, oedipus, Joshue, chaals, MikeSmith WARNING: Replacing list of attendees. Old list: Gregory_Rosmaita Mike_Smith Michael_Cooper Dick_Bulterman Joshue_O'Connor Janina_Sajka Rich_Schwerdtfeger Martin_Kliehm Eric_Carlson Marco_Ranon Steve_Faulkner Sean_Hayes Silvia_Pfeiffer Charles_McCathieNevile New list: Laura Default Present: Laura, cyns, Gregory_Rosmaita, Mike_Smith, Charles_McCathieNevile, Michael_Cooper, Dick_Bulterman, Joshue_O'Connor, Janina_Sajka, Rich_Schwerdtfeger, Martin_Kliehm, Eric_Carlson, Steve_Faulkner, Marco_Ranon Present: Laura cyns Gregory_Rosmaita Mike_Smith Charles_McCathieNevile Michael_Cooper Dick_Bulterman Joshue_O'Connor Janina_Sajka Rich_Schwerdtfeger Martin_Kliehm Eric_Carlson Steve_Faulkner Marco_Ranon Sean_Hayes Regrets: Sally_Cain Agenda: http://www.w3.org/WAI/PF/HTML/ftf_2010-04 Found Date: 07 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/07-html-a11y-minutes.html People with action items: cooper steve[End of scribe.perl diagnostic output]