minutes: HTML Accessibilty TF Canvas Sub-team telecon 2010-11-22 [draft]

aloha!

minutes from the 22 november 2010 meeting of the canvas sub-team of the
HTML5 a11y task force can be accessed as hypertext at:

http://www.w3.org/2010/11/22-html-a11y-minutes.html

as an IRC log at:

http://www.w3.org/2010/11/22-html-a11y-irc

and as plain text following this announcement -- as usual, please report
any errors, clarifications, omissions, and the like by replying-to this
announcement on-list...

canvas sub-team members are asked to review RichardS' "Reworked Canvas 
2D API using our revised DrawFocusRing" proposal, available at:

http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html

the cover emessage for which can be found at:

http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0035.html
     _________________________________________________________

                               - DRAFT -

             HTML Accessibility Task Force Teleconference

22 Nov 2010

Agenda
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html

   See also: IRC log - http://www.w3.org/2010/11/22-html-a11y-irc

Attendees

   Present
          Rich, Gregory, Charles

   Regrets
          David_Bolter, Frank_Oliver

   Chair
          Rich

   Scribe
          Gregory_Rosmaita

Contents

     * Topics
         1. Current CANVAS Issues
         2. Defects (Bugs) Logged
         3. Non-RTE Canvas Scenarios
         4. WHAT WG Feedback
     * Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 22 November 2010

   <richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Subteam

   <scribe> scribe: Gregory_Rosmaita

   <scribe> scribenick: oedipus

   <richardschwerdtfe> agenda: 
   http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html

   minutes will be logged to:
   http://www.w3.org/2010/11/22-html-a11y-minutes.html


Current CANVAS Issues

   CP: second kind of canvas bvehavior used by webkit --
   getCSSCanvasContext -- slightly different semantics, but only
   implemented by webkit

   <Downchuck> getCSSCanvasContext

   <Downchuck> http://webkit.org/blog/176/css-canvas-drawing/

   RS: for zooming detection?

   CP: yes -- canvas should work as is now -- need metrics to know
   resolution
   ... css canvas drawing makes sense to have drawing manager
   ... set backing to meet resolution when canvas element created --
   that would create a lot of overhead authors would have to work
   around, but if use get.css.canvas.conent, can do

   RS: applies only to CSS?

   CP: CSS canvas has semantic relationship with rendering -- doesn't
   change my proposal, but interesting idea

   RS: CP's proposal is "if get metrics, can get dpi" -- MS exposing
   everything on right track has been argued

Defects (Bugs) Logged

   RS: satisfied

   <Downchuck>
  
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029091.html

   CP: pretty happy with them

   <Downchuck> Robert O'Callahan proposal for CSS based backing store
   on a canvas

   RS: haven't heard from FO, but for now consider nothing new
   ... CP, could you edit current canvas 2d api modifications document

   CP: yes, needs a bit of tidying up

   RS: for drawing FocusRing, way set up now, diff from HTML5, is to
   draw FocusRing based on current drawing path have today -- if OS has
   high-contrast mode, should draw in its place so can ensure when made
   call, actually happened and mapped to a11y API and UA

   CP: don't see problems with that as long as realize have to use the
   extents can work with strangely shaped paths -- UA can decide what
   path -- works

   RS: if read spec, magnifier, based on type of object will deterimine
   how want centered

   <Downchuck> extents

   RS: problem with hixie's proposal -- provide x and y coordinates
   assuming author knows (should be up to magnifier) - FocusRing
   separate from caret and selection
   ... want to ensure this is understandable

   CP: 2 separate things caret tracking and focusRing

   RS: CP will review; FO and DB will review what CP produces


