This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There is a clear use case for creating a profile whereby an author could only use <canvas> and JavaScript as part of the profile opening the doors for a whole plethora of applications that run cross platform through the availability of a common drawing capability. At the 2010 tech plenary a person from the TV community about HTML profiles and the person stated that a subset of HTML which contained <canvas> and HTML would "hit the sweet spot." A number of issues still remain that are not addressed to address this issue. They are: - Provide Access to the blink rate of the OS. - Synchronizing the caret position in a content editable <canvas> subtree to the screen position rendered on the canvas and convey that information to a magnifier. - Convey the persons current selection position when higlighting text to a screen reader and synchronize that with what is in the contenteditable area in the subtree for a screen reader. - Convey the location of grammatical and spelling errors in a contenteditable canvas subtree to an author so that the author may synchronize them with what is rendered on the visual canvas. - Assess what HTML elements in the canvas subtree are allowed in the subtree. For example, should an IFrame be allowed?
Bug triage sub-team think this is a HTML A11Y TF priority, is part of the canvas sub-team work.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Please file only one issue per bug. Note that as a general rule, it is not good design to provide features to help authors abuse other features. Authors who use just <canvas> and JavaScript to create applications are abusing HTML, and should not be supported.
It is a general view by people who work in accessibility that authors do no adhere to the intent of a set of people. The do what, in their mind will benefit them or their company. Consequently, provisions must be made to support accessibility. Using accessibility as a vehicle to prevent authors from not adhering to the intent of the original standard authors only leads to users being excluded from using the technology. If you follow the technical plenary discussions you will find that this issue is already well under way to being addressed by the canvas accessibility team. If you follow parts of the technical plenary you will find that some participants, in the television industry felt they could live with limited HTML profile that included only canvas and javascript. They referred to this as "the sweet spot." This means that authors will want to have complete user drawn applications as the accessibility team has predicted. That would include rich text editing. I am confused by your last comment about using JavaScript to abuse HTML when your own company uses JavaScript and tables extensively in ways that were not intended for HTML 4.01. Examples are gmail and Google docs. The canvas accessibility sub team will propose a solution,The final proposal for rich text editing was not to be complete until Last Call. However, we seem to be coming to a solution more rapidly that will make use of some API changes but also ARIA with some minor enhancements. In the long run authors will be pleased that the designers of HTML had the foresight to build accessibility features into the language to support use cases like rich text editing.
Richard, it seems this bug is already covered by ISSUE-131: http://www.w3.org/html/wg/tracker/issues/131 More generally, if the editor has given a disposition and someone else wants to provide new information in the future, it's correct for the bug to stay resolved in the meantime. For these reasons, I'm making the following changes: 1) Moving bug back to RESOLVED/INVALID 2) Adding TrackerIssue keyword 3) Moving to pre-LC component, since this is covered by a pre-LC issue resulting from older bugs Alternately, it would be acceptable to file individual bugs for the issues listed here as suggested by Ian.
OK. Canvas accessibility group agrees.