- From: James Craig <jcraig@apple.com>
- Date: Thu, 14 Jan 2010 10:17:59 -0800
- To: David Singer <singer@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, Richard Schwerdtfeger <schwer@us.ibm.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-html@w3.org
On Jan 14, 2010, at 9:41 AM, David Singer wrote: > OK. I agree, I don't see much functional difference between "the UA can't render canvas" and "the user can't see the rendered result". And maybe this is the more common accessibility need (coping with users unable to see the canvas), and motor impairment is less frequent. I had always assumed that accessibility for canvas controls kinda implied that the canvas itself was still useful. That's the idea behind the 'shadow DOM' approach. Whether or not the canvas is visible, the shadow DOM's content is still accessible to the keyboard and contains all the role/state/property information of each equivalent control, therefore maintaining its usefulness to everyone, whether vision-impaired users on a screen reader or dexterity-impaired users on a standard keyboard, or people using another assistive technology like the speech recognition software you mentioned earlier. To answer Ian's question, the difference between this approach and standard fallback content is that the focus model would change. Shadow DOM contents can still be focusable (and therefore perceivable, operable, and understandable by persons with disabilities) even when the canvas is rendered visibly. James Craig
Received on Thursday, 14 January 2010 18:18:33 UTC