- From: John Foliot <jfoliot@stanford.edu>
- Date: Thu, 4 Mar 2010 09:19:55 -0800 (PST)
- To: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Minutes from the call can be found at: http://www.w3.org/2010/03/04-html-a11y-minutes.html Also Copied below: HTML Accessibility Task Force Teleconference 04 Mar 2010 Agenda See also: IRC log Attendees Present John_Foliot, kliehm, Marco_Ranon, Gregory_Rosmaita, Michael_Cooper, Janina, MikeSmith, Ben_Caldwell?, Eric_Carlson, Stevef, Matt, Cynthia_Shelly, Rich, Leif_Halvard_Silli, Paul_Cotton, +20625aaaa, Dick_Bulterman, chaals Regrets Denis_Boudreau, Jon_Gunderson, Laura_Carlson, Kelly_Ford, Geoff_Freed Chair Janina_Sajka Scribe John_Foliot Contents Topics Action Item Review Sub-Group Updates Summary of Action Items <trackbot> Date: 04 March 2010 <janina> Meeting: HTML-A11Y telecon <janina> agenda: this <janina> +http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/att-0014/canvaselement-issue74-feedback1.html <oedipus> "solomonic" summary change proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element <MichaelC> scribe: John_Foliot <MichaelC> scribeNick: JF <oedipus> jf, http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet <oedipus> leif, "solomonic" summary change proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element Action Item Review <MichaelC> action-2 due 1 April <trackbot> ACTION-2 Deliver draft of change proposal for ARIA additions to HTML 5 by 2009-12-24 due date now 1 April <LeifHS> my name: Leif Halvard Silli Cyns allow diversion for MSAA / ARIA <MichaelC> action-8: UAI TF has decided to allow for divergent relationships <trackbot> ACTION-8 Follow up with IE team about whether implementers are willing to use parent/child/nesting relationships could be used in mappings logic notes added <janina> If my stuttering continues, I could get my cell phone. It would take about 2-3 minutes to make that change. Cyns beleives Action 8 is / could be closed <MichaelC> close action-8 <trackbot> ACTION-8 Follow up with IE team about whether implementers are willing to use parent/child/nesting relationships could be used in mappings logic closed <MichaelC> action-20 due 11 March <trackbot> ACTION-20 Dig up history on column element due date now 11 March <oedipus> chaals' imagemap proposal for CANVAS: http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom <MichaelC> action-21: chaals' imagemap proposal for CANVAS: http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom <trackbot> ACTION-21 - coordinate concrete proposal for use of imagemap in CANVAS notes added Sub-Group Updates Janina: Concern that facilitators / email exchanges have gone far away from polite conversation and become attack like keep personalities out of discussions ask others honor that others have perspectives focuse on technical issues, avoid judgements Canvas subgroup has offered a proposal to the tF Chaals has a counter-proposal that he has submitted Rich: still some issues surrounding ADOM <oedipus> chaals' imagemap proposal for CANVAS: http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom Maciej suggests that by default the sub-tree navigation be keyboard accessible canvas should be in keyboard navigation else yu must make explicit statement <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/att-0265/canvaselement-issue74-feedback1.html <scribe> new modification emerged on Monday call replace ADOM with Navsubtree set to false to not include in keyboard navigation over time you will never have to set it - will become default (Richard reviews current proposal verbatum) richard: Chaals proposal binds the image map to Canvas needs to also deal with <coords> and addition of ARIA markup <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom richard suggests that either proposal could then be used to make ally available image mape would been seen as a navsubtree <Stevef> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility <oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility yet another CP presented by SteveF so group must decide do we want to proceed with the first proposal, Chaals proposal, or a combined proposal the navsubtree proposal, in terms of change is rather small to HTML spec Rich believes there is value in presenting both Janina: how many changes will this add to the spec? <oedipus> GJR notes that IMAGEMAP restoration proposal origanted with lachy, not chaals Rich is unsure of feel of HTML WG to re-visit the old HTML4 areamap SteveF: FF has no support for @role on area elements however DaveB is pushing for that <LeifHS> Chaals proposal uses <A> elements. Those support roles, no? history of re-instatement of area goes back a ways Rich: what is groups postion? <cyns> Leif, in current spec A doesn't take roles, but there's a bug on this Janina: take some time and survey group would HTML WG look kindly on imagemaps? <LeifHS> Cynthia, yes, but they discussed FIrefox support. PaulC suggests that the answer would be No SteveF: thee has been a fair bit of silence on this topic at the larger group Janina: a survey could ask "Should" HTML WG accept AreaMaps <cyns> Leif, as part of work item to do mappings, we intend to argue that A and most active elements should take roles. Rich: don't restrict authors to areamaps <cyns> So, agree with Gregory, that they SHOULD <oedipus> GJR thinks the sanest thing is to have 1 approach to CANVAS a11y hixie suggests that you can have 2D Canvas navigation Rich: navsubtree clarrifys what to do with that content eventually navsubtree would become obsolete <oedipus> strong plus 1 to SteveF's proposal to combine Rich: if we present Chaals request, do we need to re-write the whole areamap part of spec? Chaals: quite serious about making this proposal PaulC: question of scope / work effort if there is strong support for that change, will require detailed Change Proposal Chaals: would like to take preliminary Question to working group not a huge change but is scattered a bit more throughout the larger document so might take a bit more time Rich: recaps - 2 things regarding navsubtree read 2d proposal says essentially that this would be an expected beahviour elements in navsubtree should be in keyboard order Chaals: that is what the spec says, argues that it is incorrect Rich: apple also suggests that the navsubtree would be there bring the 2 together as "the proposal", then work with Chaals to refine details Chaals: 2 phases to his proposal 1) if you must render all of convas content as active when rendered, it has a constraining effect might end up rendering stuff only relevent to canvas if you use imagemap elements (no substantive change to spec, just editorial) then you could use area elements inside of canvas, but don't have a rendering behaviour if cnvs is not rendered already works <oedipus> not trying to cut off debate, but there are only 20 minutes left in call and we have yet to get to summary one weakness is that the only way to create structure is to use extensive area (ARIA) additions howeve establishes block elements - enables richer ability to add content change proposl can be minimal in many ways why write a HTML5 change proposal to change an existn (HTML4) imagemap but it could be done today Rich: if we return to HTML4 imagemap, how does it impact on HTML5 spec (drag n drop for esample) Janina: we shoud find broader solutions that go beyond just a11y Chaals: cannot see a particular impact on Drag n drop thinks it would be valuable to advance to HTML Wg impact on DOM? Janina: important as this is a threshhold issue seems both proposals can be combined iron out issues however, what would be acceptable to larger WG? ask that question before moving foward? Rich: pain points HTML spec is inconsistent re: navsubtree Q: how do people feel about the default behaviour that navsubtree be default behaviour 2) how do we feel about bringing the full HTML 4 imagemap back? Chaals: HTML5 imagemap model actually can support Chaals proposal however if we use html4 model HTML5 spec doesn't yet work, HTML4 does thx greg in functionality, both imagemaps proposals will work Cyns: does either support more than live regions? Chaals: essentially yes in theory everything should work in both imagemaps spec, the <map> element works like a <div> (discussion of HTML 4's imgemap properties) Cyns: curous to see how this would work with menus and toolbars Chaals: if you make an image map with a bunch of <A> elements inside, but wrap with a canvas element, it doesn't render, but is navigatible Rich: if we bind it, we wouldnt want it to render Chaals: can be inside our outside of canvas ... make an imagemap and place it inside the canvas <oedipus> ten minute warning Chaals: this seems to work everywhere except Safari today presumes there is a mechanism <oedipus> plus 1 to Janina's suggestion Janina: should we ask Rich and Chaals to further discuss 'merging' ideas before moving it to larger WG? Chaals: proposes that Richa nand he get together at CSUN to bang out details Janina: worth explaining to WG that we have some good, but incomplete proposals - pehaps proposal by end of month Chaals: tell WG that we have an idea, but not fully baked SteveF: if we do go down this route, we will be asking for some substantial changes to 2D canvas API <oedipus> FIVE MINUTE WARNING so introduces sme serious questions We need the 2 to work together <paulc> Leaving to go to the HTML Wg meeting which I am chairing today. there are some things that will definately need to be changed <oedipus> http://dev.w3.org/html5/2dcontext Cyns: figure out best aspects of both, then merge them <oedipus> http://dev.w3.org/html5/canvas-api SteveF: cannot get examples to work in Opera - need more working examples for testing Chaals: win version of Opera has a regression - if not working is considered a bug Rich: interested in seeig examples with input elements as well <oedipus> TWO MINUTE WARNING SteveF: if we can get some working examples, can make others <chaals> for Opera development builds Steve will bring 2 changes to the subgroup need to bring to the larger TG group larger TF group <oedipus> on the TABLE for summary (pun intended) <oedipus> LauraC: http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222 <oedipus> Leif: http://www.w3.org/html/wg/wiki/ChangeProposals/tableInfoProposal Janina: re summary: pleae look at Leif's change Proposal <oedipus> GJR's "solomonic" summary change proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element sorry we lacked time to look at these thee are numerous proposals out there <oedipus> Cyns: www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010 we should talk to see what it would take to bring all of this together? <kliehm> Also join Cynthia, John, Chris Blizzard, Michael Dale, Bruce Lawson and I at SXSW: http://my.sxsw.com/search/event_results?q=html5+workshop+-css3+-google ;-) Summary of Action Items
Received on Thursday, 4 March 2010 17:20:31 UTC