Draft Minutes for the HTML Caucuse, 16 October

Minutes from today's HTML Caucus teleconference are provided below in
text, and are available in html at:
http://www.w3.org/2009/10/16-pf-minutes.html

   W3C

                                                           - DRAFT -

                                                     PF/HTML_Caucus telecon

16 Oct 2009

   See also: IRC log

Attendees

   Present
          Cynthia_Shelly, Janina, Cooper, Rich

   Regrets
   Chair
          Janina_Sajka

   Scribe
          janina

Contents

     * Topics
     * Summary of Action Items
     __________________________________________________________________________________________________________________



   <scribe> agenda: this

   <Stevef> Recommendations regarding Long Text Alternatives http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

   <cyns> SF: alt text. I looked back at the wai concensus doc, and it reflected what I was saying in the WAI PF meeting
   yesterday

   <cyns> RS: I hate longdesc

   <cyns> JS: I think we agreed to obsolete longdesc

   <cyns> SF: that path requires behavior for aria-described-by that weren't agreed to by ppl like Rich

   <cyns> RS: in the accessibiltiy API, all described by is is a relationship that will take you somewhere in your doc,
   anywhere you want it to. I hate the idea of putting a link in there and forcing the browser to take the link.

   <cyns> JS: force, or offer to the browser?

   <cyns> SF: I thought it was just an offer

   <cyns> RS: ok, that's better.

   <cyns> SF: in the case where the longdesc has ref and id that's on a link, and the link text is further description,
   provide a mechnaism for the user to be albe to navigate teh link. A mechnanism whereby te user can move to the
   structured content

   <cyns> RS: no problem with taht

   <cyns> SF: a number of ID references could be a problem. Describedby is just supposed to concatenate text from multiple
   references.

   <cyns> RS: if the content is hidden, tehre's nowhere to go to. it'll be in the dom but not in teh API

   <cyns> RS: if it's hidden, UA will fill in MSAA description with whatever text it can gleen. It's like help text, can
   work with tooltip or whatever. But, the current interface in JAWS provides a mechanism to go to the descriptin.

   <cyns> SF: The way to go there needs to be specked out for the AT vendor.

   <cyns> JS: because longdesc was not a success

   <cyns> RS: what about if there's more than one IDREF for description? That's not spec'd, and needs to be.

   <cyns> SF: we could provide a set of steps. EG if the ID is on a table, move to table, if it's on a link provide an
   option to activate the link, if it's just a text container, just read out the content.

   <cyns> MC: just allow normal processing, just go to the described by section. if there's a link, the user can
   click/activate it.

   <cyns> RS: we can't make AT vendors do it.

   <cyns> CS; no w3c specs for AT, hole

   <cyns> RS: there is history, reasons for this.

   <cyns> RS: AT vendors wouldn't follow first UAAG spec

   <cyns> SF; need to revisist what we've said in text alternative document

   <cyns> SF: provide idea in implementiaon guide on how we think AT should implement it.

   <cyns> CS: put AT guidelines in UAG? or separate doc? good idea, but increase in scope

   <cyns> RS: good luck getting them to do it.

   <cyns> CS: took 10 years with browsers, maybe time to start with AT?

   <cyns> JS; existing mechanism (longdesc) is a failure, look at why, build from that

   <cyns> SF: some AT and browser vendors did implement longdesc

   <cyns> SF: if we provide a better mechanism, they may implement it.

   <cyns> JS: part of why we like ability to point via href via aria-describedby, is that we could do various media, not
   just text

   <cyns> SF: if you have a long text alternative relationship, if there are 1 or 10 things you're pointing to, the user
   can get access to those things

   <cyns> JS: jst like any 1 or 10 hrefs on a web page, no a special case

   <cyns> RS: can you give me an example where you'd need more than one described-by?

   <cyns> SF: one image that's more than one table? A graph, a data table in html that provides the data, that's the sort
   of relationship that a user would want to know about

   <cyns> CS: multiple alternative versions for cognitive, like a picture, a video, a shorter version of the text, etc.

   <cyns> RS: so, we need to say that if there are multiple IDREFs, each is an alternative description. AT can then bring
   up a list box, and you can pick the one you want.

   <cyns> SF: agree

   <cyns> JS: list should tell you want mime type it is

   <cyns> RS: would have to be in a target

   <cyns> CS: sounds like a may

   <cyns> JS: I'd accept a MAY, or a SHOULD

   <cyns> RS; do we want to put in in the spec?

   <cyns> what about mainstream UA? should we ask them to do that?

   <cyns> CS: yes, I think so

   <cyns> RS: in the spec, make that a should or a may for now. When IE or FF does it, HTML5 will follow

   <cyns> resolved: Multiple IDREF in an aria-describedby MUST be interpreted as multiple alternative rendereings, AT and
   other UA may expose mime-type to the user, non-AT UA SHOULD provide a mechanism for navigating to the IDREF

   <cyns> RESOLVED: Multiple IDREF in an aria-describedby MUST be interpreted as multiple alternative rendereings, AT and
   other UA may expose mime-type to the user, non-AT UA SHOULD provide a mechanism for navigating to the IDREF

   <scribe> scribe: janina

   js: open agenda today, any topics for us?

   rs: someone should be designated to start submitting changes from our spread sheet

   cs: the mappings?

   rs: yes, we're taking ian's and redoing it, so create an issue, make this change, etc

   cs: i was thinking putting the entire table in as a change request

   rs: were you planning to cover this on aria call?

   cs: could

   rs: should probably run on the aria group

   cs: didn't we decide this at our f2f?

   js: for our santa clara f2f?

   cs: would like to get it to html wg before then
   ... at the very least i'd like to have this ready to submit by f2f

   rs: i'll try to add some of the external dependencies

   cs: frank fro ie team working on a canvas proposal, related, needs rich's guidance

   rs: is there likely to be an html6 on the heels of html5?

   cs: certainly a discussion

   rs: instrumenting an a11y api for html5 will be almost impossible -- re canvas
   ... we can add dom, but that's aria2 --

   cs: canvas is so different from html

Summary of Action Items

Present: Cynthia_Shelly Janina Cooper Rich

-- 

Janina Sajka,	Phone:	+1.202.595.7777;
		sip:janina@CapitalAccessibility.Com
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Friday, 16 October 2009 15:59:35 UTC