W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2011

minutes: HTML Accessibility TF March 2011 Face2Face Day 1 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Sun, 20 Mar 2011 00:21:14 +0000
To: public-html-a11y@w3.org
Cc: gez.lemon@gmail.com
Message-Id: <20110320002004.M28753@hicom.net>
aloha!

minutes for the first day of the HTML Accessibility Task Force
plenary meeting are available at:

http://www.w3.org/2011/03/19-html-a11y-minutes.html

as an IRC log at:

http://www.w3.org/2011/03/19-html-a11y-irc

and as plain text following this announcement -- note that the 
media breakout session's minutes are located at:

http://www.w3.org/2011/03/19-media-minutes.html

thanks to all who scribed in both channels, gregory.

     _________________________________________________________

                               - DRAFT -

             HTML Accessibility Task Force Teleconference

19 Mar 2011

Agenda: http://www.w3.org/WAI/PF/HTML/ftf_2011-03

   See also: IRC log - http://www.w3.org/2011/03/19-html-a11y-irc

Attendees

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

   Regrets
   Chair
          Janina_Sajka, MikeSmith

   Scribe
          lwatson, Joshue, Gregory_Rosmaita, Rich, Leonie

Contents

     * Topics
         1. Text alternatives
         2. Longdesc
         3. ARIA Lexical Processing
         4. CANVAS
         5. Longdesc Redux
         6. Open Issues
     * Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 19 March 2011

   <richardschwerdtfe> Hi Gregory

   <dboudreau> hi everyone

   <dboudreau> greg! ça va bien?

   <Zakim> oedipus, you wanted to ask if breakout session will use
   #html-a11y-media or #html-a11y-2 ?

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

   <lwatson> scribe: lwatson

   <oedipus> scribenick: lwatson

   <oedipus> need both longdesc (external reference) and describedby
   (in-document reference)

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

   <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

   <oedipus> central control over images and image description

