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

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-canvas-api-request@w3.org wrote on 01/19/2010 04:39:25 PM:

> Ian Hickson <ian@hixie.ch>
> Sent by: public-canvas-api-request@w3.org
>
> 01/19/2010 04:39 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS, David Singer
> <singer@apple.com>, James Craig <jcraig@apple.com>
>
> cc
>
> public-canvas-api@w3.org, HTML WG <public-html@w3.org>>
>
> Subject
>
> 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.
>

This might work with one page but a user will want to specify their needs
on any page they go to. I also don't want to pass the selection of
alternative UIs off to the developer.

I also don't want to force the author to show both at the same time. You
are basically forcing authors to insert a selection mechanism using script
on every page they write.

I don't agree with that approach.
>
> > 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).
>

Again, you are pushing the burden of UI selection to the author.

>
> > 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.
>
>
You may want the content to rendered in prose on the page vs. having the
user go to another page to look at it.
Why make the user go elsewhere when they just want to see different
information.

>
> > 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?
>
Only if the author made the content AT Interoperable using standard
controls, ARIA, etc.
And yes, the blind user does not care about high contrast settings. They
only care about AT Interoperable.
In the same mind set a color blind user does may not care about being AT
Interoperable. This allows the provision for the user to decide what
collection of properties need to be satisfied.

>
> > 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.
>
Not everyone may want this. Some may not want the clutter. Some may simply
want the text book vs and read it themselves vs. a digital talking e-book.
Again, you are specifying your personal preference. So, making something
available to everyone and letting someone choose what they want are not the
same.
>
> > > > 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).
>

Where we disagree is that the selection of UIs should not be pushed off to
the author and we need a way for
user selection.
>
> > 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.
>
>
nobody is saying you cannot. Selection should be a browser feature but not
a content feature unless the author chooses to do that.
>
> > > > <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.
>
sure we can. We can specify how the browser is suppose to process content.
That was something you asked us to do for ARIA.
>
> > > 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.
>
Again, this is a question of whether the selection burden is pushed off to
the author. This also increases content footprint.
>
> 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.
>
Taking people elsewhere is disorientating. This is old style HTML
development where you ask people to load an entirely new page for one piece
of content. Imagine a mashup doing that for each service loaded into a
page.

> 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.
>

Again, you are pushing the burden off to the author.

> 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.
>
>
Again, the burden is put on the author. Not all sites want to do this.

> > 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.
>
If that were true some would not be asking that table summary be removed.
So, I disagree with this assertion. We want to make things better in HTML 5
and there are instances where we have been picking and choosing, to our
convenience, what you choose to be backward compatible. (I don't want this
to digress into a summary discussion however)
>
> > 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.
>
I think both statements are true. What I am saying is that the user can't
tell the author he can't offer alternatives.
>
> 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.
>
What I am saying is that different alternative visual mediums may be
required for some users. Not all users are blind. Some are cognitively
impaired and simplified visual content may be provided for some content as
an alternative. I think you are assuming the fallback content will satisfy
everyone's needs. It may not.

>
> 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.
>
Yes. by focus model I mean the visual rendering of focus would be on the
canvas. I should have clarified  this.
>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>