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

On Thu, 14 Jan 2010, Richard Schwerdtfeger wrote:
> > >
> > > If we want to have an alternative renderable solution then we would 
> > > use an alternative modality as I had posted.
> >
> > I don't understand why one set of fallback content isn't enough. Could 
> > you show an example where the fallback DOM for accessibility purposes 
> > would be different than the fallback DOM for non-visual UAs, and where 
> > the latter case would not be something made available to visual UAs?
> 
> Sure. alternative content may not give the user a direct match for their 
> requirements in one form and for some users it may not be necessary. A 
> one size fits all approach may not work for the author.

I disagree. I have yet to see an example where this pattern wouldn't work:

   <p>See <a href="nocanvas.html">alternative non-graphical 
   interface</a>.</p>
   <canvas>
    ...accessibility DOM subtree for canvas...
   </canvas>
   <script>
    ...canvas script...
   </script>

This pattern is very flexible; the <p> can be removed from script if that 
is appropriate, or it can be hidden from specific media using CSS, or it 
can be moved to a more appropriate place (but still made available) when 
script detects that canvas is supported, etc.


> So an alternative visual modality could support one or more of the 
> following properties (From the Access For All standard now being 
> created) :
> 
> 1. highcontrast i.e. <visual highcontrast="true">
> 
> The alternative visualization may not support desktop settings but it may
> support high contrast which would meet the users needs

This seems like a presentation-specific issue and therefore belongs in CSS 
or CSSOM, not HTML or the HTML DOM. Specifically, if the user wants the 
_canvas_ to be made high-contrast, then the author will have to render a 
high-contrast version. Either the author can simply provide that as an 
option, or we can provide an API that exposes the user's options (e.g. 
CSSOM can have an API that exposes media queries, once we add this to 
the media query language).


> 2. longdescription i.e. <visual longdescription = "true">
> 
> This might be a solution for a drawing where an alternative interactive 
> solution is not provided but it is the best thing available.

Why is <a href=""> not suitable for this? Or even just an inline <p>? Or 
simply regular fallback in <canvas>, with the UA offering the user with 
the option to switch to the non-canvas view? A long description is useful 
for people with particular acceessibility needs, but it is not limited to 
those users, and thus we should not hide such descriptions from them. A 
regular link on the page is quite suitable for this purpose.



> 3. ATinteroperable <visual ATInteroperable = "true">
> 
> This might be a solution for an application that is interoperable with an
> assistive technology, like a screen reader, but does not support desktop
> font and color settings. A blind user does not care if an application
> supports high contrast settings.

Isn't that simply a description of what HTML supports by default?


> 4. <visual e-book="true">
>     <object ... "ebook plug-in">
> 
> Let's say someone wants to use <canvas> the equivalent of a kindle UI on 
> a web page. It is inaccessible but if it has an e-book alternative it 
> could be rendered.

As a user with no current need for ATs, I would still appreciate that 
alternative. Why would we hide it? This should be a front-and-center 
option made available to all users.


> > > A low vision user may choose to use the canvas UI where it is 
> > > supported and still be accessible using the fallback subtree.
> >
> > Sure. That works fine the way I described it (and the way the spec is 
> > written today), as far as I can tell.
>
> Important and to summarize: Where possible people with disabilities 
> would prefer to use the default rendering and make that accessible. When 
> that cannot be done we must allow for an alternative visualization.

I agree, but this is already completely supported. We don't need to add 
_anything_ for this to work, today, in all browsers, even those without 
<canvas> support. Just provide the alternative visualizations to all users 
using links or some other UI (e.g. tabs).


> The intent is to include the vocabulary in CSS to form a media query in 
> harmony with HTML 5 to choose the best content for the user.

Let the user choose what is best for them. You can't know if I prefer an 
E-book reader or a high-contrast option. Which I prefer can change from 
minute to minute.



