Hi James,
how is having this accessible to AT and keyboard only users better for them?
<canvas>
your browser does not support canvas get a better <a
href="firefox.html">browser</a>.
</canvas>
What can be predicted (with some confidence I think) is that users will
encounter this sort of subtree much more that they will encounter a subtree
that is designed to take into account their needs.
regards
stevef
On 20 February 2010 02:17, James Craig <jcraig@apple.com> wrote:
> I discussed agenda item #2 (@adom) today with Maciej and David, and I've
> come to agree with Ian's original argument that canvas contents should just
> be accessible by default. Though the idea of using an attribute was slightly
> more palatable than an extra element, adding a flag of any kind doesn't
> provide much benefit in the best case scenario. In the worst case scenario,
> it would render partially accessible content completely inaccessible.
>
> James
>
>
> On Feb 19, 2010, at 5:23 PM, Richard Schwerdtfeger wrote:
>
> Monday, 2010-2-15
> Time: 3:00pm-4:00pm Boston local
> Name: WAI_PFWG(CANVAS)
> Code: 92473 ("WAIPF")
> One time
>
> irc channel= #html-a11y
>
> Agenda:
>
> 1. Identify Scribe
> 2. Final Review for spec. ready adom text for Issue 74
> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0178.html
> 3. Progress on caret tracking: *
> http://www.w3.org/WAI/PF/HTML/track/actions/19*<http://www.w3.org/WAI/PF/HTML/track/actions/17>
> - Steve Faukner
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
>
>
>
--
with regards
Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium
www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html