W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

07 Apr 2010

Agenda

See also: IRC log

Attendees

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
Chair
Janina_Sajka, Mike_Smith
Scribe
Martin_Kliehm, Marco_Ranon, Joshue, Chaals, MikeSmith

Contents


<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

Media

<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

Drag and Drop

<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

ALT redux

<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?

<oedipus> http://dev.w3.org/html5/spec/syntax.html#an-introduction-to-error-handling-and-strange-cases-in-the-parser

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]

Longdesc redux

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

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc#This_implies_the_following_changes_to_the_spec:

<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

HTML5: Techniques for providing useful text alternatives

<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

<Stevef> http://dev.w3.org/html5/spec/text-level-semantics.html#a-link-or-button-containing-nothing-but-the-image

<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]

Review new bugs

<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]

New stuff... display, focus, labels semantics.

<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

http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML+WG&keywords_type=allwords&keywords=a11ytf+a11y_display

<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]

Summary of Action Items

[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/07 16:01:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

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]