- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 24 Feb 2010 09:02:58 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org, public-canvas-api-request@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Message-ID: <OF74A9651E.4A90B333-ON862576D4.00520423-862576D4.0052AB77@us.ibm.com>
Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist public-canvas-api-request@w3.org wrote on 02/23/2010 08:17:15 PM: > Ian Hickson <ian@hixie.ch> > Sent by: public-canvas-api-request@w3.org > > 02/23/2010 08:17 PM > > To > > Steven Faulkner <faulkner.steve@gmail.com> > > cc > > Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-html- > a11y@w3.org" <public-html-a11y@w3.org>, public-canvas-api@w3.org > > Subject > > Re: Please vote on the canvas accessibility proposal > > On Tue, 23 Feb 2010, Steven Faulkner wrote: > > > > if the content of the canvas sub tree is exposed to AT and focusable > > elements are included in the tab order, by default, then regardless of > > what browser an AT user has they will get get this content. Regardless > > of what relationship any interactive content has to the canvas content, > > keyboard only users will be able to tab into and interact with focusable > > elements. > > > > So for example if I am a keyboard only user and encounter a canvas > > element that includes a link or 2 links or many that are not associated > > with the displayed canvas, because they are "fallback" then focus will > > be lost to the users, end result= confusion > > This is the case regardless of whether an AT is involved or not. > > > > or I am an AT user accessing the page *using* Firefox, I encounter the > > message "your browser does not support canvas get Firefox" end > > result=confusion. > > Indeed. > > Pages that do this are non-conforming. Authors are required to provide > accessible alternatives. If author are going to ignore the spec on this, > why would they not equally ignore the spec for "adom" and include it when > it is not appropriate, causing the same problem? > This statement is incorrect on three points: - Some authors MAY have a requirement to support accessible solutions. - There is nothing in HTML 5 that says you MUST produce accessible content. - Authors are not required to produce accessible ALTERNATIVE content. They should be able to choose whether to make something directly accessible or provide an accessible alternative based on their requirements and tools at their disposal. > I don't understand why you think it's possible for authors to follow the > spec on the one hand, while using the fact that authors _can't_ follow the > spec on the other as evidence that the feature is needed. Either authors > are going to care about what the spec says, or they're not. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Wednesday, 24 February 2010 15:03:46 UTC