This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The <canvas> element's contents are meant to act as a DOM-based alternative representation of the visual and script-driven canvas image. However, it is practically impossible for authors to actually duplicate all of the necessary accessibility-related functionality of many <input> types, particularly "simple" ones like <input type=text>. For example, properly handling bidi reordering, or presenting IMEs for a reasonable number of languages, are both extremely difficult tasks that take quite a bit of engineering effort to get right and require a lot of expert and domain-specific knowledge. Because of this, authors should not use <canvas> to create text inputs and other controls that are complex in similar ways. We should reflect this restriction in the content model of <canvas>, so that authors do not believe that they can simply recreate a crappy half-implementation of text inputs in canvas, and then put an <input type=text> in the fallback content to make it all better. (Authors will produce crappy half-implementations of text inputs in canvas anyway, but we can at least make it *more wrong* to do so, to discourage the practice.)
Restricting the use of the canvas shadow tree would irretrievably harm developer abilities to produce assistive user interfaces for users with cognitive and/or motor disabilities. This is an unbearable and unnecessary restriction on accessibility developers and users with disabilities. As for other authors: [input type="text"] is the fall-back input type for form elements which are not implemented; the canvas type does not "replace" input elements, but it may be used to progressively enhance them by overriding the browser's render tree. Consider: [canvas][input type="slider" role="slider"]. This element becomes a text element in browsers which do not support the slider input type; it is still identified as a slider by ARIA semantics. ARIA provides a full language for describing custom widgets as developed by individual authors. Canvas, when used in conjunction with ARIA is fully accessible to non-sighted users, and can be used in creative ways to assist sighted users. This discussion has been ongoing since last September, relating to text input; the HTML Editor and the editor's assistant have had every opportunity to engage the a11y crowd on the public canvas api mailing list, as well as html a11y. We did go through a process of considering restrictions on elements within the canvas DOM. We agreed as a group that such restrictions were unnecessary. I'm asserting that such restrictions are unconscionable restrictions on personal freedom. I hope that providing examples of vision-based assistive interfaces, the HTML editor and the HTML editors assistant will better understand my position on this. Again, proper handling of ARIA and focus events within the shadow dom works quite well to support eyes-free interfaces.
Given... - The specialized user experience for <input type=text> on most (mobile) devices - the amount of implementation work required from user agents *and* authors to recreate the native accessibility functionality of <input type-text> ...the author should not recreate <input type=text> rendering in <canvas>. I think authoring guidance should be sufficient here.
(In reply to comment #2) > I think authoring guidance should be sufficient here. Are you suggesting an informative note instead of content model restrictions or what?
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: Rejected Change Description: no spec change Rationale: Revert requested by the Chairs. Tab, if you want this back to FIXED, you need to use the escalation path in the Decision Process.
mass-moved component to LC1
This has been forked in the whatwg specifications: "Transparent, but with no interactive content descendants except for a elements, button elements, input elements whose type attribute are in the Checkbox or Radio Button states, and input elements that are buttons."
Comment via Rich Schwerdtfeger: Although the name of the bug refers to not replacing some input controls with canvas the text of the bug refers to text fields. This is addressed in the Canvas 2D API specification in section 19 in that it encourages using canvas for Rich Text Editing. Addressing the accessibility of Rich Text Editing has been moved to HTML.next.