Re: Fw: 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-html-request@w3.org wrote on 01/12/2010 04:52:12 PM:

> Ian Hickson <ian@hixie.ch>
> Sent by: public-html-request@w3.org
>
> 01/12/2010 04:52 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-html@w3.org
>
> Subject
>
> Re: Fw: Proposal: Canvas accessibility and a media querries approach
> for  alternative content (Action Item 6 in the HTML Accessibility Task
Force)
>
> On Mon, 11 Jan 2010, Richard Schwerdtfeger wrote:
> > >
> > > Presumably, the fallback subtree would be used for all user agents
> > > that do not support <canvas> (whether because they're not visual, or
> > > because they're legacy UAs).
> >
> > Actually, that won't work as the visual rendering is assumed to be the
> > canvas.
>
> Are you sure? It seems to work fine for me. A legacy UA would simply
> ignore the <canvas> elements altogether, and handle the fallback content
> natively. A non-visual UA would similarly use the fallback contents and
> ignore the canvas and scripted calls to the canvas. Why would it not
work?
>
>
> > The fallback is intended to be used to drive the accessibility
> > tree with canvas being the rendering of it.
>
> Sure, in visual UAs that support <canvas>; those are not the only case,
> however.
>
>
> > 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?
>
I explained this. A fallback DOM bound to canvas may be different from an
alternative visualization. I already provided the subway example. In the
subway example shadow dom would not work and an alternative visualization
would be more appropriate. And then you actually have to choose the
alternate visualization. That would be done using a media query. The author
certainly does not want to render both UIs and clutter the UI with both.
That would be bad. Allow the user to pick which they want. The current
canvas model i is broken.

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?

>
> > 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.
>
No it does not. A low vision user wants to operate the visible rendering.
The shadow content would provide
no styling as there is no reason.
>
> > In fact, given my understanding of the definition of a fallback tree
> > that does not accurately reflect the intent. The intent of the DOM
> > Subtree is to deliver accessible objects and structure represented in
> > the visual canvas.
>
> Yeah, maybe "fallback" is the wrong word as well. I guess it's just the
> regular DOM tree. The canvas descendants, if you will.
>
>
> > We had not addressed the use case of browsers that do not support
canvas as
> > our assumption was to support the HTML 5 spec. in its entirety. That
said,
> > what you are considering to be the fallback could be the alternate
visual
> > modality:
> >
> > <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.
>
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. The HTML strategy here is deficient. Sorry. This might have been
fine when we were working to get implementations in browsers to show things
worked but now we are creating a full blown spec. to which user agents and
authors are going to comply with.

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

>
> > > Why not use real toolbars and buttons?
> > >
> > >    <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>
> > >    </canvas>
> >
> > I have asked that we support input controls as well in the the aria
> > mechanism as well. I am waiting to hear back from the browser vendors
if
> > this is acceptable.
>
> Ok.
>
>
> > > > I think where we may differ is that while alternative
visualizations
> > > > would benefit all users and that they could be applied to the
entire
> > > > page, it is not not necessary that alternative modalities be
applied
> > > > only to the entire page. There is tremendous value add in providing

> > > > alternatives to individual regions like canvas, video, and audio
> > > > within the page as the rest of the page may adequately meet the
> > > > needs of the modality preferred by the user.
> > >
> > > Sure, but isn't this already possible? It's pretty common practice
for
> > > an application to provide different ways of interacting with it. It
> > > doesn't seem like we need to do anything special to support this.
> >
> > This is true. However, what is accessible is based on user needs. An
> > arbitrary application does not know what a user wants. By allowing a
> > user to apply their own media query capability they can
programmatically
> > tell the browser what that would be through the use of the style sheet.
>
> 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.
>
>

I think I have explained this sufficiently.

> > > I'm basically in agreement with what you're proposing -- but I don't
> > > understand how it is different than what the spec already does.
> >
> > I hope the above makes this clearer. The purpose of the accessible
> > canvas DOM I hope explains this better.
>
> I don't understand why we would want, or need, to make the accessible
> canvas DOM any different than the regular fallback DOM.
>

I explained this. Sounds like you are more concerned about supporting
browsers that don't support all of HTML 5 but in doing so we would also not
provide for fallback content selection based on user requirements. I have a
fundamental concern with that approach. It means the HTML working group is
fence sitting on the spec. and tieing our hands.

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