- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Mon, 1 Feb 2010 21:18:22 +0000
- To: public-canvas-api@w3.org, public-html-a11y@w3.org
- Cc: david.bolter@gmail.com, jcraig@apple.com, David Singer <singer@apple.com>, janina@rednote.net, cooper@w3.org
aloha! minutes from the 1 February 2010 Canvas Sub-group of the HTML Accessibility Task Force are available as hypertext at: http://www.w3.org/2010/02/01-html-a11y-minutes.html as an IRC log at: http://www.w3.org/2010/02/01-html-a11y-irc and as plain text following my signature; as usual, please report any errors, omissions, mis-attributions, clarifications and the like by replying-to this announcement on-list please note that the next Canvas Sub-Group teleconference will be held on 8 Feburary 2010 -- details about Canvas Sub-Group meetings, as well as links to minutes from past meetings, are available via the HTML Accessibility Task Force's wiki: http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings/Minutes thanks to all who attended and who are prototyping Canvas accessibility solutions, gregory. _________________________________________________________________ - DRAFT - HTML Accessibility Task Force Teleconference 01 Feb 2010 Agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0144.html See also: IRC log [http://www.w3.org/2010/02/01-html-a11y-irc] Attendees Present Gregory_Rosmaita, Rich, Frank_Oliver, Stevef, Jon_Gunderson Regrets David_Bolter Chair Rich Scribe Gregory_Rosmaita Contents * Topics 1. Action Item Review 2. Progress on Chart Example with data table for alternative selection 3. CANVAS API 4. Define CSS Attributes and meta data for alternative content selection 5. Access for All 6. CSS media types for tactual and tactile * Summary of Action Items _________________________________________________________________ <trackbot> Date: 01 February 2010 <richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Meeting <richardschwerdtfe> just a sec <richardschwerdtfe> coming <davidb> i can't dial in yet <frankolivier> frankolivier == [Microsoft] <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0144.html <scribe> scribe: Gregory_Rosmaita <scribe> scribenick: oedipus _________________________________________________________________ Action Item Review <Stevef> oedipus: ip caller is me FO: super simple mock-up -- not rocket science but a bit of work author has to do -- more than alt text on img, but fairly straightforward; if map controls bnack to HTML UI elements, easy to do RS: no problem with focus mangement and drawing image? FO: did simple - 2 checkbox example; text boxes more intricate, but follow same pattern; as control gets more and more complex have to do more mapping, but that doesn't mean it isn't feasible RS: looking at it http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0147.html FO: if ignore shadow dom still visible, this is like JCraig's example; if pretend shadow DOM not there, to AT would like like 2 checkboxes; all interactive behavior and focus interactions work as if actual control ... fake focus in background ... in future, have UA do surface interaction, if programmatically control focus, can control tab order and interactivity of other controls ... biggest hassel - if click on CANVAS element, have to figure out where user clicked; what event to fire (onClick or onFocus) - author needs to do state management not prohibitive, but takes specific wiring SF: what is in CANVAS spec as regards focus mangagement FO: nothing specific; very simple to do; no special features required; only thing can't do is put shadow DOM inside CANVAS - could wire up if manipulate DOM but would be tricky SF: is it in agreement with what is specified? FO: yes ... once wired up in web browser, can put shadow dom underneath RS: tabbing? FO: works in safari, didn't have chance to check with FF RS: can't get it to work in safari FO: strange.... ... using safari on windows ... we can talk outside of meeting RS: ok FO: what you see in CANVAS are 2 checkboxes and a selection rectangle - need API to support that; works like any other control - should be able to tab to first and second checkbox, use spacebar to toggle checked/not checked JRG: works for me on the mac ... tabbing to controls with safari; can see shadow DOM checkboxes beneath it RS: space to select and deselect works fine FO: biggest part getting state synced up between users of keyboard and users of mouse -- once figure out, though, all the same pattern; hopefully toolkit for canvas will do this on author's behalf RS: hiding it in ACCESSIBLE won't have impact FO: once support for ACCESSIBLE node, should work ... will try and get it to work RS: shadow DOM outside canvas FO: shouldn't have impact on stability of concept JRG: one potential issue - when inside CANVAS technique for IE to do canvas is a VML plusin -- VML goes inside CANVAS not sure how other content would react to that FO: using plug-in in IE6, IE7 and IE8 -- side effect of how implemented plug-in -- fixable problem JRG: running snow leopard, latest version ... will try on windows, too RS: have to play around with it -- if put inside CANVAS spacebar no longer works FO: works fine with me in snow leopard -- happy to debug after call RS: great progress, thanks Frank JRG: works with FF on mac, too RS: tabbed to it and didn't see any visual focus JRG: salmon-colored border FO: yeah, red border JRG: saved to desktop and opened it FO: should work from the get-go JRG: with FF on mac, tab to it from address bar RS: running 3.5.7 GJR: current release is 3.6 RS: try to put inside CANVAS to see what is happening _________________________________________________________________ Progress on Chart Example with data table for alternative selection http://www.w3.org/WAI/PF/HTML/track/actions/16 http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0145.html http://devserv.dres.uiuc.edu/ita/jongund/citaweb/test/aria/canvas/canvas1.html <davidb> oedipus, I saw that email, but haven't gotten to it yet today JRG: wanted to make sure it is what people are expecting before moring to some place permenant ... status sequences; doesn't work in IE with plugin ... took OurGraph library and added features to it; a lot inaccessible -- sketchbar can be drawn on using mouse; rightClick; if click on bars, brings up tooltip with a click; need to activate focus -- can't i do with aria live regions? ... added content to static chart is one thing, collaborative much more complicated GJR: couldn't access fallback content with JFW or NVDA and FF 3.6 RS: is TABLE outside of CANVAS JRG: contained in CANVAS RS: explains GJR's problem with screen reader access SF: nothing currently in any implementation exposes anything inside CANVAS GJR: gotcha RS: 2 examples to work off of -- need to do something with ContentEditableText ... need to do something with focus for magnification? SF: yes _________________________________________________________________ CANVAS API RS: anyone implemented SF: not the one implemented in spec RS: need UA implementation of fallback in CANVAS SF: status of work with Alexander Surkov and DavidB? RS: how to get into IE FO: adding other features into IE; can't promise work on this for forseeable future RS: need to see if can get alex to prototype some of this _________________________________________________________________ Define CSS Attributes and meta data for alternative content selection http://www.w3.org/WAI/PF/HTML/track/actions/17 RS: started that work ... raised a few questions SF: did you see my email about opera implementing IMAP ontop of CANVAS? http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0102. html RS: collection of links in IMAP? SF: [breaking up badly] ... underlying HTML DOM elements can relate to AREA elements so can add aria ontop of those RS: role="image" etc. SF: yeah -- different approach than being discussed here RS: how? SF: using existing concepts extant in HTML, imagemep in different context; focus management would be done as done in imagemaps ... this example that frank had, would have 2 AREA elements with coordinates; would have programmatic focus supplied by IMAP, so wouldn't have to draw focus rectangle yourself; AREA elements would hve role="checkbox" ... works partially now -- what you get, when move focus, will say "button" ... if have role="button" will say "button" -- can override native role with ARIA RS: violating host language strong native semantics SF: at this piont in time, there aren't strong native semantics in spec; trying to modify them -- wouldn't define A as button; AREA is similar to anchor RS: draw visual focus on canvas SF: same way UA does with imagemap; layover GJR: can understand why investigating because there is pre-existing code that can be reused RS: show it instead of shadow DOM approach? SF: their version of shadow DOM is use IMAP with AREA RS: within CANVAS? SF: doesn't have to be; mapped onto imagemap by UA RS: problem may be that not going to be navigating elements in context of DOM ... when get to canvas, what happens? SF: think of canvas as static image; has areas defined as hotspots, so tab through those as would tab through normal imagemap RS: between the canvas tags? SF: presume that if want to, can put AREA elements and IMAP inside CANVAS, but don't need to -- that's tyhe point ; already mapped via mapping for MAP with AREA inside can be anywhere in document as long as coordinates define focus in image RS: if put at end of document; WCAG says "put in logical order" SF: ask you to do in manner that AT can interact with it; AREA element can be anywhere RS: if want to ReadAll, starting above AREA, you're going to end up at end of document SF: that's how it works today ... nothing new -- works on IMAP model RS: problem not with use of imagemap, but putting outside of CANVAS SF: what people do with images on imagemaps now ... way opera proposal doesn't matter if in CANVAS or outside RS: if navigating imagemap and there are checkboxes, those would be out-of-context SF: no, physical focus and information as far as contextual info, AT gets that when has focus on imagemap RS: no problem with that; what is problem is if context is put in document in document order, mouse interaction not going to be anywhere near a11y for that element; if stick at end of document, have to tab to end then back SF: way works with imagemap, have image, associate image with imagemap, if have 2 area elements with coordinates on them for that image, when you get to the image, the 2 focusable hotspots are in focus oreder within the imagemap; can go from link to first focusable hotspot, second focusable hotspot, etc. focus order is defined by coordiinates <Stevef> http://www.paciellogroup.com/blog/misc/canvas-pie/pie.html RS: write a numerical tab index in there ... author would have to do that SF: not if use imagemap ... fine if want to put in canvas; wanted to stress that opera investigating this, so we should be checking it out too RS: besides location outside of CANVAS, don't have problem SF: issue with focus not an issue with imagemap RS: who is working on it SF: Opera under chaals RS: will talk to chaals JRG: by using coordinates of area define interactive places, then use aria markup on AREA element to say what it is? SF: yes ... in IE when access via MSAA tells you is a button -- by virtue of the ARIA spec, whatever roles are there should override, so ARIA roles should override native roles RS: AREA flexible enough for all controls? ... if want to use standard control inside AREA, can't do that ... frank's example with real checkbox SF: can't do that -- have to define role using ARIA on AREA elements RS: don't have issue if works; if want to use standard controls, AREA has a lot of limitations SF: agree RS: could say is another vehicle if it maps SF: advantage is that all the focus stuff is done for you using a known construct, the imagemap, so implementation would be trivial, which is a reason for investigation RS: when get beyond buttons, may not be so simple SF: then have to have multiple AREA elements RS: have to find if there is a point of diminishing returns ... put tools in hands of authors to do what they need to do JRG: question for FO -- when manage focus, rely OnFocus on standard form control, then update styling of canvas? FO: yes, UA handle focus management ... doesn't work if inside CANVAS because treated as fallback content by current UAs; could re-write browser to support ACCESSIBLE tag ... if dynamically add it under CANVAS in DOM, but inconsistent from UA to UA JRG: goal is that all is hidden inside CANVAS element FO: today's UAs would have to be updated to support interactive elements inside DOM JRG: could plug-in for IE do this? FO: clear everything under CANVAS element is bug i filed JRG: possible implementation problems unless coordination with developers of things for IE; going to have to be cooperation between IE plugin -- people will be manipulating VML -- possibility of conflicts that will wipe each other out FO: aware of that problem; where people using VML to add features to IE is a problem for us once we add features to IE natively; native feature conflicting with add on is situation to be avoided ... similar to requirement ot update all browsers; all implementations of CANVAS need changes to make this work <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0146.html _________________________________________________________________ Access for All RS: 2 types: accessforall meta-data for user preferences defined in terms of meta-data ... tried to simplify set down; chose core data to start with -- does all need to be in here for content, or can we reuse HTML constructs such as "lang" ... different content categories for HTML flow (secton, etc.) -- do we need new one for ACCESSIBLE since hidden behind CANVAS FO: preference is not to add new element RS: what categories would apply? ... flow content (in document flow) -- interactive content (keyboard navigatable within that spece FO: what problem are you trying to solve with tagging RS: HTML5 spec defines different types of content for each element, so need to catagorizwe FO: can be anything - could be interactive, static or dynamically generated RS: right FO: good question RS: a bit of everything FO: as generic as possible RS: if people have thoughts on it, please post to list ... talked about preceding attributes with aria- ... ARIA part of HTML5 spec links to ARIA spec, so no properties from meta-data about resource capabilites are, not necessarily to driver interoperability ... should we procede with afa- for attributes instead of aria- FO: larger discussion than just CANVAS sub-group <richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0146.html _________________________________________________________________ CSS media types for tactual and tactile tactile is defined as "capable of, allows for being touched"; tactual is defined as "arising from or due to touch"; GJR PROPOSAL 1. keep "tactile" as super-set in CSS media groups: [http://www.w3.org/TR/2009/CR-CSS2-20090908/media.html#media-groups] GJR PROPOSAL 2. add the "tactual" media type (raised line maps, thermoformed objects, etc.) to CSS's list of media types: [http://www.w3.org/TR/2009/CR-CSS2-20090908/media.html#media-intro] that way we only need to ask CSS WG for new media type: tactual [End of minutes] _________________________________________________________________
Received on Monday, 1 February 2010 21:20:21 UTC