- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 18 Dec 2006 21:07:51 -0500
- To: www-multimodal@w3.org
This is not a change suggestion for the InkML specification _per se_, but rather raising a concern that we have in accessibility that it would seem you will also have to worry about to make Ink-using applications consistently usable in their look and feel so as to be accepted by users. To co-exist with other sources in a shared canvas, you need to know what they are doing in all the dimensions of display phenomena that you enter yourself. InkML Reference: http://www.w3.org/TR/2006/WD-InkML-20061023 Issue Reference: Find "actual presentation properties" in (Member confidential link) http://lists.w3.org/Archives/Member/w3c-wai-pf/2006OctDec/0144.html Client-side scripts that attempt to meet accessibility guidelines by assuring color contrast between the effects they control and the surrounding background color of the canvas have run into problems when: >The CSS cascade resolves to 'clear' but there is a background color or image >that shows through -- layered by the operating system outside the control >of the CSS-driven rendering engine. Applications that share multi-user ink traces with platform imagery on a common canvas will encounter similar problems. The application will be color-coding the traces; and it will need to be concerned to allocate colors to the traces that will not only distinguish one trace from another but likewise be perceivable against the background arriving on the canvas from other sources. http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast We can't expect all the other content painting on the canvas to get transcoded into InkML but we should expect full information in some common canvas coordinates. In addition, one should be able to inspect starting from the underlying object model which is the origin of other-source canvas effects, as in HTML+CSS. There are similar problems with locations on the canvas. One common function of ink traces in whiteboard usage cases is to hook something in the background scene to attach an annotation. For this to work reliably, the final ink placement of the rendered text or other DOM objects must be knowable, reliably and accurately. >Brad A. Myers, Choon Hong Peck, Jeffrey Nichols, Dave Kong, and Robert >Miller. "Interacting At a Distance Using Semantic Snarfing," In Proceedings >of Ubicomp 2001. Sept 30-Oct 2, Atlanta, Georgia. pp. 305-314. >http://www.cs.cmu.edu/~pebbles/papers/pebblessnarfubicomp.pdf This is not anything that impacts the definition of the Ink format, but it is something that impacts the success of Ink-using applications. Please join with the WAI and the Working Groups working on the DOM and Delivery Context Interfaces to secure and ensure full and accurate access to this information about content rendered to the canvas. Al
Received on Tuesday, 19 December 2006 02:08:08 UTC