A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on IRC (such as one of these permanent autoconfirmed members).

Canvas

From WHATWG Wiki
Revision as of 14:56, 19 January 2012 by Richschwer (talk | contribs) (Limitations of real-world use cases)
Jump to: navigation, search

Real world uses of Canvas

List some real-world examples of uses of canvas that are examples of things best done with canvas and not other features of HTML:

Limitations of real-world use cases

In this section, discuss specific examples from the list above and explore what those use cases fail to do (e.g. in terms of accessibility) which they should do.

https://zewt.org/curves/
Keyboard users can't tab to specific points and move them from the keyboard.
  • Should show focus ring around the selected point when moving by keyboard movement.
Limited-vision users can't zoom around the specific area that the user is manipulating.
It's a pity the mouse cursor has to be manually changed onmousemove.
Finger users can't drag their finger across the canvas to find the various interactive parts of the document, because the user agent doesn't know ahead of times which parts are interactive.
http://www.ludei.com/sumon
can't navigate and activate buttons using keyboard
various UI controls not identified as controls or operable for range of users.
can't zoom in to specific controls on the UI
can't communicate time remaining info to some users
With scrollIntoView the author could bring the numbers into view within the canvas but the assistive technology cannot assess how to place the magnification point around the element as it does not know the corresponding role of the element. Many magnifier users are able to use a mouse so they would not be relying on keyboard for focus.
A magnifier vendor will want to allow the user to search the gridd of numbers to find an appropriate match. However, the magnifier cannot provide the ability to magnify around the number as it does not know the location of the element.


https://www.lucidchart.com/documents/edit?button#4766-6fcc-4f18275d-b546-71450a7ac5be?demo=on&branch=5a613773-81d2-48fb-b3a5-4fe780978ab4
A
With scrollIntoView the author could bring the numbers into view within the canvas but the assistive technology cannot assess how to place the magnification point around the element as it does not know the corresponding role of the element. Many magnifier users are able to use a mouse.
A magnifier vendor will want to allow the user to search the drawing surface of the flow chart to find an appropriate match. However, the magnifier cannot provide the ability to magnify around the number as it does not know the location of the element.
It should be noted that an advantage canvas has over SVG is that it shares the same DOM and keyboard navigation model as HTML. So, if one were to mix the best features of HTML (interactive widgets) with a drawing technology, including things like semantic relationships between elements, canvas is a better choice. So, SVG is not necessarily the preferred technology for accessibility. So, where we have a flow chart region of drawing objects the author could implement an HTML or an HTML/ARIA-enabled list box in fallback content inside a navigation section and a screen reader could bring it up in the list of navigable landmarks and it could be included in the keyboard navigation order.
From the previous bullet, the magnifier cannot assess the location location of the element in order to position the magnifier within the context of a list box.

Proposals

In this section, propose alternatives to improve canvas to make it easier to fill in the limitations listed in the previous section.


Examples

Take the pages from the first section and show how they would be changed to use the proposals in the previous section.