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

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.

I would expect that the answer to your original question -- how to handle 
fallback for non-canvas-capable browsers -- is the same as the answer to 
my question -- how to handle fallback for blind users.

If the answer is "blind users can't use the product", then the answer to 
your question is likely something like:

   <canvas>
     ...controls...
     <p>No alternative non-visual version of this tool is available.</p>
   </canvas>

If the answer is that there is another page for those users, then the 
answer could be:

   <canvas>
     ...controls...
   </canvas>
   <p>Alternative versions: <a href="text.html">text-only</a></p>

Since <canvas> is only usable with script, a third alternative that has 
the same effect as the first above but that doesn't show the message for 
users with <canvas> support, and doesn't show the controls for users 
without <canvas> support, could be:

   <p>No alternative non-visual version of this tool is available.</p>
   <canvas hidden>
     ...controls...
   </canvas>
   <script>
     // if canvas is enabled and supported, remove the hidden attribute 
     // from the <canvas> (and maybe add it to the <p>)
   </script>

(Alternatively, instead of relying on hidden="", the elements could be 
dynamically inserted and removed from the DOM.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 14 January 2010 02:31:45 UTC