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

Re: Please vote on the canvas accessibility proposal

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:02 GMT