Re: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

On Jan 13, 2010, at 18:31 , Ian Hickson wrote:

> On Wed, 13 Jan 2010, David Singer wrote:
>> On Jan 13, 2010, at 18:03 , Ian Hickson wrote:
>>> On Wed, 13 Jan 2010, David Singer wrote:
>>>> On Jan 12, 2010, at 14:52 , Ian Hickson wrote:
>>>>> 
>>>>> I don't understand why we would want, or need, to make the 
>>>>> accessible canvas DOM any different than the regular fallback DOM.
>>>> 
>>>> I may be misunderstanding the question, and if so, I apologize.
>>>> 
>>>> If I have some kind of scientific visualization with controls that I 
>>>> do in canvas, and there really isn't a way to do that without canvas 
>>>> (i.e. no real way to draw it), my fallback for browsers not capable 
>>>> of canvas may be "we regret the loss of picture", whereas my shadow 
>>>> for the accessible user using canvas may well be a set of controls -- 
>>>> check-boxes ('Gravity morphing?') sliders ('Phi incursion angle!'), 
>>>> buttons ('fire photon torpedo!') and so on.
>>>> 
>>>> If I am right, I would tend to ask the opposite: how can we be sure 
>>>> that the fallback for non-canvas-capable browsers will essentially 
>>>> always be the same as the shadow for canvas-capable browsers needing 
>>>> accessible access?
>>> 
>>> In this scenario, how is the data made accessible to blind users?
>> 
>> Why is the accessibility need assumed to be visual?  We have 
>> motor-impaired people who cannot operate a mouse, but who can interact 
>> with buttons/sliders etc. using, for example, voice controls.
> 
> I didn't mean to suggest that the accessibility need would always be 
> visual, I was just asking about how that need was met in your example.
> 
> In your scenario, it's clear that users with visual UAs are catered for, 
> whether they need ATs to help with poor eyesight, ATs to help with poor 
> motor controls, or other needs. However, it isn't clear to me how it 
> handles users with no sight at all.

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.


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 14 January 2010 17:42:02 UTC