Text alternatives

   SF: Issue 30 is being surveyed ATM.

   JS We have given our recommendations on 80, 122 and 31.

   <oedipus> lady of shallot:
   http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/

   JS: The question is whether we're satisfied with this, and whether
   the right supporting points have been made?

   <oedipus> GJR's change proposal is survey question 3

   <oedipus>
   
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

   <oedipus> TF proposal from TPAC:
   
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

   <oedipus>
   http://www.w3.org/html/wg/wiki/ChangeProposals/thematicimages

   <oedipus> GJR's proposal reflects consensus reached at TPAC 2010 F2F
   of A11y TF

   <oedipus> TF proposal from TPAC:
   
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

   SF: There is a response from me because the riginal bug was filed
   against the alt text document, that required a change proposal.
   ... The chairs wanted to widen the scope, so the same message was
   given across the spec and the alt text document.

   <oedipus> lady of shallot issue statement:
   http://www.w3.org/html/wg/tracker/issues/122

   <oedipus> HTML WG ACTION 195 (propose replacement text)
   http://www.w3.org/html/wg/tracker/actions/195

   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.
   ... It shouldn't be mandidated that you can't provide an alternative
   text.

   RS: You have short names and long descriptions. There are different
   vehicles for providing the short.

   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.

   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.

   SF: The alt text document was developed to counter the normative
   advice given within the spec.

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

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

   SF: If we move the alt text doc out to WCAG, we need a pointer
   within the HTML5 spec.

   <oedipus> steve, that is what my CP provides

   SF: The main issue I'm concerned about, is that the advice in the
   HTML5 spec is not authoratative.

   <oedipus> HTML5 should point to WCAG as per my change proposal

   <oedipus>
   
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

   SF: Text alternatives are for more than people with disabilities.

   JF: It's not who benefits, but where the guidance comes from.

   SF: I would be more than happy if the guidance was maintained
   outside of the HTML5 spec.

   RS: When you put alt="" the spec should advice what the UA does with
   it.

   <dboudreau> I agree with you Greg. There should be a direct link
   from the spec to WCAG

   SF: It' the normative authoring advice that needs looking at.

   RS: If an image has role=presentation should the rendering be the
   same?

   SF: Alt="" should be the same as role=presentation.

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

   <oedipus> my objection to role="presentation" was based on the fact
   that HTML5 lacked a role attribute -- now we have one, no?

   <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

   RS: We could propose advice for UA as to what should happen when
   images are turned off.

   <richardschwerdtfe> yes, we will have a role attribute after our
   discussion today. ... lexical processing of ARIA section

   <oedipus> then i'm ok with role="presentation"

   <Joshue> I think we turned a wrong corner when there couldn't even
   be a consensus that image would have the role="image".

   <oedipus> CP for definition of image (also agreed-to at TPAC 2010:
   
http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_defi
nition_of_img

   <oedipus>
   
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

   MS: Not sure what Laura's position on this actually is. It would be
   good if she could join the call.

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

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

   <Joshue> We meaning them (sic) and us (sic)

   MS: Perhaps we should postpone discussion on this until Laura is
   here.

   JB: We probably souldn't hold up progress on this, as Laura may not
   be able to make it.

   <MikeSmith>
   http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/results

   <MikeSmith>
   http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/

   <MikeSmith> heh

   JS: We previously voted GJR's proposal.
   ... Which leaves a second question of where this document/guidance
   lives.

   <oedipus> correct -- we decided at TPAC what to say, and i was
   tasked to write it up as a ChangeProposal

   SF: We were previously talking about role=presentation. James Craig
   says this isn't appropriate, as per the ARIA spec.

   JC: Is this just about where this document lives?

   <Joshue> -q

   CS: So the TF has a position on which position we go with?

   <oedipus> can someone type cyns' question into IRC

   <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 [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action01]

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

   JS: Is there anything else we need to say here on alt, before we
   move on?

   <MikeSmith> yep

   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.

   SP: If someone has a decorative image, what's the recommended
   approach?

   <oedipus> Stevef, what additions do you deem necessary to the change
   proposal for 122?

   JF: It's a contextual answr, given in some detail in the spec.

   <oedipus> GJR proposal says: if purely decorative, use CSS; if can't
   use CSS, consult WCAG 2.0

   SF: If it's purely decorative, then give it a null alt.

   <oedipus> if purely decorative, use CSS to embed image

   <JF> http://www.w3.org/TR/wai-aria/roles#presentation

   <dboudreau> http://www.w3.org/TR/wai-aria/roles#presentation

   <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

   RS: role=presentation seems cleaner to me.

   JF: We'll need to keep alt="" for backwards compatibility.

   CS: We'll need both for at least the next five years or so.

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

   DB: Is there a risk to using role=presentation that we'll need to
   use role=information for images that are not decorative?

   JS: It's presumed, so we probably wouldn't need to.

   CS: That was a point of contention at one point, but has since been
   settled.

   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.

   JS: What's the advice going forward?

   SF: That *is the advice, and we haven't questioned this so far.

   <Zakim> oedipus, you wanted to ask why aren't we saying use CSS to
   control purely decorative images?

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

   GJR: Why are we saying use CSS to control purely decorative images?
   ... We should say use CSS for decorative images full stop.

   DB: You can't always do that.

   <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
   markusp of the document."

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

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

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

   <oedipus> dboudreau, the second paragraph says, if you cannot use
   CSS, then consult Alt Techs and WCAG 2.0

   JS: We're dicussing issue 80 ATM.
   ... We have guidance on 80, the question is whether we stand by
   this?

   <MikeSmith> ack oedipus
   http://www.w3.org/html/wg/tracker/issues/80

   JS: We were against using title, if alt wasn't provied

   SF: Don't think there has been any disagreement on this, and we had
   a poll as well.

   <Joshue> ISSUE-80 http://www.w3.org/html/wg/tracker/issues/80

   <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

   <MikeSmith> http://www.w3.org/html/wg/tracker/issues/80

   <oedipus> dboudreau, yes, definitely --

   MS: Issues 80 and 31 are waiting for the chairs.

   JS: Do we need to revisit this?

   <oedipus> which CP:
   http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 ??

   CS: Our position has been stated, but issue 31 hasn't ben polled. Do
   we know what the TF position is?

   SP: That label isn't a good substitute for alt?

   MS: There are a buch of change proposals for issue 31.

   SF: We decided to put forward option 3 (perhaps 2) on this.

   MS: Laura wasn't in agreement with this. Would be good to have her
   input here on this.

   <oedipus> SteveF, you are talking about
   http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 
   right?

   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.

   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.

   SF: What should the exception be if you don't have an alt attribute
   on an image?

   MS: In terms of the conformance/validator, what should be an
   acceptable substitute?

   <oedipus> hixie's change proposal for Issue 80 and Issue 31:
   http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html

   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.

   JF: Did we have agreement with that?

   SF: Yes, I think we do.

   JS: We've discussed this sevral times and have always arrived at the
   same place. We should mntion this in the survey.

   <MichaelC> HTML meeting in Lyon
   http://www.w3.org/2010/11/04-html-wg-minutes

   SP: How does aria-labelledby and title fit into this?

   SF: The consensus was that title shouldn't be considered a
   conforming image, as far as the provision of a text alternative
   goes.

   DB: Is that because ATs don't support both?

   CS: We feel it's the right way to do it.

   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.

   JF: When IE started putting tooltips in, the attribute values were
   often duplicated causing information to be doubled up with some ATs.

   <oedipus> @title often contains useful metadata (file type, size,
   etc.)

   CS: In the Lyon/TPAC minutes I can't find an agreement.

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

   <oedipus> but need to have a query for title and aria-label

   <dboudreau> another problem with @title is that it's a hover effect
   only (tooltip) therefore useless when using the keyboard only and on
   mobile

   <oedipus> dboudreau, agreed

   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.

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

   CS: Alt is rendered as a place holder, aria-label isn't.

   <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

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

   <trackbot> Sorry, couldn't find user - Steven

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

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

   <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

   <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

   SP: So I'm supposed to use alt as an author, and ignore the rest?

   CS: No, they're different things for different situations.

   <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

   RS: When you write the overview, could you include somethig about
   using aria-label?

   <dboudreau> so while i do like it, i don't think it will be useful
   or helpful enough for the end user

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

Longdesc

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

   <dboudreau> greg, i fail to see how this would prevent authors from
   abusing both attributes with the same value

   JS: There are two questions... Where and what. Let's take them in
   reverse order.

   <oedipus>
   
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Req
uirements_for_HTML5

   JS: I suspect there is consensus within the TF to get longdesc back
   in the spec.

   <oedipus> laura's longdesc research:
   http://www.d.umn.edu/~lcarlson/research/ld.html

   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.

   <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

   <oedipus> dboudreau, either that or threaten the author with "cruel
   and unusal punishment"

   JF: Several browser vendors have epressed an interest in creating a
   visual indicator plugin of some kind.

   s/rpressed/expressed/

   <oedipus> tools that support LONGDESC:
   http://www.d.umn.edu/~lcarlson/research/ld.html#tools

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

   <oedipus>
   
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Implementation_Infor
mation_for_LONGDESC

   <oedipus> dboudreau, my idea would only work with additions to WCAG,
   ATAG and UAAG (expose all metadata)

   JF: If the browsers themselves can't close the loop, perhaps ATs
   will
   ... If the browsers themselves can't close the loop, perhaps ATs
   will?

   JB: Can you give some examples of the use case for a visual
   indicator?

   <Joshue> I agree with Judy about use of a @longdesc plugin..not mad
   about the idea.

   <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

   JF: People with disabilities that mean they would benefit from the
   additional information held in a longdesc.

   <oedipus> longdesc exposure and exposition should NOT be an AT
   thing, but a UA thing

   <Joshue> +1 to GJR

   JB: Browser plugins seem like a comprimised way of dealing with
   this.

   <oedipus>
   http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Use_Cases

   <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

   <oedipus> dboudreau, amen, brother!

   JB: How much as the TF looked into the use cases?

   <Joshue> Longdesc shouldn't be a second class citizen in the
   browser.

   <oedipus> plus 1 to JOC

   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.

   <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

   RS: Rather than a plugin, have you asked the browsers about an
   option within the settings?

   <Joshue> A configurable option in the browser isn't a bad idea. +1
   to RS.

   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.

   <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

   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.

   <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

   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 most benefit from the functionality.

   <oedipus> UA needs to allow users to add images with longdesc to the
   tab navigation order for the page

   <Joshue> +q

   RS: Let's put the use case together and explain that the UA should
   provide a visual indicator.

   <oedipus> visual indicator should be an option not a requirement or
   default setting

   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.

   <oedipus> author can assist with CSS applied to image with longdesc

   <dboudreau> Laura's research on londgesc is 121 printed pages long.
   How much stronger does our use case really needs to be?

   MS: The issue is whether longdesc should be conforming. It will
   still work, it just won't validate.

   <oedipus> dboudreau, i've been wondering that myself

   <Joshue> -q

   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 browsers. We'll have the same thing with longdesc.

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

   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.

   SF: I agre, but we won't get a "must" in there.
   ... 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.

   <oedipus> visual indicator should be an option not a requirement or
   default setting

   JB: This isn't going to be something that gets unanimous consent. We
   need to articulate what we need clearly.

   JF: We'll get "should", but probably not "must".

   <oedipus> UA MUST provide access to and indication of LONGDESC, but
   a visual indicator SHOULD be an option not a requirement or default
   setting

   JB: That may not be the case. It may need to be an override.
   ... 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.

   RS: Would the IE team be open to the idea of a visual indicator?

   <oedipus> yes, rich, but not by definitionault

   CS: I'm not on the IE team, so can't speak for them, but it may be a
   challenge.

   <Stevef> oedipus: can you point me to your long description wiki
   page?

   <oedipus> SteveF, which the verbose descriptoin reqs or the original
   HTML WG page on longdesc?

   EC: Same thing for Safari. The feedback from users is to put less
   chrome in front of us.

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

   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.

   JB: So it wouldn't interfere with the chrome?

   <oedipus> http://www.w3.org/html/wg/wiki/LongdescRetention

   <Joshue> -q

   RS: EC, do you have a notion of whether a plugin might e considered
   by Apple/Safari?

   JS: Does this need to be a user action, the browser could action an
   auto-download.

   CS: That opens up questions over security.

   <Zakim> oedipus, you wanted to say as a reminder -- longdesc is a
   "make or break" issue for EPUB 3.0 compatibility with HTML5

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

   <oedipus> i can't hear you either -- put comments into IRC

   GJR: There is some urgency on this. The important thing is that ePub
   badly wants longdesc in HTML5.

   <oedipus> judy, yes, i'll get URI

   JB: That's the same reference as in the Diagram Project letter.

   DB: Usually when you can't find agreement, you need to look at it on
   different levels, not just technical.

   JB: Yes, it is being looked at on multiple levels.

   <oedipus> G Freid on behalf of DIAGRAM project to HTML WG Chairs:
   http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html

   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.

   <oedipus> s/Fried/Freed/G

   DB: I'm not sure we'll get it through using the usual channels.

   JB: We do need to respond to the points that were raised, and to
   justify very clearly out position.

   JF: It seems to me we've covered most of this withour change
   proposal, is there more we can add to this?

   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.

   JF: We need to address the fact that longdesc will throw a
   validation error.

   <oedipus> what is justification for opposing restoration of
   longdesc? i mean the REAL justification....

   SF: That's actually a very small change.

   JB: My impression is that more was needed for clarity. Does Laura's
   prposal include everything we need?
   ... The chair's impression seems to be that not everyone within the
   TF even agrees about restoring longdesc. Removing that confusion
   would give clarity.

   JF: We;ve covered longdesc at previous F2F meetings.

   SF: What we have unanimity on is that there needs to be a dedicated
   method to providing a long description.

   <oedipus> HTML5 lacks a verbose descriptor mechanism (HTML bug
   10052) includes requirements:
   http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

   JB: The technical proposal needs to be the best we can do, and this
   opens up other options for how its followd through.

   <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

   <Zakim> oedipus, you wanted to ask if describedby will be simply
   describedby or aria-describedby?

   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.

   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.

   <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

   <oedipus> i'm ok with discussing later

   SF: As far as ePub is concerned, what is their requirement? Do they
   require a specific method for providing long description?

   <oedipus> SteveF, yes

   <dboudreau> greg, if we removed the aria prefix, wouldn't it cause
   confusion? using describedby in html5 and aria-describedby in any
   other language?

   <Joshue> A good question is to try and understand why is there the
   opposition to longdesc in HTML5 in the first place.

   JB: Their primary concern is that longdesc is gone, after a decade
   or more of support.

   <oedipus> SteveF, DIAGRAM/EPUB request
   http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html

   <MikeSmith> let's take a break in 5 minutes or so

   SF: So simply making it a conforming attribute would be sufficient
   for ePub?

   <Joshue> +1 to MS

   <oedipus> dboudreau, good point, but if aria is included as part of
   HTML, then the aria- prefix doesn't make sense

   <oedipus> in the HTML context, that is

   <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

   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,

   <oedipus> joshue, bogus web-usage statistics

   <Joshue> db, yes I know that but its not a good enough reason IMO

   SF: If it were brought back to conforming, there would be lots of
   way to look at the rest and create proofs of concept.

   <oedipus> plus 1 to SF

   <Joshue> oedipus, lol. He who makes the stats makes the rules..

   <dboudreau> removing @longdesc based on this is pretty much like
   saying we should remove h1 because most authors use <p
   class="pageTitle">

   <Joshue> +q

   SF: It's the semantic indication that there is a longdesc, the
   mechanics are open.

   <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

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

   <oedipus> ...a page

   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.

   JS: Are we generally agreed with this proposal, to take it as a
   first last call issue?

   +1

   <dboudreau> +1

   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.

   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?

   RRS: I was a dissenter, but I'm happy to go with the flow.

   <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

   <oedipus>
   
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Req
uirements_for_HTML5

   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

   <oedipus>
   
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Reinstate_longdesc_a
nd_Add_a_Native_describedby_Attribute

   <oedipus> Judy, a lot of this discussion was held up until the
   ARIA-in-HTML decision was issued

   <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

   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.

   <Joshue> +1 to GJR, right on.

   <oedipus> i can't speak on EPUB's behalf without pinging at least
   marku

   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.

   <oedipus> thanks, janina

   JS: I understand ePub's concerns, we're often asked to hurry alog
   because people need/want to use our specs.

   <Joshue> -q

   <dboudreau> -q

   <oedipus> many thanks to leonie for minuting

   <MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2011-03

   <Joshue> Scribe: Joshue


ARIA Lexical Processing

   RS: There were couple of topics refs to role model, we have to say
   where role is defined.

   MC: Or define it in that section, I would like role to be a global
   att

   <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

   RS: Ok

   MC: If not we can define in the proposed section.

   RS: You want to define it in just ARIA

   MC: I don't think the HTML 5 wants to.

   <oedipus> plus 1 to MCooper -- defined in 3.2.7 as defined in
   WAI-ARIA, role global attribute for HTML5 with possible exceptions

   RS: Also HTML 5 has booleans, true etc. ARIA not defined that way.

   <oedipus> what about the redundant stuff in ARIA that was for
   plugging holes that may be plugged by HTML5?

   RS: A checkbox can have true,false, mixed for example, so we don't
   limit it in the same way as HTML5
   ... So we have to define the processing of ARIA?
   ... Mike, you wrote the section how should we proceed?

   <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

   RS: I know that DAISY eg would like to provide diff roles.

   MC: Don't know what to do about that, for ARIA we want the role @ to
   support the various roles.

   <oedipus> EPUB wants to support ARIA roles and RDFa roles

   MC: We could propose the att with expanded values.

   RS: Lets have a look.

   <current ARIA lexical doc being looked at>

   MC: I suggest adding role to the list of global attr in the current
   HTML5 editors draft.

   <oedipus> are we looking at:
   http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5 ???
   the phone is down on your end

   RS: Thats prob a good place

   <Stevef>
   http://www.html5accessibility.com/tests/aria-changes.html

   RS: What is the role attr state? CR?

   MC: The HTML WG don't want to reference the ARIA role attr model

   <Stevef> oedipus: have marked the chnages using ins @ del elements
   don't know if you can pick that up

   RS: It has to be a space delimited list

   MC: For sure

   RS: We should take text from the role attr module and tailor it

   MC: Yes

   <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

   <group looks at ARIA section of spec>

   <Stevef> sur

   MC: We need to define all of the ARIA attr in HTML spec.

   <Stevef> oedipus: will do

   MC: HTML doesn't defined elements by reference..

   <oedipus> http://www.w3.org/TR/role-attribute/

   <oedipus>
   http://www.w3.org/TR/role-attribute/#s_role_module_attributes

   CS: We are waiting for Ian to complete his Action item.

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

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

   RS: Ian send a note about ARIA normative, I don't want to limit HTML
   5 to what is in ARIA 1.0.

   MC: If we can incorporate by reference thats fine.

   MS: Thats what is done, MATHML eg

   MC: We do need to map value types.

   JOC: Not referencing a numbered version would help.

   RS: Yup
   ... If ARIA is to define new roles, that they be limited to elements
   that do not restrict the roles they can be applied to.

   <looks at screen of ARIA role and value type>

   MC: They need to be copied, I can do this via XSLT.
   ... We are just not using the HTML boolean type, just using them as
   token types.

   CS: We need to be explicit about that.

   MC: We want to expand that note, and make it an editors note.

   RS: Start with role?

   MC: Yes

   <oedipus>
   http://www.w3.org/TR/role-attribute/#s_role_module_attributes

   <group reviews current draft>

   RS: The role attr takes this value.. lets not use a CURIE, we should
   take a string?

   MC: I suggest a token.

   <oedipus> plus 1 to token

   MC: Looking at micro syntaxes, we want space seperated tokens.

   RS: Yes, we do.

   <oedipus> plus 1 to space separated tokens

   <some spec cpy n pste going on>

   <some editing going on>

   <look at XHTML vocab>

   <oedipus> http://www.w3.org/TR/role-attribute/#bib-XHTML-VOCAB

   <oedipus> http://www.w3.org/1999/xhtml/vocab

   RS: Are we going to sync with ARIA implementation guide? Steve?
   ... We will prob define mapping in ARIA 2?

   CS: The guide are seperate?

   RS: Yes, knew roles are features are defined, don't want to be glued
   to version number.
   ... How do we define the processing of the role values?

   CS: So if ARIA has new roles?

   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.
   ... If new roles are created

   CS: In a later version of ARIA

   <oedipus>
   http://www.w3.org/TR/role-attribute/#extending-the-collection-of-roles

   RS: I want to say that those roles in ARIA are not restricted.

   CS: Don't know about that, or you will only use them on <divs>

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

   <oedipus> ...with RDFa (see Appendix A), then the vocabulary
   definition must be the same as that required by RDFa."

   CS: We don't want to say that only certain elements etc would accept
   ARIA roles etc
   ... I want to say that there is some restriction to new ARIA roles.

   SF: This refers to strong native semantics and implied semantics..

   MC: We have three external and two internal refs..

   <oedipus> do we want to align role extention with RDFa-Core?
   http://www.w3.org/TR/2010/WD-rdfa-core-20101026/

   RS: So if we define new ARIA roles we have to update the
   implementation guide?

   MC: Yes

   RS: Perfect.

   CS: But no that duplicates the funcionality of the implementation
   guide?

   RS: We just need to point to mapping for any new ARIA updates.

   <some confusion about what docs are being referred to>

   MC: Yes, the WAI-ARIA User Agent Imp Guide..

   CS: Yes, we can edit that at will.

   RS: So there won't be a ref to implementation guide?
   ... Will will need normative references to the UA guide?

   MC: Yes, we have that now.

   CS: So how about something that states new ARIA roles cannot be
   applied to elements that do not allow override?

   <more spec wordsmithery>

   <oedipus> using role in conjunction with RDFa
   http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-
rdfa

   RSSAGENT, make minutes

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

   CS: We don't want to be too restrictive..

   RS: There may be a fight.
   ... Ian asked about what is normative, I think we have to do this.

   CS: If we make an ARIA overide at some stage, we need to be able to
   add that.

   MC: Getting the group to agree to externalise this section would be
   good.

   CS: I agree.

   SF: We want Steves annoteted doc externalised

   <oedipus> cooper, by externalize, do you mean split off into a
   separate document, like the Alt Techs doc?

   s/annoteted/annotated

   <discussion on overrides etc>

   <oedipus> won't we be accused of cyber-ghettoization?

   SF: Ian did say that role="presentation" can be on anything.

   RS: Yes
   ... Two things, we need to say what happens when ARIA introduces new
   roles.
   ... Also what happens when a role value is provided if not listed in
   HTML5 spec

   <oedipus> on ANY element? <head role="presentation" > doesn't make
   any sense... is there an exception for elements that appear in the
   HEAD

   MC: They might want a conformance warning..

   CS: Yes

   MS: Currently I don't think the spec does define this.
   ... It does say role attr * etc can be used

   <oedipus> spec should at least limit role="preentation" to elements
   that occur in the BODY of a document

   <oedipus> er, role="presentation"

   MS: I don't see a restriction on what can be implemented in
   validator.

   MC: ARIA 1.0 does say take the first recognised token..
   ... Then ARIA spec say all it needs to.

   RS: So are we ok with ARIA role def?

   <oedipus> what is the ARIA role def -- as tweaked today?

   <more word smithery>

   MC: If we externalise this stuff we can fix more easily

   RS: If we wish to add new role values, etc we wish to state it would
   not create a conformance error?

   MC: Don't really mind, to have warnings may not be ideal.

   <oedipus> RS, as long as the role value is documented as per Role
   Attribute verbiage

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

   <discussion of other use cases>

   <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

   <more discussion on implemtation guide etc>

   s/implemtation/implementation

   MC: This is kinda like microformats, we need an interoperable web..

   RS: Regarding DAISY etc, they may ignore these warnings.

   <discussion on EPUB etc>

   CS: They should come up with there own schema

   <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

   MS: In HTML 5 we have no normative schema.

   <discussion on RELAX NG and spec schema etc>

   <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

   MS: The EPUB group were concered about developing their own schema.

   <more word smithery>

   MC: The values that are allowed changes by element.

   RS: Is the title going to remain?

   <discussion on Stevef's doc title>

   The 'Annotations for Assitive Technology' doc

   <oedipus> break now for lunch or are we continuing through lunch?

   <oedipus> s/break now for lunch or are we continuing through
   lunch?//

   <oedipus> can i step away for a break or are we coninuing? if a
   break, how long?

   <oedipus> er, continuing

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

   <oedipus> ...describedby would have necessitated a return to Last
   Call, when we REALLY want to get ARIA through CR!

   <oedipus> s/already finishing/already in/

   <oedipus> HTML5 Section 7.2 - "Activation"
   http://dev.w3.org/html5/spec/editing.html#activation

   <oedipus> HTML5 Section 7.3 - "Focus"
   http://dev.w3.org/html5/spec/editing.html#focus


CANVAS

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas

   SF: Regarding the mapping doc is there a prefered place for that?

   MS: In the ARIA section.

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals

   MC: I should do a CP
   ... I would like to take over the doc that Steve has been editing.
   ... I will then do a proposal with suggested additions etc

   <Stevef>
   http://www.html5accessibility.com/tests/aria-changes.html

   RS: Are we doing to have a what ARIA dot (incremental) version?

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

   MC: We haven't decided yet

   <Stevef> oedipus: will look

   <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals

   RS: Re: canvas, we have a CP out now. We'll talk about hit testing
   for a11y APIs.
   ... It would be great to have someone from Apple to float some
   concepts about clickable regions.

   <oedipus> scribe: Gregory_Rosmaita

   <oedipus> scribenick: oedipus

   <trying to find participants for discussion>

   MC: agenda has media people in breakout for most of 2 days
   ... could see if GJR ready for Access discussion

   http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

   most of them have status reports

   RS: returning to CANVAS
   ... problem: for a11y and authors -- very difficult to do clickable
   areas for authors (hit testing)
   ... 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)
   ... 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
   ... what you can do is...
   ... fills rest of gap we have

   <rich looks for slide from CSUN presentation>

   RS: <adjusts screen resolution>
   ... function call -- find clipping region
   ... 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

   <Joshue> CS: Microsoft did a demo of <canvas> a11y yesterday in IE9

   SF: focus management question -- want checkbox kbd accessible

   RS: is kbd accessible
   ... now can have clicks and kbd support -- nice and clean

   SF: getting method for using canvas subDOM different from dev to dev

   RS: talked about CSS -- problem is transformations that canvas does
   -- don't have to do that with proposal
   ... worked with Charles Pritchard on this -- problem clickable
   region support
   ... whatever UA does...

   <room dropped from call>

   <Joshue> <discussion on Richs idea for new canvas API>

   RS: does all transformations without additional overhead
   ... do people like this approach?

   <general approbation>

   RS: so can i advance this?

   <yes>

   <Joshue> +1 to Richs idea

   plus 1 to advancing RS' idea

   RS: problem with CSS is transformations issue
   ... limited by tools at disposal
   ... hit testing a trip down memory lane...
   ... can do before LC? re-definig clickable regions -- bigger than
   a1yy

   s/a1yy/a11y/

   s/re-definig/re-defining/

   the only one i can't hear is MikeSmith

   now i can't hear anyone but Cyns

   RS: click goes to first thing, then bubbles up
   ... what you click on has to start at some element, probably lowest
   level of DOM
   ... if MikeSmith could write up what he just said, that would be
   great

   CS: remember computation on that level -- don't want to increase
   burdens

   <MikeSmith>
   http://dev.w3.org/html5/spec/infrastructure.html#event-click

   <MikeSmith>
   http://dev.w3.org/html5/spec/references.html#refsDOMEVENTS

   <MikeSmith>
   http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

   Activation in HTML5:
   http://dev.w3.org/html5/spec/editing.html#activation

   focus in HTML5: http://dev.w3.org/html5/spec/editing.html#focus

   MS: what happens if have touch device?
   ... actuation method of DOM (couldn't hear)
   ... <reads from something>

   RS: have to say bounds of element are defined by <unintelligible>
   ... if setClickable region, bind to that element, that section is
   defined based on what is associated with that element in the DOM

   <MikeSmith> ok

   RS: this is region associated with that handler
   ... if click in any of those areas, possible to hit test to get
   bounds
   ... if we could get text for the spec, that would be good

   <scribe only getting disassociated words>

   MS: event is fired as whatever elment clicked on

   RS: determines what click on

   MS: what is method to capture event?

   CS: if put in method to get caret <couldn't hear>
   ... if event listener catches event, does the job

   RS: UA directs mouse to child --

   <can only hear individual words>

   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>

   CS: whatever you bind to -- even a parent that gets clipped -- still
   works

   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
   ... layout engine does this anyway, but doesn't specify how to
   determine <couldn't hear>
   ... are TF members ok with this approach?

   <can't hear>

   RS: even though specify rectangle, canvas doesn't take rectagle --
   can use an ellipse or other more complicated shapes
   ... setClickable.Region to passive

   <can't hear due to white noise>

   CS: if do for anything other than rectangle what will happen?

   RS: can be triangle

   CS: need to define shape first?

   <click where?>

   RS: a11y api purposes, use rectangle or triangle

   CS: if tab, going to get focus rectangle

   RS: focus.screen can be circle, ellipse

   <click where?>

   CS: if use recatagnle to bind event handlers, how would that impact
   <couldn't hear>

   RS: this is canvas, not "straight HTML"

   <Joshue> s/ recatagnle/rectangle

   RS: specify this using wording
   ... have to have function that says, based on viewer and DOM tree
   that that position is in that clicable region
   ... pick lowest point of DOM tree that has highest lean-over

   CS: how do you fix?

   RS: have to have different rule for defining other than rectangle

   <discussion between Cyns and RichS on canvas versus HTML and binding
   shapes>

   <remote scribe can't hear flow of conversation>

   CS: worry is getting it implemented

   RS: clean way to do hit testing
   ... bind canvas to object use what have in HTML to bind object
   fallback content with drawing path exposed via canvas --
   ... cleanest way to support a11y API because don't have to do
   transformations in CSS to reproduce transformations in canvas

   CS: understand RS point
   ... want it documented

   RS: nothing new -- this is a "rich drawing space"

   CS: can be different shapes

   RS: yes -- requires author-end work

   <can't hear very clearly>

   <can't hear discussion>

   <scribe thinks Rich and Cyns are discussing implementation issues>

   <heard rich say "squiqqly">

   <er, squiggly>

   <richardschwerdtfe> can you hear me?

   yes

   <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

   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
   ... 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
   ... currently all of that is handled by canvas author
   ... 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
   ... 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
   ... cleaner, but redefines what is not clearly defined in DOM Events
   spec for how do DOM hit test
   ... no other way to do this right now --
   ... whatever shape provided, have to do "best fit" rectangle for the
   a11y object because only use rectangles in a11y API

   CS: sounds like could be a lot of extensive implementation work --
   poetentially destablizing -- expect vendors to be wary of that

   RS: bring this back to discuss with Frank Oliver

   MichaelC, are you luring FrankO to RichS with chocolates?

   <richardschwerdtfe> :-)

   CS: what happens when canvas area is non-rectangular?

   <can't hear FrankO>

   CS: put click handler on canvas DOM

   MichaelC, should this be minuted -- can't hear -- 2 discussions at
   once

   RS: have method in canvas for pointing to path -- work for key
   order?

   MC: plenary stuff for afternoon
   ... look-up table auto-generated for aria state and property looks
   up HTML ValueType

   RS: if we define new property?

   MC: regenerate it
   ... why want to externalize section of spec, so can update it
   indepently

   MS: people can disagree, but don't think it is a non-starter

   CS: initial resistence, perhaps

   RS: don't want to waste cycles spinning own wheels

   MC: need lookup table like this
   ... demand for it

   RS: why not keyword enumerated values as defined by Blah
   ... i can have aria values defined as this this and this -- keyword
   enumerated values -- what aria defines in spec today
   ... if have space delimited token list, have another one
   ... IDREFs another type

   MC: that is data lookup table would provide
   ... do you want into organized by HTML type and aria attributes that
   apply?

   RS: want to avoid having another document
   ... in aria subsectino define diff types -- for types, here how to
   process
   ... whitespace
   ... how to deal with whitespace

   MC: doesn't use that term any more

   RS: for IDREF, what would you call it?

   MC: defined in mapping table
   ... IDREF is the value of a defined id value on another element --
   most precise concept can find in HTML5

   RS: so refer to IDREF, point to that
   ... don't have to id all individual attributes -- all the attributes
   refered to in ARIA section...

   section 3.6.7 in current editors' draft

   RS: IDREF defined in this section of the aria spec is processed as
   follows

   MC: what have now
   ... defines what to do in HTML

   RS: ok, but didn't like, because?

   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

   RS: why not just put that table in the HTML5 sperc

   MC: intend to
   ... can do that -- don't know if would satisfy,
   ... want to hear what HSivonen has to say about it --

   RS: where do we have true/false enumerated values
   ... refer to true/false in table -- in atomic data type?

   MC: <shows RS table (i think)>

   RS: perfect!
   ... these are the diff types as defined in aria, this is how
   processed in HTML, and put the table in it
   ... put in Annotations for Assistive Technologies (ARIA) section

   MC: or make informative external reference

   RS: has to be processable

   MC: everything specified -- do you know where to look for it
   ... do need to know spec well enough to follow a link

   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:"
   ... don't want to have to have any change to ARIA contingent upon
   any other group's processes
   ... who has change for this section?

   MC: definition for role attribute

   RS: primary change proposal

   potential ACTION for Cooper - take SteveF's Lexical Processing
   prose, add definition of @role, and propose as change proposal

   <scribe> ACTION: Cooper - take SteveF's Lexical Processing prose,
   add definition of @role, and propose as change proposal [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action02]

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

   RS: want to get feedback on default roles for elements in HTML5 --
   do we need? should we do a longdesc -- remotedesc?
   ... want to know what to plan for ARIA.next
   ... like to start circulating a list; would be fine if response is
   "we don't need anything"

   <discussion of whether to intrude on media breakout group or
   continue with other agenda items>

   MC: media group wants to continue current work

   http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

   MC: timeline review and writing change proposal -- how much time?

   MS: walk through of chairs' decision policy

   MC: should open to everyone

   <Stevef> as per earlier discussion
   http://www.html5accessibility.com/tests/img-longdesc.html

   SF: marked up some spec text for review

   MC: preliminary review as sub-group

