15:48:22 <RRSAgent> RRSAgent has joined #html-a11y
15:48:22 <RRSAgent> logging to http://www.w3.org/2011/03/19-html-a11y-irc
15:48:24 <trackbot> RRSAgent, make logs world
15:48:24 <Zakim> Zakim has joined #html-a11y
15:48:26 <trackbot> Zakim, this will be 2119
15:48:26 <Zakim> ok, trackbot; I see WAI_(A11YF2F)11:30AM scheduled to start 18 minutes ago
15:48:27 <trackbot> Meeting: HTML Accessibility Task Force Teleconference
15:48:27 <trackbot> Date: 19 March 2011
15:49:18 <dboudreau> dboudreau has joined #html-a11y
15:49:37 <MichaelC> rrsagent, do not start a new log
15:50:03 <Zakim> WAI_(A11YF2F)11:30AM has now started
15:50:10 <Zakim> +Gregory_Rosmaita
15:50:23 <richardschwerdtfe> Hi Gregory
15:51:40 <JF> JF has joined #html-a11y
15:52:08 <dboudreau> hi everyone
15:52:22 <Zakim> +??P1
15:52:42 <dboudreau> greg! ça va bien?
15:53:09 <MichaelC> zakim, ??P1 is FtF
15:53:09 <Zakim> +FtF; got it
15:55:21 <MichaelC> zakim, FtF has John_Foliot, Silvia_Pfeiffer, Mike_Smith, Rich_Schwerdtfeger, Masatomo_Kobayashi, Janina_Sajka, Denis_Boudreau, Léonie_Watson, Steve_Faulkner, Eric_Carlson, Cynthia_Shelly, Michael_Cooper
15:55:21 <Zakim> +John_Foliot, Silvia_Pfeiffer, Mike_Smith, Rich_Schwerdtfeger, Masatomo_Kobayashi, Janina_Sajka, Denis_Boudreau, Léonie_Watson, Steve_Faulkner, Eric_Carlson, Cynthia_Shelly,
15:55:25 <Zakim> ... Michael_Cooper; got it
15:55:48 <janina> janina has joined #html-a11y
15:56:56 <oedipus> q+ will breakout session use #html-a11y-media or #html-a11y-2 ?
15:57:06 <oedipus> q+ to ask if breakout session will use #html-a11y-media or #html-a11y-2 ?
15:57:07 <MichaelC> agenda: http://www.w3.org/WAI/PF/HTML/ftf_2011-03
15:57:50 <oedipus> ack oe
15:57:50 <Zakim> oedipus, you wanted to ask if breakout session will use #html-a11y-media or #html-a11y-2 ?
15:59:02 <oedipus> thought for the day: "It is much easier to slip into a daydream than it is to think." -- Charles Willeford ("I Was Looking for a Street")
16:00:06 <MichaelC> zakim, Joshue_O'Connor has entered FtF
16:00:06 <Zakim> +Joshue_O'Connor; got it
16:00:15 <MichaelC> zakim, Frank_Olivier has entered FtF
16:00:15 <Zakim> +Frank_Olivier; got it
16:00:22 <MichaelC> zakim, Judy_Brewer has entered FtF
16:00:22 <Zakim> +Judy_Brewer; got it
16:05:39 <lwatson> scribe: lwatson
16:05:56 <oedipus> scribenick: lwatson
16:08:57 <MichaelC> zakim, Sean_Hayes has entered FtF
16:08:57 <Zakim> +Sean_Hayes; got it
16:09:34 <oedipus> need both longdesc (external reference) and describedby (in-document reference)
16:09:53 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
16:10:54 <oedipus> a company or organization might have a collection of clip art for use in site, with pre-canned ALT text and stable LONGDESC reference which can be re-used ad infinitum
16:11:10 <oedipus> central control over images and image description
16:12:31 <lwatson> Topic: Text alternatives
16:12:46 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
16:13:08 <lwatson> SF: Issue 30 is being surveyed ATM.
16:13:45 <lwatson> JS We have given our recommendations on 80, 122 and 31.
16:14:01 <oedipus> lady of shallot: http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/
16:14:29 <lwatson> JS: The question is whether we're satisfied with this, and whether the right supporting points have been made?
16:14:36 <oedipus> GJR's change proposal is survey question 3
16:14:41 <oedipus> q+
16:14:53 <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
16:14:56 <oedipus> q?
16:15:05 <Judy> Judy has joined #html-a11y
16:15:08 <oedipus> TF proposal from TPAC: http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
16:15:08 <cyns> cyns has joined #html-a11y
16:15:29 <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/thematicimages
16:15:43 <Joshue> Joshue has joined #html-a11y
16:16:08 <oedipus> GJR's proposal reflects consensus reached at TPAC 2010 F2F of A11y TF
16:16:13 <oedipus> TF proposal from TPAC: http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
16:16:14 <lwatson> SF: There is a response from me because the riginal bug was filed against the alt text document, that required a change proposal.
16:16:49 <lwatson> SF: The chairs wanted to widen the scope, so the same message was given across the spec and the alt text document.
16:17:37 <oedipus> lady of shallot issue statement: http://www.w3.org/html/wg/tracker/issues/122
16:17:51 <mkobayas> mkobayas has joined #html-a11y
16:17:58 <oedipus> HTML WG ACTION 195 (propose replacement text) http://www.w3.org/html/wg/tracker/actions/195
16:18:05 <lwatson> SF: There is an example of using an img of the Lady of Shallot. The page contains the poem of the same name. The spec suggests the image is therefore decorative, but the alt text doc says otherwise because it adds to the thematic information.
16:18:59 <lwatson> SF: It shouldn't be mandidated that you can't provide an alternative text.
16:19:28 <lwatson> RS: You have short names and long descriptions. There are different vehicles for providing the short.
16:20:04 <MikeSmith> RRSAgent, make minutes
16:20:04 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
16:20:41 <oedipus> chair: Janina_Sajka, MikeSmith
16:20:45 <lwatson> lwatson has joined #html-a11y
16:22:20 <lwatson> JS: To keep this in context, two years ago when we came up with our consensus guidance we said there should be supporting documentation and that it should coe rom WAI.
16:22:31 <Zakim> -FtF
16:23:02 <lwatson> JB: Within the WAI co-ordination group, we spoke about getting this moved to the WCAG WG. BTW, there is also work being started on this by an external organisation that may result in confusion.
16:23:54 <oedipus> q+ to say that my change proposal points to WCAG and SteveF's alt techs document for discussion of purely decorative images after stating that should be controlled by CSS
16:23:59 <oedipus> q?
16:24:08 <Zakim> +??P1
16:24:39 <lwatson> SF: The alt text document was developed to counter the normative advice given within the spec.
16:24:44 <oedipus> GJR replacement text paragraph 1: "If an image is decorative but isn't especially page-specific -- for example, an image that forms part of a site-wide design scheme -- the image should be specified in the site's or document's CSS, not in the markup of the document."
16:25:03 <MichaelC> zakim, ??P1 is FtF
16:25:03 <Zakim> +FtF; got it
16:25:03 <oedipus> GJR replacement text paragraph 2: "Exceptions to this rule, in cases where CSS cannot be used to display an entirely decorative image, are covered by the HTML5: Techniques for providing useful text alternatives. [HTML ALT TECHS] Authors are also encouraged to consult the Web Content Accessibility Guidelines 2.0 for more detailed information and acceptable techniques. [WCAG 2.0] "
16:25:15 <lwatson> SF: If we move the alt text doc out to WCAG, we need a pointer within the HTML5 spec.
16:25:32 <oedipus> steve, that is what my CP provides
16:26:33 <MichaelC> present: John_Foliot, Silvia_Pfeiffer, Mike_Smith, Rich_Schwerdtfeger, Masatomo_Kobayashi, Janina_Sajka, Denis_Boudreau, Léonie_Watson, Steve_Faulkner, Eric_Carlson, Cynthia_Shelly, Michael_Cooper, Joshue_O'Connor, Frank_Olivier, Judy_Brewer, Sean_Hayes, Gregory_Rosmaita
16:26:50 <lwatson> SF: The main issue I'm concerned about, is that the advice in the HTML5 spec is not authoratative.
16:26:56 <oedipus> HTML5 should point to WCAG as per my change proposal
16:27:12 <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
16:27:15 <lwatson> SF: Text alternatives are for more than people with disabilities.
16:27:33 <lwatson> JF: It's not who benefits, but where the guidance comes from.
16:27:49 <lwatson> SF: I would be more than happy if the guidance was maintained outside of the HTML5 spec.
16:28:19 <lwatson> RS: When you put alt="" the spec should advice what the UA does with it.
16:28:20 <dboudreau> I agree with you Greg. There should be a direct link from the spec to WCAG
16:29:05 <lwatson> SF: It' the normative authoring advice that needs looking at.
16:29:25 <lwatson> RS: If an image has role=presentation should the rendering be the same?
16:29:49 <lwatson> SF: Alt="" should be the same as role=presentation.
16:29:52 <oedipus> related: CP for definition of image (also agreed-to at TPAC 2010: http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_definition_of_img
16:30:24 <MikeSmith> q?
16:30:32 <oedipus> my objection to role="presentation" was based on the fact that HTML5 lacked a role attribute -- now we have one, no?
16:30:41 <oedipus> ack oe
16:30:41 <Zakim> oedipus, you wanted to say that my change proposal points to WCAG and SteveF's alt techs document for discussion of purely decorative images after stating that should be controlled
16:30:45 <Zakim> ... by CSS
16:30:48 <lwatson> RS: We could propose advice for UA as to what should happen when images are turned off.
16:31:17 <Sean_> Sean_ has joined #html-a11y
16:31:24 <MikeSmith> RRSAgent, make minutes
16:31:24 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
16:31:38 <Stevef> Stevef has joined #html-a11y
16:31:41 <richardschwerdtfe> yes, we will have a role attribute after our discussion today. ... lexical processing of ARIA section
16:31:53 <oedipus> then i'm ok with role="presentation"
16:32:05 <Joshue> I think we turned a wrong corner when there couldn't even be a consensus that image would have the role="image".
16:32:12 <oedipus> CP for definition of image (also agreed-to at TPAC 2010: http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_definition_of_img
16:32:31 <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
16:32:32 <lwatson> MS: Not sure what Laura's position on this actually is. It would be good if she could join the call.
16:32:41 <oedipus> GJR replacement text paragraph 1: "If an image is decorative but isn't especially page-specific -- for example, an image that forms part of a site-wide design scheme -- the image should be specified in the site's or document's CSS, not in the markup of the document."
16:32:49 <oedipus> GJR replacement text paragraph 2: "Exceptions to this rule, in cases where CSS cannot be used to display an entirely decorative image, are covered by the HTML5: Techniques for providing useful text alternatives. [HTML ALT TECHS] Authors are also encouraged to consult the Web Content Accessibility Guidelines 2.0 for more detailed information and acceptable techniques. [WCAG 2.0] "
16:33:07 <Joshue> We meaning them (sic) and us (sic)
16:33:54 <lwatson> MS: Perhaps we should postpone discussion on this until Laura is here.
16:34:15 <lwatson> JB: We probably souldn't hold up progress on this, as Laura may not be able to make it.
16:34:23 <MikeSmith> http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/results
16:34:43 <MikeSmith> http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/
16:34:56 <MikeSmith> heh
16:35:02 <lwatson> JS: We previously voted GJR's proposal.
16:35:36 <lwatson> JS: Which leaves a second question of where this document/guidance lives.
16:35:49 <oedipus> correct -- we decided at TPAC what to say, and i was tasked to write it up as a ChangeProposal
16:35:53 <Joshue> q+ to ask if the content of the doc is ok, this is really just an issue of where the content lives, right?
16:35:59 <lwatson> SF: We were previously talking about role=presentation. James Craig says this isn't appropriate, as per the ARIA spec.
16:36:33 <lwatson> JC: Is this just about where this document lives?
16:36:37 <Joshue> -q
16:36:51 <MikeSmith> ack Joshue 
16:37:00 <lwatson> CS: So the TF has a position on which position we go with?
16:37:03 <oedipus> can someone type cyns' question into IRC
16:38:02 <oedipus> ACTION: Gregory  - submit comments on behalf of TF to http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ - due 2011-03-24
16:38:03 <trackbot> Created ACTION-110 -  - submit comments on behalf of TF to http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ [on Gregory Rosmaita - due 2011-03-24].
16:38:09 <lwatson> JS: Is there anything else we need to say here on alt, before we move on?
16:38:21 <MikeSmith> yep
16:38:46 <lwatson> SF: We seem to be in agreement, but my one concern is that the change materials the chairs will be reviewing doesn't necessarily reflect the clarity we need.
16:39:00 <MikeSmith> RRSAgent, make minutes
16:39:00 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
16:39:47 <lwatson> SP: If someone has a decorative image, what's the recommended approach?
16:39:58 <oedipus> Stevef, what additions do you deem necessary to the change proposal for 122?
16:40:08 <lwatson> JF: It's a contextual answr, given in some detail in the spec.
16:40:28 <oedipus> GJR proposal says: if purely decorative, use CSS; if can't use CSS, consult WCAG 2.0
16:40:30 <lwatson> SF: If it's purely decorative, then give it a null alt. 
16:41:12 <oedipus> if purely decorative, use CSS to embed image
16:41:18 <JF> http://www.w3.org/TR/wai-aria/roles#presentation
16:42:07 <dboudreau> http://www.w3.org/TR/wai-aria/roles#presentation
16:42:20 <oedipus> if allow liberal use of <img src-"foo.jpg" role="presentation"> will be offering an intollerable escape clause -- purely decorative images should be handled via CSS and only with role="presentation" in circumstances where CSS is not available
16:43:03 <lwatson> RS: role=presentation seems cleaner to me.
16:43:04 <oedipus> q+ to ask why aren't we saying use CSS to control purely decorative images?
16:43:17 <lwatson> JF: We'll need to keep alt="" for backwards compatibility.
16:43:32 <lwatson> CS: We'll need both for at least the next five years or so.
16:44:49 <oedipus> need to say for "redundant" images (such as a mailbox and the hypertext string "email us!" then the image can be role="presentation" or alt="" but that is the only compelling case for not using CSS for images (and even then, if an author is smart, he/she can do this with CSS anyway)
16:44:53 <lwatson> DB: Is there a risk to using role=presentation that we'll need to use role=information for images that are not decorative?
16:45:05 <lwatson> JS: It's presumed, so we probably wouldn't need to.
16:45:11 <oedipus> q?
16:45:30 <lwatson> CS: That was a point of contention at one point, but has since been settled. 
16:46:12 <lwatson> SF: JC raised a question about alt="" and role=presentation. The spec says if a decorative image with role=presentation is encountered, remove it from the accessibility tree.
16:46:22 <lwatson> JS: What's the advice going forward?
16:46:27 <oedipus> q?
16:46:35 <lwatson> SF: That *is the advice, and we haven't questioned this so far.
16:46:37 <oedipus> ack oe
16:46:37 <Zakim> oedipus, you wanted to ask why aren't we saying use CSS to control purely decorative images?
16:46:44 <oedipus> need to say for "redundant" images (such as a mailbox and the hypertext string "email us!" then the image can be role="presentation" or alt="" but that is the only compelling case for not using CSS for images (and even then, if an author is smart, he/she can do this with CSS anyway)
16:46:52 <lwatson> GJR: Why are we saying use CSS to control purely decorative images?
16:47:18 <lwatson> GJR: We should say use CSS for decorative images full stop.
16:47:31 <lwatson> DB: You can't always do that.
16:48:02 <oedipus> janina, GJR replacement text paragraph 1: "If an image is decorative but isn't especially page-specific -- for example, an image that forms part of a site-wide design scheme -- the image should be specified in the site's or document's CSS, not in the markup of the document."
16:48:08 <lwatson> lwatson has joined #html-a11y
16:48:10 <oedipus> janina, GJR replacement text paragraph 2: "Exceptions to this rule, in cases where CSS cannot be used to display an entirely decorative image, are covered by the HTML5: Techniques for providing useful text alternatives. [HTML ALT TECHS] Authors are also encouraged to consult the Web Content Accessibility Guidelines 2.0 for more detailed information and acceptable techniques. [WCAG 2.0] "
16:48:10 <lwatson> MS: This is an issue for the change proposal itself, but with regards to the spec the change proposal is advocating for haing the spec reference some other txt/document. 
16:48:35 <lwatson> MS: It's not an issue in terms of what we need to do for last call. The text we're referencing isn't the issue.
16:48:37 <dboudreau> Greg, there are many situations in which you have no choice but to put your decorative image in the html. I don't think we can enforce that.
16:49:11 <oedipus> dboudreau, the second paragraph says, if you cannot use CSS, then consult Alt Techs and WCAG 2.0
16:49:24 <lwatson> JS: We're dicussing issue 80 ATM.
16:49:49 <lwatson> JS: We have guidance on 80, the question is whether we stand by this?
16:50:01 <MikeSmith> ack oedipus http://www.w3.org/html/wg/tracker/issues/80
16:50:01 <lwatson> JS: We were against using title, if alt wasn't provied
16:50:02 <lwatson> SF: Don't think there has been any disagreement on this, and we had a poll as well.
16:50:06 <Joshue> ISSUE-80 http://www.w3.org/html/wg/tracker/issues/80
16:50:07 <dboudreau> oh, i see. But then, refering to techniques, we should find a reference to role="presentation" there if this is what we agree on
16:50:08 <MikeSmith> http://www.w3.org/html/wg/tracker/issues/80
16:50:28 <oedipus> dboudreau, yes, definitely -- 
16:50:45 <lwatson> MS: Issues 80 and 31 are waiting for the chairs.
16:50:57 <lwatson> JS: Do we need to revisit this?
16:51:13 <oedipus> which CP: http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 ??
16:51:16 <lwatson> CS: Our position has been stated, but issue 31 hasn't ben polled. Do we know what the TF position is?
16:51:48 <lwatson> SP: That label isn't a good substitute for alt?
16:52:18 <lwatson> MS: There are a buch of change proposals for issue 31.
16:52:31 <lwatson> SF: We decided to put forward option 3 (perhaps 2) on this.
16:52:48 <lwatson> MS: Laura wasn't in agreement with this. Would be good to have her input here on this.
16:53:05 <oedipus> SteveF, you are talking about http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 right?
16:53:21 <lwatson> SF: If we're in agreement that the normative advice should be taken out of the spec, our response to 31 should either include or encompass that.
16:53:44 <lwatson> MS: It's a different problem. We do need to have normative text in the spec. This is about the exceptions and what they are.
16:54:01 <lwatson> SF: What should the exception be if you don't have an alt attribute on an image?
16:54:19 <lwatson> MS: In terms of the conformance/validator, what should be an acceptable substitute?
16:55:26 <oedipus> hixie's change proposal for Issue 80 and Issue 31: http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
16:55:35 <lwatson> SF: Summary is that it's ok to h have role=presentation, alt="", or a image with no alt and an associated figcaption, or aria-labelledby.
16:55:42 <lwatson> JF: Did we have agreement with that?
16:55:49 <lwatson> SF: Yes, I think we do. 
16:56:26 <lwatson> JS: We've discussed this sevral times and have always arrived at the same place. We should mntion this in the survey.
16:57:01 <MichaelC> -> http://www.w3.org/2010/11/04-html-wg-minutes HTML meeting in Lyon
16:57:43 <MikeSmith> RRSAgent, make minutes
16:57:43 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
16:58:40 <lwatson> SP: How does aria-labelledby and title fit into this?
16:59:10 <lwatson> SF: The consensus was that title shouldn't be considered a conforming image, as far as the provision of a text alternative goes.
16:59:27 <lwatson> DB: Is that because ATs don't support both?
16:59:41 <lwatson> CS: We feel it's the right way to do it.
17:00:41 <lwatson> SF: Historically, it hasn't been keyboard accessible - the information might be important. It's a browser limitation, but it's been known about for 10 years or more and there is no srong advice in the spec about providing a text dscription is a device independent way.
17:01:14 <lwatson> JF: When IE started putting tooltips in, the attribute values were often duplicated causing information to be doubled up with some ATs.
17:01:29 <oedipus> @title often contains useful metadata (file type, size, etc.)
17:01:57 <lwatson> CS: In the Lyon/TPAC minutes I can't find an agreement.
17:02:15 <oedipus> dboudreau, definitely need to push screen reader devs to support both alt and title (in JAWS, one can set cascade of attributes to expose)
17:03:09 <oedipus> but need to have a query for title and aria-label
17:03:15 <dboudreau> another problem with @title is that it's a hover effect only (tooltip) therefore useless when using the keyboard only and on mobile
17:03:34 <oedipus> dboudreau, agreed
17:04:08 <lwatson> SF: ARIA has no effect on the UA rendering of stuff. So you display the content of aria-label means you're asking the UA to do something extra. I'm not opposed to that, but that's the reason whay it's not in the spec.
17:04:11 <dboudreau> greg, if we were to push them towards supporting both attributes, then users wold get the info twice... pretty annoying don't you think?
17:04:56 <lwatson> CS: Alt is rendered as a place holder, aria-label isn't.
17:05:07 <MichaelC> q+ to time check, we have 1/2 hour left allocated for this session unless we pre-empt another one; also need to hit longdesc
17:05:09 <dboudreau> unless we could get  mechanism that only reads the value of @title when it's different form the @alt's value... but then again, this is just another specific setting available in jaws
17:05:20 <MikeSmith> action Steven to send e-mail message to a11y TF mailing list with a draft summary of the TF consensus position on what exceptions should be allowed for alt-less images (e.g., role=presentation, aria-labeledby, etc.)
17:05:20 <trackbot> Sorry, couldn't find user - Steven
17:05:26 <MikeSmith> action Steve to send e-mail message to a11y TF mailing list with a draft summary of the TF consensus position on what exceptions should be allowed for alt-less images (e.g., role=presentation, aria-labeledby, etc.)
17:05:27 <trackbot> Created ACTION-111 - Send e-mail message to a11y TF mailing list with a draft summary of the TF consensus position on what exceptions should be allowed for alt-less images (e.g., role=presentation, aria-labeledby, etc.) [on Steve Faulkner - due 2011-03-26].
17:05:27 <oedipus> dboudreau, alt needs to be a functional equivalent of the image being described, title is a hint/advice -- when i use both i never use the same text -- validator should mark identical alt and title strings assigned to a single element as an ERROR and instruct the author to either use one or to change the value of one
17:06:00 <oedipus> validator should mark identical alt and title strings assigned to a single element as an ERROR and instruct the author to either use one or to change the value of one
17:06:07 <lwatson> SP: So I'm supposed to use alt as an author, and ignore the rest?
17:06:22 <lwatson> CS: No, they're different things for different situations.
17:06:43 <dboudreau> greg » i like that idea very much. from a validation perspective this is good, but most authors won't validate therefore won't be stopped by this
17:07:00 <MichaelC> q-
17:07:14 <lwatson> RS: When you write the overview, could you include somethig about using aria-label?
17:07:15 <dboudreau> so while i do like it, i don't think it will be useful or helpful enough for the end user
17:07:53 <oedipus> dboudreau, so ATAG needs to say "if author enters identical value for @alt and @title, generate an error message and query for different strings (alt for equivalent info, title for extra metadata)
17:08:29 <lwatson> Topic: Longdesc
17:08:40 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
17:08:49 <dboudreau> greg, i fail to see how this would prevent authors from abusing both attributes with the same value
17:08:49 <lwatson> JS: There are two questions... Where and what. Let's take them in reverse order.
17:08:56 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Requirements_for_HTML5
17:09:08 <lwatson> JS: I suspect there is consensus within the TF to get longdesc back in the spec.
17:09:15 <oedipus> laura's longdesc research: http://www.d.umn.edu/~lcarlson/research/ld.html
17:10:14 <lwatson> JF: We've heard from lots of people that there needs to be a visual indicator of longdesc, for sighted people who would benefit. Longdesc was originally intended to be hidden. Browsers seem reluctant to do this. 
17:10:17 <oedipus> dboudreau, if author using authoring tool, that tool should know to watch for and flag as error identical values for @alt and @title -- sure won't help hand-coders like myself, but we seem to be a dying breed
17:10:29 <MikeSmith> q?
17:11:00 <oedipus> dboudreau, either that or threaten the author with "cruel and unusal punishment"
17:11:18 <lwatson> JF: Several browser vendors have epressed an interest in creating a visual indicator plugin of some kind.
17:11:23 <Judy> q+
17:11:26 <lwatson> s/rpressed/expressed/
17:11:37 <oedipus> tools that support LONGDESC: http://www.d.umn.edu/~lcarlson/research/ld.html#tools
17:11:51 <dboudreau> you may be right... but i'd be reluctant to suport this knowing it would end up meaning redundancy for end users.. i'd rather go with the threat and personnaly dliver it myself (if we have the budget) <grin>
17:11:53 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Implementation_Information_for_LONGDESC
17:12:33 <oedipus> dboudreau, my idea would only work with additions to WCAG, ATAG and UAAG (expose all metadata)
17:12:44 <lwatson> JF: If the browsers themselves can't close the loop, perhaps ATs will
17:13:02 <lwatson> JF: If the browsers themselves can't close the loop, perhaps ATs will?
17:13:26 <richardschwerdtfe> q+
17:13:28 <lwatson> JB: Can you give some examples of the use case for a visual indicator?
17:13:38 <Joshue> I agree with Judy about use of a @longdesc plugin..not mad about the idea.
17:13:40 <oedipus> longdesc not only for blind -- cognitive users may be assisted by a guide to the complex image as would those with very limited viewports
17:13:49 <lwatson> JF: People with disabilities that mean they would benefit from the additional information held in a longdesc. 
17:14:02 <oedipus> longdesc exposure and exposition should NOT be an AT thing, but a UA thing
17:14:17 <Joshue> +1 to GJR
17:14:17 <lwatson> JB: Browser plugins seem like a comprimised way of dealing with this.
17:14:22 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Use_Cases
17:14:37 <oedipus> ack judy
17:14:43 <dboudreau> I also believe we should work to have longdesc supported by the UA, not the AT... UA means more people can benefit form it
17:14:54 <oedipus> dboudreau, amen, brother!
17:15:09 <lwatson> JB: How much as the TF looked into the use cases?
17:15:41 <Joshue> Longdesc shouldn't be a second class citizen in the browser.
17:15:45 <richardschwerdtfe> q?
17:15:48 <oedipus> plus 1 to JOC
17:15:52 <lwatson> JB: If one of the reasons the browsers are pushing back is because the use cases aren't strong enough, perhaps the TF should strengthen the case.
17:16:30 <oedipus> judy, laura and i have tried to structure http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs to reflect what the chairs told us they wanted explicated
17:17:06 <lwatson> RS: Rather than a plugin, have you asked the browsers about an option within the settings?
17:17:31 <Joshue> A configurable option in the browser isn't a bad idea. +1 to RS.
17:18:01 <lwatson> JF: The functionality is available through the contextual menu. Screen readers also have a mechanism for giving the user a choice of whether to access the longdesc.
17:18:18 <oedipus> plus 1 as well -- user needs to know longdesc available -- should be able to put images with longdesc into the tab-navigation order so it is easy for the user to access
17:18:51 <lwatson> JF: One of the prolems with longdesc is that developers don't see it, potential cause for longdesc etc. If we make it visible, it has to go in one of two places. A plugin will give us proof of concept.
17:19:20 <oedipus> JF, note that one can only get longdesc info from a graphic if one lets the whole page be spoken or if one navigates from graphic-to-graphic when using screen reader
17:19:27 <lwatson> RS: The concern I have is that the people who need a visual indicator, is that a plugin will be difficult for the people who would ost benefit from the functionality.
17:19:41 <lwatson> s/ost/most/
17:19:41 <MikeSmith> q?
17:19:44 <oedipus> UA needs to allow users to add images with longdesc to the tab navigation order for the page
17:19:45 <MikeSmith> ack richardschwerdtfe 
17:20:07 <Joshue> +q
17:20:11 <lwatson> RS: Let's put the use case together and explain that the UA should provide a visual indicator.
17:20:31 <oedipus> visual indicator should be an option not a requirement or default setting
17:20:44 <lwatson> JF: Longdesc is a DOM node. As ar as supporting the browsers goes, it's ther. It's what the visual browsers do with this information.
17:20:58 <oedipus> author can assist with CSS applied to image with longdesc
17:21:10 <dboudreau> Laura's research on londgesc is 121 printed pages long. How much stronger does our use case really needs to be?
17:21:23 <lwatson> MS: The issue is whether longdesc should be conforming. It will still work, it just won't validate.
17:21:26 <oedipus> dboudreau, i've been wondering that myself
17:22:04 <Joshue> -q
17:22:21 <oedipus> q+ to say as a reminder -- longdesc is a "make or break" issue for EPUB 3.0 compatibility with HTML5
17:22:22 <dboudreau> dboudreau has left #html-a11y
17:22:33 <lwatson> JF: The title attribute was for advisable information, but it was never specified how that should be presented to the user. The upshot was that it became a tooltip, but that was just the path chosen by the rowsers. We'll have the same thing with longdesc.
17:22:48 <lwatson> s/rowsers/browsers/
17:22:58 <dboudreau> dboudreau has joined #html-a11y
17:23:03 <oedipus> q?
17:23:31 <Joshue> +q to say that I don't agree with the longdesc POC approach, the requirements and use cases should be defined first and then clearly defined in the HTML5 spec. The plugins etc already exist, more of them won't help the issue.
17:24:09 <lwatson> RS: We could say that to support longdesc the UA must provide a facility to allow the user to have visual indication that longdesc is available on the element. Also that it must be a high level vehicle.
17:24:18 <lwatson> SF: I agre, but we won't get a "must" in there.
17:25:02 <lwatson> SF: There needs to be device independent access to the title attribute, and we've been told that can't be mandidated. We can't say that the UA is "required" to provide access to an element/attribute/information.
17:25:28 <oedipus> visual indicator should be an option not a requirement or default setting
17:25:35 <lwatson> JB: This isn't going to be something that gets unanimous consent. We need to articulate what we need clearly.
17:25:54 <lwatson> JF: We'll get "should", but probably not "must".
17:26:02 <oedipus> UA MUST provide access to and indication of LONGDESC, but a visual indicator SHOULD be an option not a requirement or default setting
17:26:07 <lwatson> JB: That may not be the case. It may need to be an override.
17:26:08 <oedipus> q?
17:27:40 <lwatson> JB: I wanted to speak to the timing, which is the trickiest part of our strategy. It could play out in many different ways. We could for example have this first on the queue after the last call is issued.
17:27:54 <MikeSmith> q?
17:28:46 <lwatson> RS: Would the IE team be open to the idea of a visual indicator?
17:29:02 <oedipus> yes, rich, but not by default
17:29:05 <lwatson> CS: I'm not on the IE team, so can't speak for them, but it may be a challenge.
17:29:19 <Stevef> oedipus: can you point me to your long description wiki page?
17:29:45 <oedipus> SteveF, which the verbose descriptoin reqs or the original HTML WG page on longdesc?
17:29:50 <lwatson> EC: Same thing for Safari. The feedback from users is to put less chrome in front of us.
17:29:55 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
17:30:35 <lwatson> JF: There is a timeline of implementation. a plugin is the "cheap, easy and beautiful" option. If we can prove there is a need and the browser vendors can see the download data, it adds to the use case.
17:30:49 <lwatson> JB: So it wouldn't interfere with the chrome?
17:31:02 <oedipus> http://www.w3.org/html/wg/wiki/LongdescRetention
17:31:55 <Joshue> -q
17:32:06 <lwatson> RS: EC, do you have a notion of whether a plugin might e considered by Apple/Safari?
17:32:26 <lwatson> JS: Does this need to be a user action, the browser could action an auto-download.
17:32:36 <lwatson> CS: That opens up questions over security.
17:32:44 <oedipus> ack oe
17:32:44 <Zakim> oedipus, you wanted to say as a reminder -- longdesc is a "make or break" issue for EPUB 3.0 compatibility with HTML5
17:32:47 <oedipus> GJR wants to address urgency of longdesc and describedby -- EPUB can't wait until Last Call, but needs a decision now to keep it aligned with the HTML5 spec as requested of the HTML WG Chairs by George Kerscher, Jim Fructerman and Geoff Fried
17:32:59 <oedipus> i can't hear you either -- put comments into IRC
17:33:43 <lwatson> GJR: There is some urgency on this. The important thing is that ePub badly wants longdesc in HTML5.
17:34:00 <oedipus> judy, yes, i'll get URI
17:34:03 <lwatson> JB: That's the same reference as in the Diagram Project letter.
17:34:07 <MikeSmith> s/Fried/Freed/
17:34:32 <lwatson> DB: Usually when you can't find agreement, you need to look at it on different levels, not just technical.
17:34:42 <lwatson> JB: Yes, it is being looked at on multiple levels.
17:35:24 <oedipus> G Freid on behalf of DIAGRAM project to HTML WG Chairs: http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html
17:35:39 <lwatson> JB: There are various mechanisms we can look at. The requirements of last call require that things need to be fully addressed, so there is a question that the spec should go to last call now.
17:35:49 <oedipus> s/Fried/Freed/G
17:36:22 <lwatson> DB: I'm not sure we'll get it through using the usual channels.
17:36:40 <oedipus> q+ to ask if describedby will be simply describedby or aria-describedby?
17:36:44 <lwatson> JB: We do need to respond to the points that were raised, and to justify very clearly out position.
17:37:00 <lwatson> JF: It seems to me we've covered most of this withour change proposal, is there more we can add to this?
17:37:46 <MikeSmith> RRSAgent, make minutes
17:37:46 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
17:38:04 <lwatson> JB: Another problem I see, it isn't fully clear what the proposal on the table actually is. We're not all fully co-ordinated within the TF. The chairs would also like to see dialogue between the TF and the people who are opposed to restoring longdesc.
17:38:34 <lwatson> JF: We need to address the fact that longdesc will throw a validation error.
17:38:35 <oedipus> what is justification for opposing restoration of longdesc?  i mean the REAL justification....
17:38:41 <lwatson> SF: That's actually a very small change.
17:39:00 <lwatson> JB: My impression is that more was needed for clarity. Does Laura's prposal include everything we need?
17:39:36 <lwatson> JB: The chair's impression seems to be that not everyone within the TF even agrees about restoring longdesc. Removing that confusion would give clarity.
17:39:48 <lwatson> JF: We;ve covered longdesc at previous F2F meetings.
17:40:04 <lwatson> SF: What we have unanimity on is that there needs to be a dedicated method to providing a long description.
17:40:11 <oedipus> HTML5 lacks a verbose descriptor mechanism (HTML bug 10052) includes requirements: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853 
17:40:34 <lwatson> JB: The technical proposal needs to be the best we can do, and this opens up other options for how its followd through.
17:40:45 <MikeSmith> q?
17:40:46 <oedipus> requirement 1: A programmatic mechanism to reference a specific set of structured content, either internal or external to the document containing the described image
17:40:57 <MikeSmith> ack oedipus 
17:40:57 <Zakim> oedipus, you wanted to ask if describedby will be simply describedby or aria-describedby?
17:41:01 <lwatson> JF: So, what do we need to do now? We don't have longdesc in the spec, and the chairs have told us they won't discuss it until aftr last call.
17:43:14 <lwatson> JB: If the chairs did put this first in queue, feedback from the TF on what we think about that would be useful to know today.
17:43:15 <MikeSmith> q+ oedipus to ask if describedby will be simply describedby or aria-describedby
17:43:18 <oedipus> q+ to ask if describedby will be simply describedby or aria-describedby in HTML5?  is the aria- prefix necessary?  if there is ARIA-in-HTML, then should just be describedby
17:43:58 <oedipus> ack oe
17:43:58 <Zakim> oedipus, you wanted to ask if describedby will be simply describedby or aria-describedby and to ask if describedby will be simply describedby or aria-describedby in HTML5?  is the
17:44:02 <Zakim> ... aria- prefix necessary?  if there is ARIA-in-HTML, then should just be describedby
17:44:05 <Stevef> q+
17:44:14 <oedipus> i'm ok with discussing later
17:44:22 <MikeSmith> ack Stevef 
17:44:35 <lwatson> SF: As far as ePub is concerned, what is their requirement? Do they require a specific method for providing long description?
17:44:44 <oedipus> SteveF, yes
17:44:46 <dboudreau> greg, if we removed the aria prefix, wouldn't it cause confusion? using describedby in html5 and aria-describedby in any other language?
17:44:59 <Joshue> A good question is to try and understand why is there the opposition to longdesc in HTML5 in the first place.
17:45:05 <lwatson> JB: Their primary concern is that longdesc is gone, after a decade or more of support.
17:45:11 <oedipus> SteveF, DIAGRAM/EPUB request http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html
17:45:14 <MikeSmith> let's take a break in 5 minutes or so
17:45:20 <lwatson> SF: So simply making it a conforming attribute would be sufficient for ePub?
17:45:21 <Joshue> +1 to MS
17:45:41 <oedipus> dboudreau, good point, but if aria is included as part of HTML, then the aria- prefix doesn't make sense
17:45:50 <oedipus> in the HTML context, that is
17:45:53 <dboudreau> joshue, there is oposition because some feel that since it's never been implemented properly by brosers and authors ailways used it wrong, it should be replaced by a better mechanism
17:46:11 <lwatson> JB: So, how can we be responsive to the concerns and to the user needs? If there is a way to evolve it to a configurable option, that would be good. If the TF could write out that path, that would also be helpful,
17:46:16 <oedipus> joshue, bogus web-usage statistics
17:46:36 <Joshue> db, yes I know that but its not a good enough reason IMO
17:46:37 <lwatson> SF: If it were brought back to conforming, there would be lots of way to look at the rest and create proofs of concept.
17:46:50 <oedipus> plus 1 to SF
17:46:56 <Joshue> oedipus, lol. He who makes the stats makes the rules..
17:47:02 <MikeSmith> q?
17:47:11 <dboudreau> removing @longdesc based on this is pretty much like saying we should remove h1 because most authors use <p class="pageTitle">
17:47:18 <Joshue> +q
17:47:34 <lwatson> SF: It's the semantic indication that there is a longdesc, the mechanics are open.
17:47:48 <oedipus> requirement 1: A programmatic mechanism to reference a specific set of structured content, either internal or external to the document containing the described image
17:48:12 <oedipus> HTML5 does not provide the functions that had been provided through the HTML 4 attribute longdesc. Those functions are: 1. A direct, reusable programmatically determinable mechanism to a long description of an image without a forced visual encumbrance or default visual indicator. and  2. A method to reference a longer description of an image, without including the content in the main flow of...
17:48:14 <oedipus> ...a page
17:48:27 <lwatson> JB: To come back to DB's question... The fact there is long documentation isn't perhaps as relevant as *what we provide. Does it specifically defin use cases, and (as the chairs would like) does it address each point very clearly. If I can be of help in looking at the presentation of the response, I will.
17:49:33 <lwatson> JS: Are we generally agreed with this proposal, to take it as a first last call issue?
17:49:39 <lwatson> +1
17:49:42 <dboudreau> +1
17:50:30 <Joshue> q?
17:50:40 <lwatson> JS: Let me summarise... At the time they published last call, there will be a list of issues with the spec. At the top will be longdesc, and a committment from the chairs to look at this as the first priority.
17:51:18 <oedipus> q?
17:51:28 <lwatson> JB: I think there is a misunderstanding on the chair's part that there is strong dissention within the TF about restoring longdesc. There hasn't been any of that dissention within this discussion today. Am I hearing right?
17:51:31 <dboudreau> q?
17:52:17 <MikeSmith> RRSAgent, make minutes
17:52:17 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
17:52:21 <lwatson> RRS: I was a dissenter, but I'm happy to go with the flow.
17:52:47 <oedipus> the chairs made a mistake in removing something EXPLICITLY added to HTML4 as part of the director's mandate on accessibility WITHOUT proposing an equivalent or superior mechanism, nor even the recognition that this functionality is needed
17:53:24 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Requirements_for_HTML5
17:53:56 <Judy> q?
17:53:59 <dboudreau> q+
17:54:11 <lwatson> SF: It's important that if it is restored, the spec clearly explains a mechanism for how it should be implemented that improves on the current HTML4 implementation.4
17:54:43 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Reinstate_longdesc_and_Add_a_Native_describedby_Attribute
17:55:29 <oedipus>  Judy, a lot of this discussion was held up until the ARIA-in-HTML decision was issued
17:56:10 <oedipus> still feel strongly we need to state in this case (and in other, summary comes to mind) the chairs made a mistake in removing something EXPLICITLY added to HTML4 as part of the director's mandate on accessibility WITHOUT proposing an equivalent or superior mechanism, nor even the recognition that this functionality is needed
17:56:54 <lwatson> JS: Returning to GJR's question about what last call means... The proposal is that in May there will be a last call that includes the publication of the spec. Longdesc will not be specified in there as conforming. There will be a statement of known issues, and longdesc will beat the top and the committment is there to take that up as the first issue.
17:57:06 <Joshue> +1 to GJR, right on.
17:57:07 <oedipus> i can't speak on EPUB's behalf without pinging at least marku
17:57:14 <lwatson> JS: At the end of that process, approx. 30 days, there will be an updated last call spec that would include the disposition of that review.
17:57:17 <oedipus> s/marku/markus/
17:57:48 <oedipus> thanks, janina
17:58:10 <lwatson> JS: I understand ePub's concerns, we're often asked to hurry alog because people need/want to use our specs.
17:58:16 <Joshue> -q
17:58:33 <Zakim> -Gregory_Rosmaita
17:58:37 <dboudreau> -q
17:59:20 <oedipus> many thanks to leonie for minuting
18:08:11 <Zakim> +??P0
18:08:42 <Zakim> -??P0
18:09:27 <Zakim> -FtF
18:09:28 <Zakim> WAI_(A11YF2F)11:30AM has ended
18:09:30 <Zakim> Attendees were Gregory_Rosmaita, John_Foliot, Silvia_Pfeiffer, Mike_Smith, Rich_Schwerdtfeger, Masatomo_Kobayashi, Janina_Sajka, Denis_Boudreau, Léonie_Watson, Steve_Faulkner,
18:09:30 <JF> JF has joined #html-a11y
18:09:32 <Zakim> ... Eric_Carlson, Cynthia_Shelly, Michael_Cooper, Joshue_O'Connor, Frank_Olivier, Judy_Brewer, Sean_Hayes, FtF
18:10:02 <Zakim> WAI_(A11YF2F)11:30AM has now started
18:10:08 <Zakim> +??P1
18:10:22 <MichaelC> zakim, ??P1 is FtF
18:10:22 <Zakim> +FtF; got it
18:11:20 <Zakim> +Gregory_Rosmaita
18:13:24 <richardschwerdtfe> richardschwerdtfe has joined #html-a11y
18:15:00 <eric_carlson_> eric_carlson_ has joined #html-a11y
18:15:02 <silvia1> silvia1 has joined #html-a11y
18:15:37 <silvia> silvia has joined #html-a11y
18:16:00 <MikeSmith> MikeSmith has joined #html-a11y
18:16:01 <dboudreau> dboudreau has joined #html-a11y
18:16:08 <MichaelC> MichaelC has joined #html-a11y
18:18:03 <richardschwerdtfe> richardschwerdtfe has joined #html-a11y
18:18:47 <MikeSmith> RRSAgent, make minutes
18:18:47 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
18:19:00 <Joshue> Joshue has joined #html-a11y
18:19:12 <MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2011-03
18:19:12 <Joshue> Scribe: Joshue
18:19:24 <Joshue> TOPIC: ARIA Lexical Processing
18:19:51 <Joshue> RS: There were couple of topics refs to role model, we have to say where role is defined.
18:20:06 <Joshue> MC: Or define it in that section, I would like role to be a global att
18:20:07 <oedipus> NOTE: section 3.6.2 is now section 3.6.7 http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria
18:20:11 <Joshue> RS: Ok
18:20:25 <Joshue> MC: If not we can define in the proposed section.
18:20:33 <Joshue> RS: You want to define it in just ARIA
18:20:43 <Joshue> MC: I don't think the HTML 5 wants to.
18:21:10 <oedipus> plus 1 to MCooper -- defined in 3.2.7 as defined in WAI-ARIA, role global attribute for HTML5 with possible exceptions
18:21:14 <Joshue> RS: Also HTML 5 has booleans, true etc. ARIA not defined that way.
18:21:42 <oedipus> what about the redundant stuff in ARIA that was for plugging holes that may be plugged by HTML5?
18:21:46 <Joshue> RS: A checkbox can have true,false, mixed for example, so we don't limit it in the same way as HTML5
18:22:02 <Joshue> RS: So we have to define the processing of ARIA?
18:22:24 <Joshue> RS: Mike, you wrote the section how should we proceed?
18:22:44 <JF> JF has joined #html-a11y
18:23:51 <oedipus> NOTE: section 3.6.2 is now section 3.6.7 http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria
18:24:14 <Joshue> RS: I know that DAISY eg would like to provide diff roles.
18:24:36 <Joshue> MC: Don't know what to do about that, for ARIA we want the role @ to support the various roles.
18:24:38 <oedipus> EPUB wants to support ARIA roles and RDFa roles
18:24:51 <Joshue> MC: We could propose the att with expanded values.
18:24:58 <Joshue> RS: Lets have a look.
18:25:11 <Zakim> -FtF
18:25:21 <Joshue> <current ARIA lexical doc being looked at>
18:26:45 <Joshue> MC: I suggest adding role to the list of global attr in the current HTML5 editors draft.
18:26:52 <Stevef> Stevef has joined #html-a11y
18:26:54 <oedipus> are we looking at: http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5 ???  the phone is down on your end
18:26:55 <Joshue> RS: Thats prob a good place
18:26:58 <Stevef> http://www.html5accessibility.com/tests/aria-changes.html
18:27:11 <Joshue> RS: What is the role attr state? CR?
18:27:43 <Joshue> MC: The HTML WG don't want to reference the ARIA role attr model
18:27:52 <Stevef> oedipus: have marked the chnages using ins @ del elements don't  know if you can pick that up
18:27:52 <Joshue> RS: It has to be a space delimited list
18:27:55 <Joshue> MC: For sure
18:28:18 <Joshue> RS: We should take text from the role attr module and tailor it
18:28:20 <Joshue> MC: Yes
18:28:29 <oedipus> SteveF: now that you told me what to have my SR look for, i should be able to find them -- you might add a note to the text for others, though
18:28:42 <Joshue> <group looks at ARIA section of spec>
18:28:47 <Stevef> sur
18:28:55 <Joshue> MC: We need to define all of the ARIA attr in HTML spec.
18:28:56 <Stevef> oedipus: will do
18:29:28 <Joshue> MC: HTML doesn't defined elements by reference..
18:29:40 <oedipus> http://www.w3.org/TR/role-attribute/
18:29:51 <oedipus> http://www.w3.org/TR/role-attribute/#s_role_module_attributes
18:29:56 <Joshue> CS: We are waiting for Ian to complete his Action item.
18:30:09 <oedipus> "The attribute describes the role(s) the current element plays in the context of the document. This can be used, for example, by applications and assistive technologies to determine the purpose of an element. This could allow a user to make informed decisions on which actions may be taken on an element and activate the selected action in a device independent way. It could also be used as a...
18:30:11 <oedipus> ...mechanism for annotating portions of a document in a domain specific way (e.g., a legal term taxonomy). Although the role attribute may be used to add semantics to an element, authors should use elements with inherent semantics, such as p, rather than layering semantics on semantically neutral elements, such as div role="paragraph"."
18:30:48 <Joshue> RS: Ian send a note about ARIA normative, I don't want to limit HTML 5 to what is in ARIA 1.0.
18:31:02 <Joshue> MC: If we can incorporate by reference thats fine.
18:31:13 <Joshue> MS: Thats what is done, MATHML eg
18:31:31 <Zakim> -Gregory_Rosmaita
18:31:32 <Zakim> WAI_(A11YF2F)11:30AM has ended
18:31:33 <Joshue> MC: We do need to map value types.
18:31:34 <Zakim> Attendees were FtF, Gregory_Rosmaita
18:31:52 <Joshue> JOC: Not referencing a numbered version would help.
18:31:54 <Joshue> RS: Yup
18:32:30 <Joshue> RS: If ARIA is to define new roles, that they be limited to elements that do not restrict the roles they can be applied to.
18:32:54 <Joshue> <looks at screen of ARIA role and value type>
18:33:05 <Joshue> MC: They need to be copied, I can do this via XSLT.
18:33:25 <Joshue> MC: We are just not using the HTML boolean type, just using them as token types.
18:33:34 <Joshue> CS: We need to be explicit about that.
18:34:01 <Joshue> MC: We want to expand that note, and make it an editors note.
18:34:11 <Joshue> RS: Start with role?
18:34:15 <Joshue> MC: Yes
18:34:20 <oedipus> http://www.w3.org/TR/role-attribute/#s_role_module_attributes
18:35:19 <Joshue> <group reviews current draft>
18:35:59 <Joshue> RS: The role attr takes this value.. lets not use a CURIE, we should take a string?
18:36:07 <Joshue> MC: I suggest a token.
18:36:19 <oedipus> plus 1 to token
18:36:46 <Joshue> MC: Looking at micro syntaxes, we want space seperated tokens.
18:36:50 <Joshue> RS: Yes, we do.
18:37:03 <oedipus> plus 1 to space separated tokens
18:37:09 <Joshue> <some spec cpy n pste going on>
18:38:29 <Joshue> <some editing going on>
18:40:24 <Joshue> <look at XHTML vocab>
18:40:38 <oedipus> http://www.w3.org/TR/role-attribute/#bib-XHTML-VOCAB
18:40:53 <oedipus> http://www.w3.org/1999/xhtml/vocab
18:42:08 <Joshue> RS: Are we going to sync with ARIA implementation guide? Steve?
18:42:25 <Joshue> RS: We will prob define mapping in ARIA 2?
18:42:36 <Joshue> CS: The guide are seperate?
18:42:54 <Joshue> RS: Yes, knew roles are features are defined, don't want to be glued to version number.
18:43:06 <Joshue> RS: How do we define the processing of the role values?
18:43:16 <Joshue> CS: So if ARIA has new roles?
18:44:27 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
18:44:50 <Joshue> RS: Say, EPUB and DAISY etc, re ARIA 2 we want to say the value mappings are defined in an external reference. HTML to platform A11y API Implementation Guide.
18:45:05 <Joshue> RS: If new roles are created
18:45:12 <Joshue> CS: In a later version of ARIA
18:45:22 <oedipus> http://www.w3.org/TR/role-attribute/#extending-the-collection-of-roles
18:45:27 <Joshue> RS: I want to say that those roles in ARIA are not restricted.
18:45:46 <Joshue> CS: Don't know about that, or you will only use them on <divs>
18:46:01 <oedipus> "It is possible to define additional role values. Such values must be defined in their own vocabulary. The URI associated with that vocabulary should resolve to a resource that allows for the machine and human discovery of the definition of the roles in the vocabulary. One format that achieves this is the RDFa Profile as defined in [RDFA-CORE]. Note: If this attribute is used in conjunction...
18:46:02 <oedipus> ...with RDFa (see Appendix A), then the vocabulary definition must be the same as that required by RDFa."
18:46:03 <Joshue> CS: We don't want to say that only certain elements etc would accept ARIA roles etc
18:46:15 <Joshue> CS: I want to say that there is some restriction to new ARIA roles.
18:46:39 <Joshue> SF: This refers to strong native semantics and implied semantics..
18:46:59 <Joshue> MC: We have three external and two internal refs..
18:47:36 <oedipus> do we want to align role extention with RDFa-Core? http://www.w3.org/TR/2010/WD-rdfa-core-20101026/
18:47:39 <Joshue> RS: So if we define new ARIA roles we have to update the implementation guide?
18:47:41 <Joshue> MC: Yes
18:47:48 <Joshue> RS: Perfect.
18:48:14 <Joshue> CS: But no that duplicates the funcionality of the implementation guide?
18:48:54 <Joshue> RS: We just need to point to mapping for any new ARIA updates.
18:49:22 <Joshue> <some confusion about what docs are being referred to>
18:49:46 <Joshue> MC: Yes, the WAI-ARIA User Agent Imp Guide..
18:50:00 <Joshue> CS: Yes, we can edit that at will.
18:50:51 <Joshue> RS: So there won't be a ref to implementation guide?
18:51:05 <Joshue> RS: Will will need normative references to the UA guide?
18:51:12 <Joshue> MC: Yes, we have that now.
18:51:34 <Joshue> CS: So how about something that states new ARIA roles cannot be applied to elements that do not allow override?
18:51:45 <Joshue> <more spec wordsmithery>
18:51:48 <oedipus> using role in conjunction with RDFa http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-rdfa
18:51:57 <Joshue> RSSAGENT, make minutes
18:52:14 <oedipus> "If a Host Language contains the @role attribute, then an RDFa processor processing a document written in that Host Language according to the rules of that Host Language may generate additional triples for role attributes. If these additional triples are being generated, then they must be generated as follows:"
18:52:35 <Joshue> RRSAGENT, make minutes
18:52:35 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html Joshue
18:53:40 <Joshue> CS: We don't want to be too restrictive..
18:53:54 <Joshue> RS: There may be a fight.
18:54:10 <Joshue> RS: Ian asked about what is normative, I think we have to do this.
18:54:36 <Joshue> CS: If we make an ARIA overide at some stage, we need to be able to add that.
18:54:52 <Joshue> MC: Getting the group to agree to externalise this section would be good.
18:54:58 <Joshue> CS: I agree.
18:55:22 <Joshue> SF: We want Steves annoteted doc externalised
18:55:31 <oedipus> cooper, by externalize, do you mean split off into a separate document, like the Alt Techs doc?
18:55:34 <Joshue> s/annoteted/annotated
18:57:08 <Joshue> <discussion on overrides etc>
18:57:14 <oedipus> won't we be accused of cyber-ghettoization?
18:57:47 <Joshue> SF: Ian did say that role="presentation" can be on anything.
18:57:49 <Joshue> RS: Yes
18:58:11 <Joshue> RS: Two things, we need to say what happens when ARIA introduces new roles.
18:58:30 <Joshue> RS: Also what happens when a role value is provided if not listed in HTML5 spec
18:58:54 <oedipus> on ANY element? <head role="presentation" > doesn't make any sense...  is there an exception for elements that appear in the HEAD
18:59:01 <Joshue> MC: They might want a conformance warning..
18:59:04 <Joshue> CS: Yes
18:59:25 <Joshue> MS: Currently I don't think the spec does define this.
18:59:56 <Joshue> MS: It does say role attr * etc can be used
18:59:57 <oedipus> spec should at least limit role="preentation" to elements that occur in the BODY of a document
19:00:07 <oedipus> er, role="presentation"
19:01:05 <Joshue> MS: I don't see a restriction on what can be implemented in validator.
19:01:29 <Joshue> MC: ARIA 1.0 does say take the first recognised token..
19:01:40 <Joshue> MC: Then ARIA spec say all it needs to.
19:01:57 <Joshue> RS: So are we ok with ARIA role def?
19:02:15 <oedipus> what is the ARIA role def -- as tweaked today?
19:02:19 <Joshue> <more word smithery>
19:02:32 <Joshue> s/def/definition
19:03:00 <Joshue> MC: If we externalise this stuff we can fix more easily
19:03:29 <Joshue> RS: If we wish to add new role values, etc we wish to state it would not create a conformance error?
19:03:46 <Joshue> MC: Don't really mind, to have warnings may not be ideal.
19:03:52 <oedipus> RS, as long as the role value is documented as per Role Attribute verbiage
19:04:13 <oedipus> "It is possible to define additional role values. Such values must be defined in their own vocabulary. The URI associated with that vocabulary should resolve to a resource that allows for the machine and human discovery of the definition of the roles in the vocabulary. One format that achieves this is the RDFa Profile as defined in [RDFA-CORE]."
19:04:17 <Joshue> <discussion of other use cases>
19:04:50 <oedipus> "Note If this attribute is used in conjunction with RDFa (see Appendix A), then the vocabulary definition must be the same as that required by RDFa." http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-rdfa
19:05:33 <Joshue> <more discussion on implemtation guide etc>
19:05:54 <Joshue> s/implemtation/implementation
19:06:47 <Joshue> MC: This is kinda like microformats, we need an interoperable web..
19:07:07 <Joshue> RS: Regarding DAISY etc, they may ignore these warnings.
19:07:29 <Joshue> <discussion on EPUB etc>
19:07:56 <Joshue> CS: They should come up with there own schema
19:08:22 <oedipus> EPUB wants to ensure that it is as close to HTML5 as possible so as to allow rendering of EPUB content in HTML5-capable UA
19:08:32 <Joshue> MS: In HTML 5 we have no normative schema.
19:09:08 <Joshue> <discussion on RELAX NG and spec schema etc>
19:09:18 <oedipus> cyns, EPUB will come up with own, if can't get from HTML5 -- point is, they'd rather not have to come up with their own, but reuse native semantics
19:10:18 <Joshue> MS: The EPUB group were concered about developing their own schema.
19:10:42 <Joshue> <more word smithery>
19:12:18 <Joshue> MC: The values that are allowed changes by element.
19:12:25 <Joshue> RS: Is the title going to remain?
19:13:01 <Joshue> <discussion on Stevef's doc title>
19:14:07 <Joshue> The 'Annotations for Assitive Technology' doc
19:20:40 <oedipus> break now for lunch or are we continuing through lunch?
19:21:49 <oedipus> s/break now for lunch or are we continuing through lunch?//
19:24:09 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
19:39:56 <oedipus> can i step away for a break or are we coninuing?  if a break, how long?
19:40:03 <oedipus> er, continuing
19:43:32 <dboudreau> dboudreau has joined #html-a11y
19:59:20 <oedipus> dboudreau, the reason we didn't make describedby capable of taking an external URI was: 1) we thought that LONGDESC already did that and liked the solutions offered by SVG (namely, a container into which structured content could be put) and 2) when it did come up as a potential replacement for LONGDESC, ARIA was already finishing its second last call period, and making the change to...
19:59:22 <oedipus> ...describedby would have necessitated a return to Last Call, when we REALLY want to get ARIA through CR!
20:00:38 <oedipus> s/already finishing/already in/
20:19:17 <oedipus> HTML5 Section 7.2 - "Activation" http://dev.w3.org/html5/spec/editing.html#activation 
20:19:23 <oedipus> HTML5 Section 7.3 - "Focus" http://dev.w3.org/html5/spec/editing.html#focus
20:22:12 <Joshue> TOPIC: CANVAS
20:23:04 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas
20:23:36 <Zakim> WAI_(A11YF2F)11:30AM has now started
20:23:43 <Zakim> +Gregory_Rosmaita
20:24:08 <Joshue> SF: Regarding the mapping doc is there a prefered place for that?
20:24:14 <Joshue> MS: In the ARIA section.
20:24:52 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals
20:24:52 <Zakim> +??P2
20:25:05 <MichaelC> zakim, ??P2 is FtF
20:25:05 <Zakim> +FtF; got it
20:25:20 <Joshue> MC: I should do a CP
20:25:41 <Joshue> MC: I would like to take over the doc that Steve has been editing.
20:26:03 <Joshue> MC: I will then do a proposal with suggested additions etc
20:26:25 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
20:27:16 <Stevef> Stevef has joined #html-a11y
20:27:19 <Stevef> http://www.html5accessibility.com/tests/aria-changes.html
20:27:57 <Joshue> RS: Are we doing to have a what ARIA dot (incremental) version?
20:28:01 <oedipus> Stevef, do you have any comments on HTML WG Bug 10905 - clarify how assigning an accesskey to an element affects the elements default role filed by Steve Faulkner http://www.w3.org/Bugs/Public/show_bug.cgi?id=10905 for http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs#Bugs_marked_RESOLVED_WONTFIX
20:28:11 <Joshue> MC: We haven't decided yet
20:28:17 <Stevef> oedipus: will look
20:28:43 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals
20:29:11 <Joshue> RS: Re: canvas, we have a CP out now. We'll talk about hit testing for a11y APIs.
20:30:15 <Joshue> RS: It would be great to have someone from Apple to float some concepts about clickable regions.
20:31:10 <oedipus> scribe: Gregory_Rosmaita
20:31:15 <oedipus> scribenick: oedipus
20:31:39 <oedipus> <trying to find participants for discussion>
20:32:03 <oedipus> MC: agenda has media people in breakout for most of 2 days
20:32:15 <oedipus> MC: could see if GJR ready for Access discussion
20:32:25 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
20:32:38 <oedipus> most of them have status reports
20:32:44 <oedipus> RS: returning to CANVAS
20:33:03 <oedipus> RS: problem: for a11y and authors -- very difficult to do clickable areas for authors (hit testing)
20:33:37 <oedipus> RS: want to introduce concept of clickable region as have in windowing system -- dates back to windows 3 -- when draw to desktop, have device context (font, color, clipping region, bounding rectangle)
20:34:10 <oedipus> RS: when click on screen app in windows calls into app (hit test) -- if child in there, keep going through -- know clicked in area -- not a concept contained currently in CANVAS
20:34:22 <oedipus> RS: what you can do is...
20:34:28 <oedipus> RS: fills rest of gap we have
20:34:42 <oedipus> <rich looks for slide from CSUN presentation>
20:35:54 <silvia> silvia has joined #html-a11y
20:36:00 <MikeSmith> MikeSmith has joined #html-a11y
20:36:05 <oedipus> RS: <adjusts screen resolution>
20:36:07 <Joshue> Joshue has joined #html-a11y
20:36:10 <MichaelC_> MichaelC_ has joined #html-a11y
20:36:17 <JF> JF has joined #html-a11y
20:37:27 <oedipus> RS: function call -- find clipping region
20:37:59 <oedipus> RS: then say setClickable Region and set that in canvas subtree -- when click in clicakble region, you would operate off DOM to get coordinates and bounding box
20:38:11 <Joshue> CS: Microsoft did a demo of <canvas> a11y yesterday in IE9
20:38:17 <oedipus> SF: focus management question -- want checkbox kbd accessible
20:38:21 <oedipus> RS: is kbd accessible
20:38:34 <oedipus> RS: now can have clicks and kbd support -- nice and clean
20:38:57 <oedipus> SF: getting method for using canvas subDOM different from dev to dev
20:38:57 <richardschwerdtfe> richardschwerdtfe has joined #html-a11y
20:39:38 <oedipus> RS: talked about CSS -- problem is transformations that canvas does -- don't have to do that with proposal
20:39:55 <oedipus> RS: worked with Charles Pritchard on this -- problem clickable region support 
20:39:59 <Zakim> -FtF
20:40:04 <oedipus> RS: whatever UA does...
20:40:14 <oedipus> <room dropped from call>
20:41:05 <Joshue> <discussion on Richs idea for new canvas API>
20:41:18 <Zakim> +??P2
20:41:35 <oedipus> RS: does all transformations without additional overhead
20:41:41 <oedipus> RS: do people like this approach?
20:41:44 <cyns> cyns has joined #html-a11y
20:41:47 <oedipus> <general approbation>
20:41:51 <MichaelC> zakim, ??P2 is FtF
20:41:51 <Zakim> +FtF; got it
20:41:56 <oedipus> RS: so can i advance this?
20:41:59 <oedipus> <yes>
20:41:59 <Joshue> +1 to Richs idea
20:42:10 <oedipus> plus 1 to advancing RS' idea
20:42:20 <oedipus> RS: problem with CSS is transformations issue
20:42:28 <oedipus> RS: limited by tools at disposal
20:42:41 <oedipus> RS: hit testing a trip down memory lane...
20:42:52 <dboudreau> dboudreau has joined #html-a11y
20:42:57 <oedipus> RS: can do before LC?  re-definig clickable regions -- bigger than a1yy
20:43:04 <oedipus> s/a1yy/a11y/
20:43:21 <oedipus> s/re-definig/re-defining/
20:44:12 <oedipus> the only one i can't hear is MikeSmith
20:44:58 <oedipus> now i can't hear anyone but Cyns
20:45:12 <oedipus> RS: click goes to first thing, then bubbles up
20:45:28 <oedipus> RS: what you click on has to start at some element, probably lowest level of DOM
20:45:52 <oedipus> RS: if MikeSmith could write up what he just said, that would be great
20:46:23 <oedipus> CS: remember computation on that level -- don't want to increase burdens
20:46:45 <MikeSmith> http://dev.w3.org/html5/spec/infrastructure.html#event-click
20:47:09 <MikeSmith> http://dev.w3.org/html5/spec/references.html#refsDOMEVENTS
20:47:18 <MikeSmith> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
20:47:29 <oedipus> Activation in HTML5: http://dev.w3.org/html5/spec/editing.html#activation
20:47:42 <oedipus> focus in HTML5: http://dev.w3.org/html5/spec/editing.html#focus
20:48:05 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
20:48:14 <oedipus> MS: what happens if have touch device?
20:48:29 <oedipus> MS: actuation method of DOM (couldn't hear)
20:48:42 <oedipus> MS: <reads from something>
20:49:34 <oedipus> RS: have to say bounds of element are defined by <unintelligible>
20:50:11 <oedipus> RS: if setClickable region, bind to that element, that section is defined based on what is associated with that element in the DOM
20:50:28 <MikeSmith> ok
20:50:35 <oedipus> RS: this is region associated with that handler
20:52:09 <oedipus> RS: if click in any of those areas, possible to hit test to get bounds
20:52:17 <oedipus> RS: if we could get text for the spec, that would be good
20:54:34 <oedipus> <scribe only getting disassociated words>
20:54:58 <oedipus> MS: event is fired as whatever elment clicked on
20:55:03 <oedipus> RS: determines what click on 
20:55:12 <oedipus> MS: what is method to capture event?
20:55:22 <oedipus> CS: if put in method to get caret <couldn't hear>
20:55:38 <oedipus> CS: if event listener catches event, does the job
20:55:55 <oedipus> RS: UA directs mouse to child -- 
20:56:16 <oedipus> <can only hear individual words>
20:56:24 <Zakim> -FtF
20:57:52 <Zakim> -Gregory_Rosmaita
20:57:53 <Zakim> WAI_(A11YF2F)11:30AM has ended
20:57:55 <Zakim> Attendees were Gregory_Rosmaita, FtF
20:59:52 <janina-lurker> janina-lurker has joined #html-a11y
21:01:51 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
21:02:23 <Zakim> WAI_(A11YF2F)11:30AM has now started
21:02:30 <Zakim> +??P0
21:02:38 <Zakim> -??P0
21:02:39 <Zakim> WAI_(A11YF2F)11:30AM has ended
21:02:39 <Zakim> Attendees were 
21:02:59 <janina-lurker> zakim, who's on the phone?
21:02:59 <Zakim> apparently WAI_(A11YF2F)11:30AM has ended, janina-lurker
21:03:00 <Zakim> On IRC I see janina-lurker, dboudreau, cyns, richardschwerdtfe, JF, MichaelC, Joshue, MikeSmith, silvia, Stevef, Zakim, RRSAgent, oedipus, [tm], trackbot
21:04:17 <Zakim> WAI_(A11YF2F)11:30AM has now started
21:04:23 <Zakim> +??P0
21:04:38 <Zakim> +Gregory_Rosmaita
21:05:27 <oedipus> RS: i'm going to associate clipping region i have to define how that object associated with that clipping area is determined <couldn't hear>
21:05:40 <oedipus> CS: whatever you bind to -- even a parent that gets clipped -- still works
21:06:06 <oedipus> RS: problem is on normal web page -- you clip, you know the DOM target, but on CANVAS, need to find a way to map that area to that object and properties
21:06:25 <oedipus> RS: layout engine does this anyway, but doesn't specify how to determine <couldn't hear>
21:06:41 <janina-lurker> zakim, who's on the phone?
21:06:41 <Zakim> On the phone I see ??P0, Gregory_Rosmaita
21:06:56 <janina-lurker> zakim, ??P0 is F2F
21:06:56 <Zakim> +F2F; got it
21:07:10 <oedipus> RS: are TF members ok with this approach?
21:07:20 <oedipus> <can't hear>
21:08:03 <oedipus> RS: even though specify rectangle, canvas doesn't take rectagle -- can use an ellipse or other more complicated shapes
21:08:20 <oedipus> RS: setClickable.Region to passive
21:08:45 <oedipus> <can't hear due to white noise>
21:08:57 <oedipus> CS: if do for anything other than rectangle what will happen?
21:09:01 <oedipus> RS: can be triangle
21:09:06 <oedipus> CS: need to define shape first?
21:09:24 <oedipus> <click where?>
21:09:50 <oedipus> RS: a11y api purposes, use rectangle or triangle
21:10:00 <oedipus> CS: if tab, going to get focus rectangle
21:10:10 <oedipus> RS: focus.screen can be circle, ellipse
21:10:19 <oedipus> <click where?>
21:10:43 <oedipus> CS: if use recatagnle to bind event handlers, how would that impact <couldn't hear>
21:10:52 <oedipus> RS: this is canvas, not "straight HTML"
21:10:58 <Joshue> s/ recatagnle/rectangle
21:11:16 <oedipus> RS: specify this using wording
21:11:35 <oedipus> RS: have to have function that says, based on viewer and DOM tree that that position is in that clicable region 
21:11:46 <oedipus> RS: pick lowest point of DOM tree that has highest lean-over
21:12:03 <oedipus> CS: how do you fix?
21:12:15 <oedipus> RS: have to have different rule for defining other than rectangle
21:12:58 <oedipus> <discussion between Cyns and RichS on canvas versus HTML and binding shapes>
21:13:11 <oedipus> <remote scribe can't hear flow of conversation>
21:14:13 <oedipus> CS: worry is getting it implemented
21:14:19 <oedipus> RS: clean way to do hit testing
21:14:51 <oedipus> RS: bind canvas to object use what have in HTML to bind object fallback content with drawing path exposed via canvas --
21:15:18 <oedipus> RS: cleanest way to support a11y API because don't have to do transformations in CSS to reproduce transformations in canvas
21:15:25 <oedipus> CS: understand RS point
21:15:31 <oedipus> CS: want it documented
21:16:10 <oedipus> RS: nothing new -- this is a "rich drawing space"
21:16:16 <oedipus> CS: can be different shapes
21:16:24 <oedipus> RS: yes -- requires author-end work
21:16:33 <oedipus> <can't hear very clearly>
21:17:37 <oedipus> <can't hear discussion>
21:17:54 <oedipus> <scribe thinks Rich and Cyns are discussing implementation issues>
21:19:21 <oedipus> <heard rich say "squiqqly">
21:19:40 <oedipus> <er, squiggly>
21:20:15 <richardschwerdtfe> can you hear me?
21:20:35 <oedipus> yes
21:20:35 <cyns> I said that moving from the html rectangle-only hit testing in browsers now to arbitrary paths may be a lot of implemenation work
21:21:22 <oedipus> RS: diff between hit testing in canvas and on HTML is largely like desktop -- do hit testing within rectangles, so is trivial thing to say whether this piont is in bounds of rectangle
21:21:54 <oedipus> RS: however, can have squiggly path that is closed, but not uniform in terms of trectangle -- finding out if click in path is more challanging -- is that going to be a problem for UA devs 
21:22:01 <oedipus> RS: currently all of that is handled by canvas author
21:22:25 <oedipus> RS: when looked at DOM event spec did not define how it knew when position within bounds of the element that you were trying to click on
21:22:50 <oedipus> RS: can have things like an option in listbox -- how do you know you are within option in list box -- send to listbox or listbox container
21:23:06 <oedipus> RS: cleaner, but redefines what is not clearly defined in DOM Events spec for how do DOM hit test
21:23:23 <oedipus> RS: no other way to do this right now --
21:23:55 <oedipus> RS: whatever shape provided, have to do "best fit" rectangle for the a11y object because only use rectangles in a11y API
21:24:21 <oedipus> CS: sounds like could be a lot of extensive implementation work -- poetentially destablizing -- expect vendors to be wary of that
21:24:36 <oedipus> RS: bring this back to discuss with Frank Oliver 
21:25:32 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
21:26:26 <Zakim> -Gregory_Rosmaita
21:37:23 <Zakim> +Gregory_Rosmaita
21:45:58 <oedipus> MichaelC, are you luring FrankO to RichS with chocolates?
21:49:50 <richardschwerdtfe> :-)
22:05:03 <oedipus> CS: what happens when canvas area is non-rectangular?
22:05:08 <oedipus> <can't hear FrankO>
22:05:50 <oedipus> CS: put click handler on canvas DOM
22:07:01 <oedipus> MichaelC, should this be minuted -- can't hear -- 2 discussions at once
22:07:21 <oedipus> RS: have method in canvas for pointing to path -- work for key order?
22:07:49 <oedipus> MC: plenary stuff for afternoon
22:10:01 <oedipus> MC: look-up table auto-generated for aria state and property looks up HTML ValueType
22:10:11 <oedipus> RS: if we define new property?
22:10:14 <oedipus> MC: regenerate it
22:10:28 <oedipus> MC: why want to externalize section of spec, so can update it indepently
22:10:52 <JF> JF has joined #html-a11y
22:11:04 <oedipus> MS: people can disagree, but don't think it is a non-starter
22:11:10 <oedipus> CS: initial resistence, perhaps
22:11:20 <oedipus> RS: don't want to waste cycles spinning own wheels
22:11:30 <oedipus> MC: need lookup table like this
22:11:33 <oedipus> MC: demand for it
22:11:45 <oedipus> RS: why not keyword enumerated values as defined by Blah
22:12:05 <oedipus> RS: i can have aria values defined as this this and this -- keyword enumerated values -- what aria defines in spec today
22:12:14 <oedipus> RS: if have space delimited token list, have another one
22:12:20 <oedipus> RS: IDREFs another type
22:12:33 <oedipus> MC: that is data lookup table would provide
22:12:54 <oedipus> MC: do you want into organized by HTML type and aria attributes that apply?
22:13:04 <oedipus> RS: want to avoid having another document
22:13:19 <oedipus> RS: in aria subsectino define diff types -- for types, here how to process
22:13:23 <oedipus> RS: whitespace 
22:13:32 <oedipus> RS: how to deal with whitespace
22:13:38 <oedipus> MC: doesn't use that term any more
22:13:47 <oedipus> RS: for IDREF, what would you call it?
22:13:52 <oedipus> MC: defined in mapping table
22:14:16 <oedipus> MC: IDREF is the value of a defined id value on another element -- most precise concept can find in HTML5
22:14:24 <oedipus> RS: so refer to IDREF, point to that
22:14:43 <oedipus> RS: don't have to id all individual attributes -- all the attributes refered to in ARIA section...
22:14:52 <JF> JF has joined #html-a11y
22:14:58 <oedipus> section 3.6.7 in current editors' draft
22:15:15 <oedipus> RS: IDREF defined in this section of the aria spec is processed as follows
22:15:18 <oedipus> MC: what have now
22:15:28 <oedipus> MC: defines what to do in HTML
22:15:36 <oedipus> RS: ok, but didn't like, because?
22:16:34 <oedipus> MC: if user agent implementor and implement ARIA state and property attributes -- hear values -- don't want substitutions or stopping because doesn't know what to do, so would have the link that takes you to the table that is intended to be generated
22:16:42 <oedipus> RS: why not just put that table in the HTML5 sperc
22:16:45 <oedipus> MC: intend to
22:17:05 <oedipus> MC: can do that -- don't know if would satisfy, 
22:17:25 <oedipus> MC: want to hear what HSivonen has to say about it -- 
22:18:01 <oedipus> RS: where do we have true/false enumerated values
22:18:13 <oedipus> RS: refer to true/false in table -- in atomic data type?
22:18:30 <oedipus> MC: <shows RS table (i think)>
22:18:39 <oedipus> RS: perfect!
22:19:10 <oedipus> RS: these are the diff types as defined in aria, this is how processed in HTML, and put the table in it
22:19:29 <oedipus> RS: put in Annotations for Assistive Technologies (ARIA) section
22:19:35 <oedipus> MC: or make informative external reference
22:19:41 <oedipus> RS: has to be processable
22:20:22 <oedipus> MC: everything specified -- do you know where to look for it
22:20:35 <oedipus> MC: do need to know spec well enough to follow a link
22:21:39 <oedipus> RS: put somewhere in this section "WAI_ARIA is a cross-cutting technology. Therefore, the actual implementation of aria must be specified for each host language. For HTML here is the implementation:"
22:22:11 <oedipus> RS: don't want to have to have any change to ARIA contingent upon any other group's processes
22:22:20 <oedipus> RS: who has change for this section?
22:22:34 <oedipus> MC: definition for role attribute
22:22:40 <oedipus> RS: primary change proposal
22:23:19 <oedipus> potential ACTION for Cooper - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal
22:24:28 <oedipus> ACTION: Cooper - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal
22:24:28 <trackbot> Created ACTION-112 - - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal [on Michael Cooper - due 2011-03-26].
22:26:31 <oedipus> RS: want to get feedback on default roles for elements in HTML5 -- do we need?  should we do a longdesc -- remotedesc?
22:26:39 <oedipus> RS: want to know what to plan for ARIA.next
22:27:35 <oedipus> RS: like to start circulating a list; would be fine if response is "we don't need anything"
22:29:35 <oedipus> <discussion of whether to intrude on media breakout group or continue with other agenda items>
22:29:52 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
22:31:43 <oedipus> MC: media group wants to continue current work
22:32:27 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
22:33:08 <oedipus> MC: timeline review and writing change proposal -- how much time?
22:33:16 <oedipus> MS: walk through of chairs' decision policy
22:33:23 <oedipus> MC: should open to everyone 
22:34:04 <Stevef> Stevef has joined #html-a11y
22:34:24 <lwatson> lwatson has joined #html-a11y
22:34:40 <Stevef> as per earlier discussion http://www.html5accessibility.com/tests/img-longdesc.html
22:34:44 <oedipus> SF: marked up some spec text for review
22:34:57 <oedipus> MC: preliminary review as sub-group
22:35:19 <oedipus> TOPIC: Longdesc Redux
22:35:26 <richardschwerdtfe> scribe: Rich
22:35:45 <richardschwerdtfe> Subject: Longdesc
22:35:46 <oedipus> scribenick: richardschwerdtfe
22:35:52 <richardschwerdtfe> Steve: we need to be conformant
22:36:09 <richardschwerdtfe> Steve: we need to be normative
22:36:21 <oedipus> http://www.html5accessibility.com/tests/img-longdesc.html
22:36:33 <richardschwerdtfe> Steve: As I said there are minor edits.
22:36:50 <MichaelC> present+ Roger_Hudson
22:37:03 <richardschwerdtfe> The text:
22:37:06 <richardschwerdtfe> The longdesc attribute may be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a separate document, a content fragment in a separate document or content fragment within the same document as the image.
22:37:07 <richardschwerdtfe> Content referenced by the longdesc attribute, if present, must be exposed by the user agent via a device independent mechanism.The user must be allowed to make a decision on whether to access the content referenced by the longdesc.
22:37:07 <richardschwerdtfe> For example, a user agent may provide access to the document or document fragment referenced by the longdesc attribute in a context menu associated with the image. In this case the context menu must be operable using the keyboard and a visible indication of longdesc presence must be provided. The option to disable visible indication and access may be provided via a user preference. 
22:38:25 <richardschwerdtfe> yw
22:38:33 <richardschwerdtfe> Cynthia: this is too strong
22:38:47 <richardschwerdtfe> Steve: it is a starting point
22:39:23 <richardschwerdtfe> More text:
22:39:24 <richardschwerdtfe> Another example is to provide an indication of the presence of a description via a programmatically associated visible button or link. The button associated with the image must be included in the default tab order of the document. The button may be hidden until an image is moused over or receives keyboard focus, then user agents must provide a visual indication and mechanism to access the associated description. Clicking on the button or pressing a 
22:39:24 <richardschwerdtfe> when the button has focus will navigate to the referenced content or provide an inline display of the referenced content. Visible indication and access may be user configurable.
22:39:45 <richardschwerdtfe> Steve: I provided an inline example using IFrame
22:40:07 <richardschwerdtfe> Cynthia: I would like to say that the visual indications are  MAYs or SHOULDs
22:40:25 <richardschwerdtfe> Cynthia: What is actually required is the way an AT can access it.
22:40:42 <richardschwerdtfe> John: What we have is ...
22:41:03 <MikeSmith> q?
22:41:13 <richardschwerdtfe> Cynthia: I am not convinced that the case for making longdesc visible is strong enough
22:42:09 <richardschwerdtfe> Mike: I think it is important that we get it available to the rest of the working group. Making it discoverable is useful. It is useful to have these examples.
22:42:33 <Stevef> http://www.html5accessibility.com/tests/img-longdesc.html
22:42:34 <richardschwerdtfe> Cynthia: all the examples of visual renderings need to be SHOULDs and NOT MUSTs 
22:42:52 <oedipus> q+ to say that longdesc simulteneous display for cognative guidance and limited viewport guidance through image / assistance in interpreting image
22:42:55 <richardschwerdtfe> Leonie: Why is it a must for one group of disabilities but not another
22:43:12 <richardschwerdtfe> Cynthia: I am not convinced that the example is a strong use case
22:43:36 <richardschwerdtfe> Steve: Having the provision of content in text form is good for some users.
22:43:47 <richardschwerdtfe> John: we do not have data. 
22:43:57 <MikeSmith> q?
22:44:17 <richardschwerdtfe> John: The WhatWg has stated that not having a visual indicator is a problem
22:44:29 <richardschwerdtfe> ack oedipus
22:44:29 <Zakim> oedipus, you wanted to say that longdesc simulteneous display for cognative guidance and limited viewport guidance through image / assistance in interpreting image
22:44:36 <MikeSmith> q+ Stevef 
22:45:01 <richardschwerdtfe> oedipus: Did you not find users with a very limited viewport a valid viewport?
22:45:13 <JF> JF has joined #html-a11y
22:45:17 <richardschwerdtfe> Cynthia: I believed that was hypothetical
22:45:36 <lwatson_> lwatson_ has joined #html-a11y
22:45:38 <oedipus> no, not hypothetical -- we have extensively courted feedback on that
22:45:50 <richardschwerdtfe> Steve: users don't know it would be possible
22:45:58 <oedipus> especiaally in the case of graphs and charts
22:46:10 <MikeSmith> ack Stevef 
22:46:15 <richardschwerdtfe> Roger: It is a valid use case for low vision users who can't see the whole graph to be exposed to the text
22:47:01 <richardschwerdtfe> Steve: I put MUSTs in the chart so that we can roll backward. Don't be overly concerned about that. If the sort of features that we are talking about here the way we want to go.
22:47:20 <lwatson> lwatson has joined #html-a11y
22:47:41 <richardschwerdtfe> Steve: Should we expose URL through the description field in the accessibility API
22:48:03 <richardschwerdtfe> correction: Cynthia said that
22:48:29 <richardschwerdtfe> Steve: The NVDA guys said we should not have to expose this. It should be exposed via the browser.
22:49:44 <oedipus> i agree with NVDA dudes -- it SHOULD be exposed by the browser, but (in the words of WCAG 1.0) "until User Agents support..."
22:50:07 <richardschwerdtfe> Rich: I am not a big longdesc fan, but my concern is that users with cognitive impairments will need  to see the longdesc text.
22:50:19 <lwatson_> lwatson_ has joined #html-a11y
22:50:44 <richardschwerdtfe> Cynthia: not many sites use longdesc
22:50:54 <richardschwerdtfe> John: ... create more longdescs
22:50:58 <oedipus> cyns, it depends upon your definition of the term "use"
22:51:14 <richardschwerdtfe> Cynthia: My point is that script can be used by the author to expose the longdesc
22:51:20 <oedipus> longdesc is there, some mandate it, all want to use it, so let's get off the fence and support it
22:51:23 <MikeSmith> RRSAgent, make minutes
22:51:24 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html MikeSmith
22:51:31 <richardschwerdtfe> Cynthia: this might be better if the author does it
22:51:55 <richardschwerdtfe> John: I said earlier that I don't think MUST is going to fly but I would like to see a SHOULD or SHOULD+
22:52:04 <MikeSmith> q?
22:52:13 <richardschwerdtfe> John: but if this is the problem here is how to fix the problem
22:52:35 <oedipus> easiest fix is to "restore" longdesc -- it doesn't take any work --unlike removing it
22:53:42 <richardschwerdtfe> John: the argument we are getting is that there needs to be a way of describing longdesc info to sigted users
22:56:03 <richardschwerdtfe> Content referenced by the longdesc attribute, if present, should be exposed by the user agent via a device independent mechanism.The user should be allowed to make a decision on whether to access the content referenced by the longdesc.
22:57:02 <richardschwerdtfe> For example, a user agent may provide access to the document or document fragment referenced by the longdesc attribute in a context menu associated with the image. In this case the context menu should be operable using the keyboard and a visible indication of longdesc presence should be provided. The option to disable visible indication and access may be provided via a user preference. 
22:57:11 <oedipus> from what i hear, it sounds as if it conforms to the verbose desc reqs! <wink>
22:57:34 <cyns> cyns has joined #html-a11y
22:58:49 <richardschwerdtfe> Another example is to provide an indication of the presence of a description via a programmatically associated visible button or link. The button associated with the image must be included in the default tab order of the document when present. The button may be hidden until an image is moused over or receives keyboard focus, then user agents should provide a visual indication and mechanism to access the associated description. Clicking on the button
22:58:49 <richardschwerdtfe> pressing a key when the button has focus will navigate to the referenced content or provide an inline display of the referenced content. Visible indication and access may be user configurable.
22:59:05 <oedipus> if a user agent is set to receive keyboard focus for @longdesc, then it MUST add the element for which the @longdesc was defined to the document's tab navigation order
22:59:30 <richardschwerdtfe> Steve: where should that go?
22:59:36 <oedipus> it can go at the end, can't it?
22:59:47 <oedipus> thanks steve
22:59:50 <MikeSmith> q?
23:00:13 <cyns> Another example is to provide an indication of the presence of a description via a programmatically associated visible button or link. <ins> when present</ins> The button associated with the image must be included in the default tab order of the document when present. 
23:00:30 <dboudreau_> dboudreau_ has joined #html-a11y
23:00:59 <dboudreau> dboudreau has left #html-a11y
23:01:00 <cyns> Another example is for the browser to add the longdesc to the accessibiity API such that AT can access it and expose it to users.
23:01:12 <dboudreau> dboudreau has joined #html-a11y
23:01:29 <oedipus> need to cover those using AT and those not using AT but for whom the longdesc would be beneficial
23:02:00 <richardschwerdtfe> Steve:  mouse over may provide a button to click
23:02:44 <richardschwerdtfe> Steve: I don't have a problem providing an example of how it should work
23:03:05 <richardschwerdtfe> Cynthia: I am fine with that but specifying the UI is not our job
23:03:14 <richardschwerdtfe> MIke: what's next?
23:03:33 <dboudreau> dboudreau has joined #html-a11y
23:03:34 <richardschwerdtfe> Rich: Do you want to put a change proposal in?
23:03:53 <richardschwerdtfe> Rich: Start writing a change proposal for it
23:04:15 <richardschwerdtfe> Cynthia: Put this stuff in the change proposal
23:04:34 <richardschwerdtfe> Steve: I said to Laura we needed a more robust mechanism for this
23:04:54 <oedipus> discoverable versus hidden metadata
23:04:54 <Stevef> oedipus: no problem
23:05:30 <richardschwerdtfe> Action: Steve create a change proposal for longdesc that includes example of how a user agent might render longdesc information
23:05:30 <trackbot> Created ACTION-113 - Create a change proposal for longdesc that includes example of how a user agent might render longdesc information [on Steve Faulkner - due 2011-03-26].
23:05:36 <oedipus> rich's wording sounds to me as if it would be more palatable to the HTML WG
23:06:16 <MikeSmith> q?
23:06:41 <MikeSmith> http://dev.w3.org/html5/status/issue-status.html
23:07:26 <richardschwerdtfe> Topic: Open Issues
23:07:59 <richardschwerdtfe> scribe: Leonie
23:08:19 <lwatson> scribe, lwatson
23:08:38 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
23:09:09 <oedipus> scribenick: lwatson
23:09:14 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
23:09:30 <silvia1> silvia1 has joined #html-a11y
23:09:40 <MikeSmith> MikeSmith has joined #html-a11y
23:09:43 <dboudreau_> dboudreau_ has joined #html-a11y
23:10:47 <JF> JF has joined #html-a11y
23:10:50 <MichaelC> MichaelC has joined #html-a11y
23:10:54 <MikeSmith> regarding issue 31, http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformaceChoices gives a really good overview of the differences among the various change proposals
23:11:40 <MichaelC> action: Cynthia to work with Steve and go through decisions from Lyon and document them regarding HTML-ISSUE-31
23:11:41 <trackbot> Created ACTION-114 - Work with Steve and go through decisions from Lyon and document them regarding HTML-ISSUE-31 [on Cynthia Shelly - due 2011-03-26].
23:11:49 <richardschwerdtfe> richardschwerdtfe has joined #html-a11y
23:12:03 <lwatson> MC: Issue 32, table summary.
23:12:16 <lwatson> CS: Did that get escalated?
23:12:30 <lwatson> MC: It's in the hands of the chairs, so I think there's othing for us to do now.
23:12:48 <lwatson> MC: Issue 80, title alternative. In chair's hands.
23:13:08 <lwatson> SF: It's been with them for ages hasn't it?
23:13:51 <lwatson> MC: Issue 92, clean up table.
23:13:52 <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
23:13:59 <lwatson> MS: Done.
23:14:21 <oedipus> i have action to comment on poll for ISSUE 122
23:14:24 <MikeSmith> http://dev.w3.org/html5/status/issue-status.html
23:14:28 <oedipus> on behalf of HTML A11y TF
23:16:10 <lwatson> MC: Issue 131, canvas text.
23:16:33 <lwatson> MS: Deadline is 22nd to modify the hange proposal.
23:16:45 <lwatson> s/hange/change/
23:17:23 <lwatson> MS: One thing we should discuss is whether we're happy with this change proposal.
23:17:51 <lwatson> MC: Was this subitted in a hurry?
23:18:09 <lwatson> RS: We have the bounding rectangle, but it doesn't necessarrily apply to this.
23:18:50 <lwatson> RS: We took out references to rich text, so we're not saying "go do rich text".
23:19:23 <lwatson> MS: If there are no cunter proposals, we need to adopt this.
23:19:37 <lwatson> MC: Issue 133, modal dialogues.
23:19:52 <lwatson> MC: Do we want this and do we like what's here?
23:20:00 <oedipus> i am proposing the modal dialog for ARIA.next
23:20:13 <lwatson> RS: What we need is a dialogue element that specifies modal.
23:20:29 <oedipus> s/dialogues/dialogs/
23:20:31 <lwatson> MC: Is there anything besides a dialogue that could be modal?
23:20:41 <lwatson> SF: Yes.
23:21:04 <lwatson> RS: I would like to have the use cases enumerated here.
23:21:22 <lwatson> SF: You can have fall back as well. If your JS isn't working for example.
23:21:44 <lwatson> CS: This is a post last call issue.
23:22:11 <MichaelC> action: Schwerdtfeger to review ISSUE-133 and consider whether a refined (counter) proposal needs to be submitted
23:22:11 <trackbot> Created ACTION-115 - Review ISSUE-133 and consider whether a refined (counter) proposal needs to be submitted [on Richard Schwerdtfeger - due 2011-03-26].
23:22:37 <lwatson> MC: Issue 124, tab states.
23:22:48 <lwatson> s/124/134/
23:23:00 <oedipus> might be affected by ARIA-in-HTML decision
23:23:19 <oedipus> cooper is correct
23:23:28 <lwatson> MC: this is creating native attribs that are like ARIA attribs.
23:23:56 <lwatson> RS: I don't like tabbing through a tab panel, or tabbing through a menu.
23:24:11 <MikeSmith> q?
23:24:14 <lwatson> MC: This is attempting to allow menus to be defined as tablists.
23:24:19 <oedipus> borrowing concepts from ARIA for HTML5 -- might be OBE by ARIA-in-HTML decision
23:24:33 <MikeSmith> Zakim, clear queue
23:24:33 <Zakim> I don't understand 'clear queue', MikeSmith
23:25:03 <lwatson> MC: So we support the change proposal.
23:25:10 <lwatson> RS: Give me an action to review this one.
23:25:11 <oedipus> q- excellent
23:25:19 <oedipus> q- he, said, tenting
23:25:20 <MikeSmith> q=
23:25:30 <MikeSmith> q?
23:25:54 <lwatson> SF: If something has a modal attrib, it's default role could be dialogue.
23:26:20 <oedipus> s/default role could be dialogue./default role could be dialog/
23:26:25 <lwatson> SF: We should have a discussion as to whether it should be an element or an attribute.
23:27:56 <MichaelC> action: schwerdtfeger to review ISSUE-134
23:27:56 <trackbot> Created ACTION-116 - Review ISSUE-134 [on Richard Schwerdtfeger - due 2011-03-26].
23:29:02 <lwatson> MC: MC: Issue 135, link canvas spec.
23:29:41 <lwatson> MC: Looks like there has been a call for consensus amongst the chairs on this.
23:30:17 <lwatson> MC: Issue 142, poster alt.
23:30:30 <lwatson> JF: The poll closed, and we have two change proposals.
23:30:53 <lwatson> JF: It's waiting for the chairs. 
23:30:58 <oedipus> http://www.w3.org/2002/09/wbs/40318/issue-142-objection-poll/results
23:31:49 <lwatson> MC: Issue 144, underlining <u>
23:31:58 <lwatson> CS: No harm to make it conforming.
23:32:13 <oedipus> presentational elements should be only conforming with a warning -- USE CSS!!!
23:32:28 <lwatson> s/underlining/conforming/
23:33:04 <lwatson> MC: Issue 147, playback rate undefined.
23:33:13 <lwatson> JF: Doesn't affect us much.
23:33:40 <lwatson> MS: We should get Sylvia's input on this.
23:34:16 <MichaelC> agenda+ review HTML-ISSUE-147 with media sub-group
23:36:19 <lwatson> MC: Issue 153, link external.
23:37:11 <lwatson> MC: Issue 155, cell border.
23:37:26 <lwatson> MS: I've read through this but not sure I fully understand it.
23:38:04 <lwatson> CS: Don't think it's an accessibility issue.
23:38:55 <lwatson> MC: Issue 161, accessibility API mapping.
23:39:01 <lwatson> CS: We need to do some work there.
23:39:24 <lwatson> SF: It's just to add a link in there.
23:39:58 <lwatson> MC: Issue 163, navigating tracks
23:40:16 <lwatson> JF: We're discussing this tomorrow.
23:41:14 <lwatson> MC: The bug triage sub team hasn't seen any bugs it needs to take a look at.
23:41:37 <oedipus> i am in contact with others in w3c about bugzilla 4.0 a11y improvements and those that still need to be logged on bugzilla's bugzilla
23:42:06 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
23:42:19 <lwatson> MC: There are five bugs...
23:42:45 <lwatson> MC: 10249, canvas requires a content selection method, assigned to RS.
23:43:24 <lwatson> MC: It needs expanding, or closed.
23:43:38 <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10249
23:44:05 <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10896
23:44:18 <lwatson> MC: 10896, enable device independent access to event handlers, filed by LW.
23:45:01 <oedipus> hixie said that he thought it more appropriate for the DOM / WebApps / WebEvents group for DI access to event handlers
23:45:34 <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/event_handler_requirements
23:45:37 <lwatson> MC: 11328, canvas authors need to be able to assess pixel resolution, filed by RS.
23:46:10 <lwatson> CS: Assign it to Doug, he should be able to find someone to look at it.
23:47:36 <lwatson> MC: 11329, HTML5 supporting browsers must support resize event during zoom, filed by RS.
23:48:25 <lwatson> MC: It's been assigned to Web Apps WG, is that the right place?
23:48:43 <lwatson> JF: Is this a TF concern?
23:49:01 <lwatson> CS: Yes, it relates to zoom.
23:49:40 <lwatson> MC:11391, provide examples of track usage, filed by FO.
23:50:47 <lwatson> MS: This would make the track element usable for additional audio tracks.
23:51:06 <lwatson> JF: So this is related back to issue 152.
23:51:28 <lwatson> JF: Think I may have reported this back to Martin a couple of weeks ago.
23:51:49 <lwatson> JF: Think I may have reported this back to Martin a couple of weeks ago.?
23:52:51 <lwatson> MC: So here's nothing else to do on this right now?
23:53:30 <oedipus> we could look at http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
23:54:38 <MichaelC> action: foliot to raise Bug 11391 with media sub-team
23:54:38 <trackbot> Created ACTION-117 - Raise Bug 11391 with media sub-team [on John Foliot - due 2011-03-26].
23:56:19 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
23:56:42 <lwatson> MC: We needed to do a review of the whole spec, but this could be a PF action as opposed to a TF action.
23:57:37 <lwatson> MC: The idea was to start writing WCAG techniques as a mechanism for discovery.
23:58:30 <lwatson> MC: Nothing for us to do on spec review right now.
00:00:13 <lwatson> MS: It looks as though we don't have any outstanding actions on drag/drop anymore.
00:00:24 <mkobayas> mkobayas has joined #html-a11y
00:01:52 <lwatson> SF: Gez and Everett looked at the spec and seemed not to have furter concerns.
00:02:37 <lwatson> RS: What happens if ARIA is used with respect to HTML5 drag/drop? Could we ask Gez to look into this?
00:02:40 <MichaelC> action: Lemon to review if HTML drag and drop model conflicts with ARIA drag and drop model
00:02:40 <trackbot> Created ACTION-118 - Review if HTML drag and drop model conflicts with ARIA drag and drop model [on Gez Lemon - due 2011-03-27].
00:04:27 <oedipus> [ADJOURNED]
00:04:30 <lwatson> MS: Meeting adjourned.
00:04:42 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/19-html-a11y-minutes.html oedipus
00:19:30 <Zakim> -F2F
00:19:36 <Zakim> -Gregory_Rosmaita
00:19:38 <Zakim> WAI_(A11YF2F)11:30AM has ended
00:19:40 <Zakim> Attendees were Gregory_Rosmaita, F2F
00:19:46 <Zakim> Zakim has left #html-a11y
00:23:59 <RRSAgent> I see 8 open action items saved in http://www.w3.org/2011/03/19-html-a11y-actions.rdf :
00:23:59 <RRSAgent> ACTION: Gregory  - submit comments on behalf of TF to http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ - due 2011-03-24 [1]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T16-38-02
00:23:59 <RRSAgent> ACTION: Cooper - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal [2]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T22-24-28
00:23:59 <RRSAgent> ACTION: Steve create a change proposal for longdesc that includes example of how a user agent might render longdesc information [3]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T23-05-30
00:23:59 <RRSAgent> ACTION: Cynthia to work with Steve and go through decisions from Lyon and document them regarding HTML-ISSUE-31 [4]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T23-11-40
00:23:59 <RRSAgent> ACTION: Schwerdtfeger to review ISSUE-133 and consider whether a refined (counter) proposal needs to be submitted [5]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T23-22-11
00:23:59 <RRSAgent> ACTION: schwerdtfeger to review ISSUE-134 [6]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T23-27-56
00:23:59 <RRSAgent> ACTION: foliot to raise Bug 11391 with media sub-team [7]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T23-54-38
00:23:59 <RRSAgent> ACTION: Lemon to review if HTML drag and drop model conflicts with ARIA drag and drop model [8]
00:23:59 <RRSAgent>   recorded in http://www.w3.org/2011/03/19-html-a11y-irc#T00-02-40