- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Mon, 29 Nov 2010 21:15:38 +0000
- To: public-canvas-api@w3.org, public-html-a11y@w3.org, Charles Pritchard <chuck@jumis.com>, franko@microsoft.com
- Message-Id: <20101129211403.M96365@hicom.net>
aloha! minutes from the 29 november 2010 Canvas Accessibility subteam weekly teleconference are available as hypertext from: http://www.w3.org/2010/11/29-html-a11y-minutes.html as an IRC log at: http://www.w3.org/2010/11/29-html-a11y-irc and as plain text following this announcement -- as usual, please log any comments, clarifications, corrections, mis-attributions and the like by replying-to this announcement on-list note that the next Canvas A11y Subteam meeting will be held on Monday, 6 December 2010 at 2000h UTC -- logistics and other meeting info available at: http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings gregory. _________________________________________________________ - DRAFT - HTML Accessibility Task Force Teleconference 29 Nov 2010 Agenda http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0050.html See also: IRC log - http://www.w3.org/2010/11/29-html-a11y-irc Attendees Present Gregory_Rosmaita, Rich, Charles_Pritchard Regrets Chair Rich Scribe Gregory_Rosmaita Contents * Topics 1. Demo 2. Review Charles' change to <canvas> in HTML 5 3. Review of Charles updated draft change proposal to Canvas 2D API 4. Mozilla's refusal to supply the API needed in http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328 5. Implementation of Canvas 2D API context changes for non Rich Text Editing scenarios 6. Steps to assess what HTML elements are allowable in the shadow DOM 7. What are the next steps to address Rich Text Editing in HTML 5? 8. To Do * Summary of Action Items _________________________________________________________ <trackbot> Date: 29 November 2010 <richardschwerdtfe> meeting: W3C Canvas Accessibility subteam <scribe> scribe: Gregory_Rosmaita <scribe> scribenick: oedipus Demo CP: can fake some things - hitting certain checkbox would cause to do a select range -- more of a unit test GJR: yes, add things incrementally CP: test of API without having to know where to paint things ... ways we can start from ground and test it out RS: need UA vendors to make change or create java applet to move caret CP: like i did for focusable, can do for demo purposes --- need to compare cross-browsers ... for IE9, can make demo that doesn't need to have rich text editing ability but demo it will work -- draw caret in x y position -- just draw caret at appropriate blink rate and place ... hooking up to mouse right now not issue for testing purposes Review Charles' change to <canvas> in HTML 5 CP: filed sub-tree with WebKit -- will try and push with Chrome RS: defect logged against FF, but probably won't make for FF4 GJR: DBolter told me FF4 API frozen HTML Canvas Element: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0050/HTML_Canvas_Element.html CP: stuck in sentence -- none of elements in shadow DOM should be initializaed on OnPageLoad -- if IFRAME has src won't be loaded at window load -- need review by FO RS: that would go under which defect? CP: knowing which elements are to be supported ... don't be initialized if don't need be rather than list of elements plus 1 to CP don't be initialized Review of Charles updated draft change proposal to Canvas 2D API HTML Canvas 2D Context: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0050/HTML_Canvas_2D_Context.html CP: primary change had caret xy position based on text directionality RS: don't have problem with coordinate -- if selecting text and going to right, it is last position CP: understand --don't know if needs to be defined -- anyone programming will notice cursor placement problems RS: want to ensure that on a Mac, don't have caret tracking while doing selection -- had when selecting text going in certain direction, so is last thing selected CP: gotcha RS: if going to the left, last on left, if going to right... CP: when text selected, not caret RS: right CP: that is where caret is drawn so needs to be accessible ... kinda covered by note saying last drawn position must be tracked ... understand what RS intended now -- thought was related to single char RS: last char that got selected CP: exactly RS: take another pass at it? ... trying to get legal to look at code CP: will take another tweak -- if have any other feedback let me know Mozilla's refusal to supply the API needed in http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328 RS: pixel coordinates x and y pixel API CP: didn't want accessible to untrusted environment ... when installed as extention RS: how do you mean? CP: trusted extention -- plug-in -- put under security issue, though not ... trusted script usually because of security or very proprietary ... not available to normal web scripting environment -- didn't want people to tinker with zoom -- not tinkering, but being aware things are bigger -- diddn't want because said programmers wouldn't use correctly RS: in IE CP: don't care -- not going to move on it without mozilla support RS: if author wants to change view of canvas, what is problem? CP: someone will misinterpret screen metrics to implement own zoom effects -- use CSS zoom rather than onClick zoom -- based on idea, not going to give web devs one more thing to do wrong -- countered that good documentation would counter that; is a11y issue that affects people now, and have a proposal, but dead end -- is trying to use CSS media queries, but don't know if can get single... ... value from media queries RS: email? CP: on what wg list RS: will talk with david bolter CP: will send out summaries to try and get more than 1 person's attention on it davidb, can you help push moziilla on bug 11328? RS: if documented in HTML5 spec, that would be right answer Implementation of Canvas 2D API context changes for non Rich Text Editing scenarios RS: i'm working to get approval on that ... need FrankO for HTML elements that are allowable ... CP does your change address that? <davidb> oedipus, what bug database? davidb, http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328 CP: better approach is to keep src from initializing, not to have list of elements Steps to assess what HTML elements are allowable in the shadow DOM RS: need to get cross-UA support What are the next steps to address Rich Text Editing in HTML 5? RS: trying to get ok from attorneys to work on this ... have to write API addition for grammar and spell checking to get ranges CP: brought that up in WHAT WG -- got response from most UA vendors -- trying to push to get something out of them, but no spell checking a11y from DOM on basis of privacy concerns RS: that is fallacious CP: contenteditable -- addressed on own grounds -- trying to find middle ground -- not going to allow full API in untrusted scope -- if added password to list of suggested spellings, that password might be exposed via brute force, so any addition to dictionary is private ... raised "getSpellingRange" -- replied that going to expose user's language and their OS -- replied already have that exposed RS: can get ranges for selectoin CP: worried if have system dictionary and says something is misspelled, can tell what lang dictionary user is using -- exposing what natural language user preferes RS: just asking for where spelling is CP: for example color versus colour ... can we at least get range? ... even with range, they said security issue ... CSS proposal for highlighting -- without ranges, can only highlight -- can't make bigger because don't know range ... why not open to discussion so don't have separate APIs or use system prompt and make that a function, but so far, been met with negativity -- trying to make problem as small as possible RS: need to make proposal for it, submit it, and say "this is what we need for someone with low vision to operate a canvas RTE for spelling and grammar errors" and let them say "can't be done" if that is their opinioin CP: contenteditable is the key ... spelling a defect in contenteditable, not in each UA GJR notes still needs to route mouse cursor to speech cursor to get right-click dictionary entries in FF RS: where is this defined? CP: MSDN has APIs RS: HTML5 APIs for getSelection CP: think is under ranges ... API for text field selections ... single textarea API RS: link? <Downchuck> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection <Downchuck> http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html http://dev.w3.org/html5/spec/association-of-controls-and-forms.html#textFieldSelection RS: need to add for grammar ... use ranges for grammar CP: makes sense RS: getSpellingRanges and getGrammarRanges To Do RS: will write change proposal for that section http://dev.w3.org/html5/spec/webappapis.html#webappapis http://dev.w3.org/html5/spec/editing.html#contenteditable CP: leave off to UA and DOM RS: need one for selection, as well CP: "UA should offer way to move images..." ... about non-editable elements inside hosts -- drag'n'drop images ... trying to keep contenteditable entirely within UA -- will send summary of proposals to RS to work with RS: in contenteditable says up to UA to get selection? CP: basically RS: should or must? CP: not uppercase must, but prose must RS: we can just add text to do selection and query for ranges of grammatical and spelling errors CP: using GetRanges or getSelection -- easier to do on a given element -- either would work -- from HTML5 viewpoint, that is all UA side and not exposed to scripting environment RS: should be allowed ability to get selection? CP: could make a selection, don't talk about getting a selection -- can make selection with KeyDown events -- completely undefined save for drag and drop ... input method editor with spelling, grammar, etc. entirely up to UA and should not be scripted seems to be the spec's leaning RS: work on change for that ... could provide annotation/non-visible attribute (grammarerror tag) for elements that say this is beginning of grammatical range CP: a tag is technically semantic... ... what about spelling or grammar tag so is marked up is reasonable to have in HTML5 spec RS: that way, author of page can mark spelling or grammatical error -- write own grammar or spelling checker for canvas CP: applications -- canvas is a method ... would allow author to convey spelling mistake in text and would look/render same as other spelling mistakes RS: like to run this by frankO -- don't expose what is inside contenteditable section, then allow author to annotate in markup beginning of a grammatical error section, go through DOM to mark -- could then style it and do all sorts of stuff CP: absolutely davidb, thank you RS: propose a few new tags until more malleable on contentditable ... will ask FO what route to travel: work on contenteditable or introduce spelling and grammar tags CP: could do in ARIA -- aria-spellingerror RS: put on list for ARIA.next CP: spelling tag a good idea -- it is just a tag -- whatever styling one is using, use on this span <scribe> meeting: HTML Accessibility TF Canvas Sub-Team Summary of Action Items [End of minutes] _________________________________________________________
Received on Monday, 29 November 2010 21:18:22 UTC