Longdesc Redux

   <richardschwerdtfe> scribe: Rich

   <richardschwerdtfe> Subject: Longdesc

   <scribe> scribenick: richardschwerdtfe

   Steve: we need to be conformant
   ... we need to be normative

   <oedipus>
   http://www.html5accessibility.com/tests/img-longdesc.html

   Steve: As I said there are minor edits.

   The text:

   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.

   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.

   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.

   yw

   Cynthia: this is too strong

   Steve: it is a starting point

   More text:

   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

   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.

   Steve: I provided an inline example using IFrame

   Cynthia: I would like to say that the visual indications are MAYs or
   SHOULDs
   ... What is actually required is the way an AT can access it.

   John: What we have is ...

   Cynthia: I am not convinced that the case for making longdesc
   visible is strong enough

   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.

   <Stevef>
   http://www.html5accessibility.com/tests/img-longdesc.html

   Cynthia: all the examples of visual renderings need to be SHOULDs
   and NOT MUSTs

   Leonie: Why is it a must for one group of disabilities but not
   another

   Cynthia: I am not convinced that the example is a strong use case

   Steve: Having the provision of content in text form is good for some
   users.

   John: we do not have data.
   ... The WhatWg has stated that not having a visual indicator is a
   problem

   <Zakim> oedipus, you wanted to say that longdesc simulteneous
   display for cognative guidance and limited viewport guidance through
   image / assistance in interpreting image

   oedipus: Did you not find users with a very limited viewport a valid
   viewport?

   Cynthia: I believed that was hypothetical

   <oedipus> no, not hypothetical -- we have extensively courted
   feedback on that

   Steve: users don't know it would be possible

   <oedipus> especiaally in the case of graphs and charts

   Roger: It is a valid use case for low vision users who can't see the
   whole graph to be exposed to the text

   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.
   ... Should we expose URL through the description field in the
   accessibility API

   correction: Cynthia said that

   Steve: The NVDA guys said we should not have to expose this. It
   should be exposed via the browser.

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

   Rich: I am not a big longdesc fan, but my concern is that users with
   cognitive impairments will need to see the longdesc text.

   Cynthia: not many sites use longdesc

   John: ... create more longdescs

   <oedipus> cyns, it depends upon your definition of the term "use"

   Cynthia: My point is that script can be used by the author to expose
   the longdesc

   <oedipus> longdesc is there, some mandate it, all want to use it, so
   let's get off the fence and support it

   Cynthia: this might be better if the author does it

   John: I said earlier that I don't think MUST is going to fly but I
   would like to see a SHOULD or SHOULD+
   ... but if this is the problem here is how to fix the problem

   <oedipus> easiest fix is to "restore" longdesc -- it doesn't take
   any work --unlike removing it

   John: the argument we are getting is that there needs to be a way of
   describing longdesc info to sigted users

   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.

   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.

   <oedipus> from what i hear, it sounds as if it conforms to the
   verbose desc reqs! <wink>

   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

   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.

   <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

   Steve: where should that go?

   <oedipus> it can go at the end, can't it?

   <oedipus> thanks steve

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

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

   <oedipus> need to cover those using AT and those not using AT but
   for whom the longdesc would be beneficial

   Steve: mouse over may provide a button to click
   ... I don't have a problem providing an example of how it should
   work

   Cynthia: I am fine with that but specifying the UI is not our job

   MIke: what's next?

   Rich: Do you want to put a change proposal in?
   ... Start writing a change proposal for it

   Cynthia: Put this stuff in the change proposal

   Steve: I said to Laura we needed a more robust mechanism for this

   <oedipus> discoverable versus hidden metadata

   <Stevef> oedipus: no problem

   <scribe> ACTION: Steve create a change proposal for longdesc that
   includes example of how a user agent might render longdesc
   information [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action03]

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

   <oedipus> rich's wording sounds to me as if it would be more
   palatable to the HTML WG

   <MikeSmith> http://dev.w3.org/html5/status/issue-status.html