> > > <canvas>
> > >   <default > /!--  canvas accessible DOM subtree (using this vs. the
> > > fallback DOM) assumes the canvas is a visual modality --/
> > >  <div role="toolbar"> /!-- The UI for each one of these is drawn in the
> > > visual canvas area --?
> > >        <div tabindex="0" role="button" aria-pressed="false">Double
> > > Space</div>
> > >        <div tabinex="-1" role="button" aria-pressed="false">bold</div>
> > >        <div tabindex="-1" role="button" aria-pressed="true">bulleted
> > > list</div>
> > >  </div>
> > >   </default>
> > >   <visual ATInteroperable="true"> /! This is the default Standard HTML 5
> > > accessible content supporting accessibility interoperability and could be
> > > used by browsers that do not support canvas-->
> > >       <menu type=toolbar>
> > >         <label> <input type=checkbox name=ds> Double Space</label>
> > >         <label> <input type=checkbox name=b> Bold</label>
> > >         <label> <input type=checkbox name=l checked> Bulleted List</label>
> > >       </menu>
> > >   </visual>
> > >   <visual>
> > >   </visual>
> > > </canvas>
> >
> > This would cause a non-supporting UA to show both sets of content, 
> > which wouldn't work.
>
> A user agent will do what the spec. provides for. This would be driven 
> by CSS Media queries.

Non-supporting UAs such as those shipping today would render both sets of 
content. There's nothing we can write in any spec anywhere that will 
change what those browsers do, however hard we try.


> > Why can't we just make everything available to every user? In practice 
> > it's not like there's going to be an overwhelming number of choices 
> > anyway. It's already common practice to offer multiple "modalities", 
> > or UI views, for example calendar apps let you pick a "month" view and 
> > a "week" view. It seems like this woul dbe similar.
>
> See above.

I didn't see an answer to this. I think this is the critical problem with 
the current proposal.


On Thu, 14 Jan 2010, Richard Schwerdtfeger wrote:
> 
> Could you show me how the user, independent of site chooses which UI is 
> rendered in such a form that does not clutter the page?

You don't do it independent of site. You just provide a link and the user 
clicks it.

For example, consider a very uncluttered page:

   http://www.google.com/

It has an "Advanced Search" link which provides an alternative modality. 
Or alternatively, consider:

   http://www.google.com/finance?q=IBM

An alternative modality could easily and unobtrusively be provided under 
the graph where it currently says "Settings | Plot feeds | Technicals" etc.

Or consider this actual <canvas>:

   http://www.whatwg.org/issues/data.html

It has both a fallback DOM _and_ alternative modalities in links at the 
bottom, without cluttering the page.


> Then the UA does not support HTML 5. Either it supports it or it does 
> not. You are asking us to support accessibility of a markup that is not 
> fully supported.

Yes. We have to, since right now "not supporting" is the majority case, 
and it'll be _a_ case for many years to come. HTML5 is designed from the 
ground up to be backwards-compatible, which means being accessible in both 
legacy UAs and new UAs.


> We need to allow the author to choose what content is rendered and this 
> fallback mechanism for browsers that do not support an HTML 5 breaks 
> that capability.

I do not agree with the premise of this statement. We do not need to allow 
the author to choose what content is rendered. The *user* has to have that 
choice.


On Thu, 14 Jan 2010, David Singer wrote:
> >>>> 
> >>>> 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 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".

There is _some_ difference, e.g. CSS used to style the fallback content in 
the former case can make use of 'color' usefully, whereas in the latter 
case 'color' is pointless.

In either case, we need to handle _all_ these cases. I don't see why there 
would be a particularly big difference in how we handle fallback for users 
with UAs that don't support <canvas> and for users who are blind or using 
a non-visual medium such as browsing the Web by voice.


On Thu, 14 Jan 2010, James Craig wrote:
> 
> 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.

That's what HTML5 requires today.


On Thu, 14 Jan 2010, James Craig wrote:
> 
> The fallback contents of a graphing application could be the editable 
> data grid whose values are synced with the values rendered in the graph. 
> Leaving the visual rendering visible would allow blind and sighted 
> co-workers to collaborate. For example, if I use my mouse to update the 
> sine curve on a visible graph, the bound value updates in the shadow 
> DOM, allowing my blind co-worker, Bob, to perceive that value. Likewise, 
> if he updates a value in the data grid, I can perceive that change as a 
> visible re-rendering of the chart. If this example sounds like a 
> hypothetical stretch to you, you'd be really surprised at how adept many 
> screen reader users are.

I completely agree with this. However, this doesn't require multiple 
modalities. It only requires one set of fallback content. It is not the 
case that Richard seemed to be referring to.

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

Received on Tuesday, 19 January 2010 22:39:58 UTC