W3C home > Mailing lists > Public > public-html@w3.org > February 2012

RE: Issue 131 Change Proposal

From: Frank Olivier <Frank.Olivier@microsoft.com>
Date: Mon, 13 Feb 2012 17:24:32 +0000
To: Charles Pritchard <chuck@jumis.com>
CC: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Message-ID: <91175A762AB48840AF1473514B26B475517A81E9@TK5EX14MBXC262.redmond.corp.microsoft.com>
I agree with what you'd said - it might be the case for some authors that in the fallback case, the fallback content is not styled like the canvas subdom content.

But nothing prevents you from detecting either case and styling the fallback content / subdom content differently.



-----Original Message-----
From: Charles Pritchard [mailto:chuck@jumis.com] 
Sent: Sunday, February 12, 2012 11:54 AM
To: Frank Olivier
Cc: Benjamin Hawkes-Lewis; public-html@w3.org; public-html-a11y@w3.org
Subject: Re: Issue 131 Change Proposal

On 2/12/2012 2:29 AM, Benjamin Hawkes-Lewis wrote:
> On Fri, Feb 10, 2012 at 9:10 PM, Frank Olivier 
> <Frank.Olivier@microsoft.com>  wrote:
>> I would like to submit http://www.w3.org/wiki/Reading_text_in_canvas 
>> as a change proposal for this issue.
> How does this proposal address screen magnifier content focus for 
> multi-line spans of text?
>
> Also, the proposed spec text says:
>
> "User agents that support caret browsing can use the subdom text 
> cursor position to indicate the current caret location on the screen."
>
> How is that supposed to happen?
>

Also this: "When an author renders text on a canvas with fillText or strokeText, they must also add an html element (div or span) with the same text, styling and position to the canvas subdom". It may be the case that styling can not be met, that styling would not result in similar dimensions, that the font available to Canvas may not be available in the subdom, and that calls to fillText and/or strokeText may be decorative or otherwise repeated for a particular effect. I've consistently argued that the fallback content should managed by the author, and should be flexible enough not to interfere with the A11y of Canvas itself. What I mean by that is: the author should be able to style the fallback content independently of the Canvas element.

I've continued to push for a CSS element to allow us authors to toggle on-and-off visibility of the fallback content v. the Canvas bitmap and width/height. This proposal would go against that effort.

<canvas><label><input type=checkbox> Example</label></canvas>

In real-world use, I want the fallback content to look like a typical form, though the Canvas display may be quite different.
I do not want my fallback content CSS style to match my Canvas presentational style, in most cases.

-Charles

Received on Monday, 13 February 2012 17:25:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:44 GMT