Open Issues

   <scribe> scribe: Leonie

   <lwatson> scribe, lwatson

   <oedipus> scribenick: lwatson

   <MikeSmith> regarding issue 31,
   
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformace
Choices gives a really good overview of the differences
   among the various change proposals

   <MichaelC> ACTION: Cynthia to work with Steve and go through
   decisions from Lyon and document them regarding HTML-ISSUE-31
   [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action04]

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

   MC: Issue 32, table summary.

   CS: Did that get escalated?

   MC: It's in the hands of the chairs, so I think there's othing for
   us to do now.
   ... Issue 80, title alternative. In chair's hands.

   SF: It's been with them for ages hasn't it?

   MC: Issue 92, clean up table.

   <oedipus>
   http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element

   MS: Done.

   <oedipus> i have action to comment on poll for ISSUE 122

   <MikeSmith> http://dev.w3.org/html5/status/issue-status.html

   <oedipus> on behalf of HTML A11y TF

   MC: Issue 131, canvas text.

   MS: Deadline is 22nd to modify the hange proposal.

   s/hange/change/

   MS: One thing we should discuss is whether we're happy with this
   change proposal.

   MC: Was this subitted in a hurry?

   RS: We have the bounding rectangle, but it doesn't necessarrily
   apply to this.
   ... We took out references to rich text, so we're not saying "go do
   rich text".

   MS: If there are no cunter proposals, we need to adopt this.

   MC: Issue 133, modal dialogues.
   ... Do we want this and do we like what's here?

   <oedipus> i am proposing the modal dialog for ARIA.next

   RS: What we need is a dialogue element that specifies modal.

   <oedipus> s/dialogues/dialogs/

   MC: Is there anything besides a dialogue that could be modal?

   SF: Yes.

   RS: I would like to have the use cases enumerated here.

   SF: You can have fall back as well. If your JS isn't working for
   example.

   CS: This is a post last call issue.

   <MichaelC> ACTION: Schwerdtfeger to review ISSUE-133 and consider
   whether a refined (counter) proposal needs to be submitted [recorded
   in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action05]

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

   MC: Issue 124, tab states.

   s/124/134/

   <oedipus> might be affected by ARIA-in-HTML decision

   <oedipus> cooper is correct

   MC: this is creating native attribs that are like ARIA attribs.

   RS: I don't like tabbing through a tab panel, or tabbing through a
   menu.

   MC: This is attempting to allow menus to be defined as tablists.

   <oedipus> borrowing concepts from ARIA for HTML5 -- might be OBE by
   ARIA-in-HTML decision

   MC: So we support the change proposal.

   RS: Give me an action to review this one.

   SF: If something has a modal attrib, it's default role could be
   dialogue.

   <oedipus> s/default role could be dialogue./default role could be
   dialog/

   SF: We should have a discussion as to whether it should be an
   element or an attribute.

   <MichaelC> ACTION: schwerdtfeger to review ISSUE-134 [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action06]

   <trackbot> Created ACTION-116 - Review ISSUE-134 [on Richard
   Schwerdtfeger - due 2011-03-26].

   MC: MC: Issue 135, link canvas spec.
   ... Looks like there has been a call for consensus amongst the
   chairs on this.
   ... Issue 142, poster alt.

   JF: The poll closed, and we have two change proposals.
   ... It's waiting for the chairs.

   <oedipus>
   http://www.w3.org/2002/09/wbs/40318/issue-142-objection-poll/results

   MC: Issue 144, underlining <u>

   CS: No harm to make it conforming.

   <oedipus> presentational elements should be only conforming with a
   warning -- USE CSS!!!

   s/underlining/conforming/

   MC: Issue 147, playback rate undefined.

   JF: Doesn't affect us much.

   MS: We should get Sylvia's input on this.

   MC: Issue 153, link external.
   ... Issue 155, cell border.

   MS: I've read through this but not sure I fully understand it.

   CS: Don't think it's an accessibility issue.

   MC: Issue 161, accessibility API mapping.

   CS: We need to do some work there.

   SF: It's just to add a link in there.

   MC: Issue 163, navigating tracks

   JF: We're discussing this tomorrow.

   MC: The bug triage sub team hasn't seen any bugs it needs to take a
   look at.

   <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

   <oedipus>
   http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

   MC: There are five bugs...
   ... 10249, canvas requires a content selection method, assigned to
   RS.
   ... It needs expanding, or closed.

   <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10249

   <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10896

   MC: 10896, enable device independent access to event handlers, filed
   by LW.

   <oedipus> hixie said that he thought it more appropriate for the DOM
   / WebApps / WebEvents group for DI access to event handlers

   <oedipus>
   http://www.w3.org/WAI/PF/HTML/wiki/Access/event_handler_requirements

   MC: 11328, canvas authors need to be able to assess pixel
   resolution, filed by RS.

   CS: Assign it to Doug, he should be able to find someone to look at
   it.

   MC: 11329, HTML5 supporting browsers must support resize event
   during zoom, filed by RS.
   ... It's been assigned to Web Apps WG, is that the right place?

   JF: Is this a TF concern?

   CS: Yes, it relates to zoom.

   MC: 11391, provide examples of track usage, filed by FO.

   MS: This would make the track element usable for additional audio
   tracks.

   JF: So this is related back to issue 152.
   ... Think I may have reported this back to Martin a couple of weeks
   ago.
   ... Think I may have reported this back to Martin a couple of weeks
   ago.?

   MC: So here's nothing else to do on this right now?

   <oedipus> we could look at
   http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

   <MichaelC> ACTION: foliot to raise Bug 11391 with media sub-team
   [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action07]

   <trackbot> Created ACTION-117 - Raise Bug 11391 with media sub-team
   [on John Foliot - due 2011-03-26].

   MC: We needed to do a review of the whole spec, but this could be a
   PF action as opposed to a TF action.
   ... The idea was to start writing WCAG techniques as a mechanism for
   discovery.
   ... Nothing for us to do on spec review right now.

   MS: It looks as though we don't have any outstanding actions on
   drag/drop anymore.

   SF: Gez and Everett looked at the spec and seemed not to have furter
   concerns.

   RS: What happens if ARIA is used with respect to HTML5 drag/drop?
   Could we ask Gez to look into this?

   <MichaelC> ACTION: Lemon to review if HTML drag and drop model
   conflicts with ARIA drag and drop model [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action08]

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

   <oedipus> [ADJOURNED]

   MS: Meeting adjourned.

Summary of Action Items

   [NEW] ACTION: Cooper - take SteveF's Lexical Processing prose, add
   definition of @role, and propose as change proposal [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action02]

   [NEW] ACTION: Cynthia to work with Steve and go through decisions
   from Lyon and document them regarding HTML-ISSUE-31 [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action04]

   [NEW] ACTION: foliot to raise Bug 11391 with media sub-team
   [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action07]

   [NEW] 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 [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action01]

   [NEW] ACTION: Lemon to review if HTML drag and drop model conflicts
   with ARIA drag and drop model [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action08]

   [NEW] ACTION: Schwerdtfeger to review ISSUE-133 and consider whether
   a refined (counter) proposal needs to be submitted [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action05]

   [NEW] ACTION: schwerdtfeger to review ISSUE-134 [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action06]

   [NEW] ACTION: Steve create a change proposal for longdesc that
   includes example of how a user agent might render longdesc
   information [recorded in
   http://www.w3.org/2011/03/19-html-a11y-minutes.html#action03]

   [End of minutes]
     _________________________________________________________
Received on Sunday, 20 March 2011 00:21:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:18 UTC