W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2012

Re: Canvas and ARIA alternatives

From: Pierre Dubois <duboisp2@gmail.com>
Date: Sat, 4 Aug 2012 00:47:31 -0400
Message-ID: <CAPGwD7ieVHuoQFcdjxs2wQUask=rG6+pcFDxsyqXX3+jTskX2g@mail.gmail.com>
To: Ian Sharpe <isforums@manx.net>
Cc: rcorominas@technosite.es, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, WAI Interest Group <w3c-wai-ig@w3.org>

Regarding the accessibility of the canvas element, I would prefer to have a
basic piece of HTML and enhance it on a canvas or SVG by using the
progressive enhancement strategy.

For a concrete example see :

That example is to show the result of the creation of a complex graphic
based on a usable complex data table. This project was integrated recently
in the Web Experience Toolkit (WET). (https://github.com/wet-boew/wet-boew)

One of the advantages with the WET is about on how it is easier for the Web
Editor to generate a graphic. That is done simply by adding the class
"wet-boew-charts" to the "table" element and once the javascript is on, the
usable table are parsed and the graphic are generated. It is also possible
to customize the graphic by adding other class to the appropriate HTML
table element (table, th, td).

Once the graphic are generated, I decided to auto set the attribute
aria-describedby on the figure element to provide a better accessibility.
The aria-describedby attribute have a reference to the HTML table.
Do you think that is a sufficient technique to set the accessibility for
the Canva / SVG element in my case ?



Pierre Dubois

On Fri, Aug 3, 2012 at 9:55 AM, Ian Sharpe <isforums@manx.net> wrote:

> Thanks Ramón, particularly for the examples. From the original message in
> this thread I got the impression that the canvas element was being used for
> more "mundane" user input and the canvas used to just add aesthetic fluff
> rather than essential functionality.
> That said, I would still make the following points:
> 1. I'm not sure why you feel that I am "assuming that every user input can
> be achieved with a "simple" user interface" using selects and radio buttons
> or any of the other standard elements. I also totally understand that the
> model for user interaction is changing and will continue to change
> requiring
> new widgets / techniques. I would just like to see accessibility moved up
> the priority list as I'm sure so would everyone else.
> 2. What's happened to SVG? As far as I am aware, canvas was primarily
> introduced into HTML5 as a more performant graphics rendering surface and
> so
> can understand why this is important in terms of video games, but SVG would
> seem to offer an obvious, more accessible alternative in a couple of the
> examples you give.
> 3. While I have used the canvas element for rendering graphics previously,
> I
> certainly would not consider myself to be an expert on using it and it's
> modes of interaction. However, is it not possible to simply provide
> accessible elements to manipulate / interact with the canvas? This may be a
> slightly naive question but it would be helpful if I could better
> understand
> the issue.
> 4. I think we all agree that innovation will happen whatever we do. I just
> feel that the web, in contrast to proprietary technology, has a
> responsibility to us all to try and limit exclusion where ever possible.
> And
> given our limited resources, I feel we have a better chance of improving
> accessibility for more people by focusing primarily on the most common
> use-case scenarios. Yes we certainly need to be involved in the development
> of new technology to incorporate accessibility from the ground up, and if
> that's happening great. But it doesn't feel like accessibility is as high
> up
> the priority stack as I personally feel it should be given the inclusive
> vision.
> That's not to criticise those who are involved in this work by the way.
> Just
> that in the real world in which most of us exist, we rarely get to see the
> good work happening behind the seens. Maybe this kind of discussion will
> help raise awareness.
> And I'm certainly not trying to "stop the inevitable". I just feel that
> specifically in the case of the web and standards through W3C, we should be
> starting with the question, how do we provide new functionality in an
> accessible way, rather than let's include new technology and then try and
> make it accessible.
> Cheers
> -----Original Message-----
> From: Ramón Corominas [mailto:rcorominas@technosite.es]
> Sent: 03 August 2012 09:54
> To: Ian Sharpe
> Cc: 'Benjamin Hawkes-Lewis'; 'WAI Interest Group'
> Subject: Re: Canvas and ARIA alternatives
> Hi, Ian and all.
>  > I would be very interested to know of a use case for data input  > which
> requires the use of canvas and which cannot be achieved  > using a more
> accessible alternative approach. This discussion  > is a little abstract
> and
> I feel a concrete example may be helpful.
> Some possibilities:
> - Interactive graphs with grips where the user can move points to change
> parameters or show the results of their variations.
> - Flowcharting apps with flux diagrams or other diagrams with nodes, where
> users can organise processes, routes, organisational charts, etc., moving
> boxes/nodes and the connections between them.
> - 2D interfaces where the user can write by hand or draw shapes to perform
> actions (Real-world example: http://shapecatcher.com)
> - Interactive 3D interfaces where users can select parts of objects or even
> move them to interact with other objects.
> - Video games of many types
>  > Secondly, I'm certainly not advocating that we just sit on our  > hands
> and tell people to use existing features which they say  > do not meet
> their
> needs and again, I find this kind of  > over-simplification unhelpful in
> terms of the discussion.
> Over-simplification is what you are doing assuming that every user input
> can
> be achieved with "simple" user interfaces. As the web is moving towards
> more
> interactive applications and other things very different from "static web
> pages", new needs for sophisticated UIs arise, and many of them will not be
> as simple as selects, radio buttons, checkboxes and so on.
> > Thirdly, and this comes back to my point, if the foundations of the
> > web are based on openness and inclusion then surely these are the
> > principles upon which all decisions should be made over and above
> > anything else. I do appreciate that in reality, this goal maybe more
> > of a hope than ever realised, but I feel it needs to happen if we are
> > ever going to see an open and inclusive web.
> I cannot see the point of "simpler interfaces" as "more inclusive". What we
> should do is ensuring that new interfaces can also be made accessible, not
> trying to stop innovation, because innovation will occur anyway.
> > There will always be times when existing technology does not meet the
> > requirements of certain organisations to perform particular tasks in
> > the way they would like. That's fine. It's part of the natural
> > evolution of technology. But rather than trying to work out how to
> > shoe-horn in accessibility as an after-thought, surely it would be
> > better to work with these organisations to determine the most
> > effective solutions in order to incorporate them in an accessible way
> where appropriate.
> Why would I prefer to work with many different organisations to determine
> that maybe they really need these new solutions, instead of working in the
> technology itself?
> > Just build accessibility in from the start. It's part of the
> > guidelines
>  > and our recommendations after all. Indeed, surely  this is part of the
>  >
> W3C process? Maybe the work which you mention that is on-going is part  >
> of
> this process.
> And that is exactly what is being done with ideas aimed at ensuring that
> canvas can be made accessible from the start. Not
> > I know that it's not always possible to predict how a technology might be
> > used but if it is going to lead to significant problems in terms of
> > accessibility, I feel a better approach would be to work on "improving"
> > existing accessible technology to provide the desired functionality while
> > encouraging the adoption of accessible alternatives in the interim.
> How would you improve radio-buttons or checkboxes to simulate 3D
> interfaces or create video games?
> > Finally, I would be interested to know whether anyone believes that if
> for
> > example, the guidelines did prohibit the use of canvas for user input, it
> > would have no impact on the adoption of such an approach (which is what I
> > think you are saying in a albeit different way)?
> If browsers implement canvas and it is the solution that designers and
> developers need, they will use it. Guidelines and even laws already
> "prohibit" inaccessible uses of HTML or CSS, for example, but most web
> pages are still inaccessible. Maybe some organisations would not use
> canvas if they don't need it, but if they need it most legislations
> allow inaccessible uses if there is no accessible approach that can
> perform the task. Legislations will rarely prohibit innovation in favour
> of accessibility.
> > I'm sure some organisations or individuals would "do it anyway" as many
>  > do now despite current legislation in many parts of the world.
> > But I personally am seeing more of a trend towards working within the
>  > guidelines, particularly in government and larger organisations. And
>  > while we still have a long way to go, I am perhaps a little more
>  > optimistic (hopeful?) and don't feel it would lead to the beginning
>  > of the end of accessibility.
> That is because governments and many other organisations probably don't
> need canvas for anything. But this is not the case of many other
> companies, and sure it will not be the case for the video games industry.
>  > Indeed, I feel we perhaps need to at least think about pushing back
>  > little, particularly in situations such as this, in order to
>  > continue to make a difference. But maybe we're not far
>  > > enough a long the curve yet?
> And why not push forward better accessibility for canvas? Sincerely, I
> don't see the point of trying to stop the inevitable.
> Regards,
> Ramón.
Received on Saturday, 4 August 2012 04:48:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:41 UTC