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

Hi Ian, to get some clarification on what the spec requires

If a user clicks on a region of the canvas that has been scripted to
naviagte to a n URL with an associated focus rectangle that is associated
with an <a> element inside the canvas. Does the click get passed to the link
and a navigation event get triggered?

<canvas>
<a href="example.html>example</a>
</canvas>

regards
stevef
2010/1/19 Ian Hickson <ian@hixie.ch>

> 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.   `._.-(,_..'--(,_..'`-.;.'
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html