HTML Accessibility Task Force Teleconference -- 29 Nov 2010

<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

- DRAFT -

HTML Accessibility Task Force Teleconference

29 Nov 2010

Attendees

Contents