minutes: canvas sub-group of html a11y task force telecon, 2010-02-01 [draft]

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:20 UTC