Non-RTE Canvas Scenarios

   RS: made valid point about only checking hit test on checkbox image
   and not the entire checkbox input element -- take code and replace
   hixie's broken code
   ... going to look deeply into RTE
   ... is there basic code for RTE that we can work off of?

   CP: code bass designed from ground up to match implementation
   standard -- doesn't use DOM nodes in shadow DOM, which is needed to
   get it working
   ... complex because getting mouse coords and mapping to text is
   quite a bit of work

   RS: why i didn't want to start from scratch

   CP: need stylable select elments was beginning, built up DOM, when
   got to input type="text" realized a whole lot of other issues -- do
   need a large library to do RTE

   RS: what licensing?

   CP: CC 0 public domain
   ... 100% clear

   <Downchuck> http://creativecommons.org/publicdomain/zero/1.0/

   RS: if you could provide me a link and the liscense (creative
   commons zero) -- am U.S. citizen, so can do public domain

   <Downchuck> http://w115.visc.us/html/textbox.html

   CP: "dual lisence" by explicitly stating is "public domain" -- CC0
   is for those where public domain doesn't apply -- if make changes,
   need branch or fork
   ... at bottom of demo, used pseudo CSS -- need to observe in
   relation to line breaks (for braille interfaces -- could be done
   with unicode) -- CSS generated text easiest way to mark changes in
   content -- generating style and injecting image

   RS: put a line break in actual content, or CSS-wrapping

   CP: can put line break, but :psuedo CSS method of inserting content
   directly -- unicode and existing HTML semantics should work fine
   ... CSS content spec is on the right path

   <scribe> agenda:
   http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html

  
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html

   <richardschwerdtfe>
   http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0034.html

  
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0035/CanvasEditor.html

   works in IE -- GJR try out with JAWS and IE9

   GJR: will do

   RS: set selection from contenteditable areas -- how to do across
   browsers
   ... FO supposed to have API differences for what they've done for IE

   CP: anything public?

   RS: windows.selection -- works on contenteditable areas -- trying to
   ascertain what for caret
   ... in FF, have collapse property

   CP: found similar in chrome -- empty range but different property --
   in extentions api despite lack of caret browsing in Chrome
   ... if implemented, ranges will work for grammar and spelling areas
   -- how to implement is more difficult -- want to set up range, then
   get more ranges from it for a spell or grammar chacker -- might just
   attach to a single element for ease of use -- get.Element on current
   DIV get.Element.grammarranges
   ... don't want to do on multiple ranges at once

   RS: API for that?

   CP: not for spell checking -- range apis fairly well known and
   implemented to standard, including caret position, albeit in a weird
   way -- caret position another range with additional properties

   RS: selection, then collapse?
   ... Chrome and FF try to keep same thing -- get window.selection
   return a range -- when have caret, is collapsed

   CP: want to get properties -- if fire a select, may collapse
   inadvertently

   RS: window selection, range X, select from 0, if range X is
   collapsed, is caret
   ... don't know what happens in IE -- have to find out from FrankO

   CP: textareas?
   ... spelling and get.range on spelling -- get all spelling ranges
   inside a single element -- less straightforward is get me all
   spelling errors in all ranges -- add to collection of ranges
   prototype, and spit out antother collection of ranges -- mozilla did
   work on allowing multiple ranges being chosen at same time

   RS: going to investigate code; CP please review what i have for
   caret
   ... updating code very important -- don't know what browser hixie's
   code works in, but didn't work in IE or FF for me

   CP: label might be reason to put out as survey item -- who is
   implementing label correctly?

WHAT WG Feedback

   CP: brought up baseline and zoom issues -- have mozilla talking to
   me about zoom use case --
   ... a lot of feedback has been "this isn't a valid use case"
   ... no response on baseline issue -- need to know baseline so can
   get text on same baseline when in 2 diff font sizes
   ... getting some traction on ideas from mozilla

   RS: glad MS has keyboard nav into sub-tree -- first time been able
   to do example with shadow DOM -- that is a BIG plus

   GJR: will check out with IE9 and JAWS 12

   RS: need to look at caret tracking in TEXTAREAs

   CP: did a lot of work on caret tracking a while ago -- IE6 did not
   have way to do that -- would tell what was highlighted, but not
   where it was -- fixed since ranges implemented
   ... allowable element -- is shadow DOM outside or inside of the DOM?

   RS: part of DOM -- just treat as shadow DOM

   CP: items that need to be initialized such as script src= need to go
   through process -- if embedded inside CANVAS shouldn't be
   initialized unless CANVAS isn't supported
   ... explicitly say items that need initializtion should not be
   initialized, should be ok
   ... if add SCRIPT to shadow dom, will initialize, before scripting
   happens, should create SCRIPT in DOM but not initialize it
   ... "activated content" is the key term

   RS: if canvas isn't supported, UA has to fall back to fallback
   content
   ... what if stick IFrame in middle of CANVAS?

   CP: would make sense that IFrame available in DOM, but src="foo" bit
   doesn't load so IFrame would be empty
   ... keep existing semantics in place and work with actual language
   -- can have IFrame inside shadow DOM, not going to do anything
   unless use scr= for scripting

   RS: target on scriptiong side?

   CP: yes

   RS: require spec change?

   CP: do need to state how IFRAME is handled in shadow-DOM --
   hopefully we just need an explicit statement of that rather than
   reengineering

   RS: haven't seen any comments from hixie on defects on canvas
   ... have code to test -- now need to ascertain support

   CP: 1 comment: there is a complexity introduced by separating canvas
   2d context from canvas element -- basic ammount of implementation
   that needs to be in any canvas content -- shadow DOM itself is to be
   found in CANVAS tag, not canvas context -- wasn't sure if that was
   clear
   ... sub-DOM itself should be addition to canvas element -- should
   work same for 2d and 3d context

   RS: 1-to-1 mapping for elements in DOM to what is seen on visual
   canvas

   CP: want to add to that -- elements inside CANVAS sub-tree do not
   get initialized in browser mode -- script still available via DOM,
   just not loaded on window.load -- want to ensure based on actual
   reality

   RS: work on that?

   CP: yes -- work on canvas element wording

   RS: so another change proposal for canvas?

   CP: yes

   [adjourned]


Summary of Action Items

   [End of minutes]
     _________________________________________________________

Received on Monday, 22 November 2010 21:08:41 UTC