- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Wed, 20 Jan 2010 11:01:40 +0000
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-canvas-api@w3.org, HTML WG <public-html@w3.org>
- Message-ID: <55687cf81001200301s32a954d1p8c85ae00b2f6ac45@mail.gmail.com>
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
Received on Wednesday, 20 January 2010 11:02:41 UTC