w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Consensus test on canvas change proposal
The results of this questionnaire are available to anybody.
This questionnaire was open from 2010-02-22 to 2010-02-25.
16 answers have been received.
Jump to results for question:
1. Canvas change proposal
See the canvas element change proposal.
The HTML Accessibility Task Force canvas sub-team proposes to add an attribute to canvas, called "adom," to provide the author with the ability to state <canvas> subtree is an accessible implementation synchronized to the visual canvas rendering. It should be noted that additional canvas API work, separate from the HTML 5 specification, is in process to give the author the tools to draw visusal focus and carets in such a way as to support magnification.
Do you support taking the proposal above to the HTML working group as a change request to support <canvas> accessibility - Issue 74?
Summary
| Choice | All responders |
|---|---|
| Results | |
| Submit this proposal to the HTML WG as a decision of the task force. | 9 |
| Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. | 5 |
| Do not submit this proposal to the HTML WG for the following reasons. | 2 |
Details
| Responder | Canvas change proposal | Comments |
|---|---|---|
| Frank Olivier | Submit this proposal to the HTML WG as a decision of the task force. | |
| Ian Hickson | Do not submit this proposal to the HTML WG for the following reasons. | I do not think there is value in providing a mode in which the contents of the <canvas> element are not made accessible to ATs. If the contents shouldn't be rendered by ATs, then the author should just remove the contents. |
| Maciej Stachowiak | Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. | Thanks for putting this together! I have two comments (personal opinions only): Comment 1: I think it should be always allowed to always expose the content of the <canvas> element to AT. I did not see a justification for ever not exposing <canvas> content in the proposal linked from the survey. Therefore I will propose adopting this proposal with one of the following changes: A) Allow <canvas> children to always be exposed to AT, even if adom is not set; OR B) Provide a rationale for not exposing this content to AT in some cases (this would likely include not exposing it for any currently existing <canvas> elements). Comment 2: In purely formal terms, this proposal is missing the required parts of a Change Proposal (Summary, Rationale, Impact; only Details seems to be provided). I presume these will be added before submitting to the HTML WG, but just for the record I request the addition of that material. |
| Jon Gunderson | Submit this proposal to the HTML WG as a decision of the task force. | |
| Joshue O'Connor | Submit this proposal to the HTML WG as a decision of the task force. | |
| David Bolter | Submit this proposal to the HTML WG as a decision of the task force. | I can't speak for Mozilla as a whole, but thinking of all our discussions and the feedback that has come from people inside and outside this TF, this approach seems like a reasonable compromise to me, and I'd like to hear more from the HTML WG ASAP. |
| Richard Schwerdtfeger | Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. | Based on feedback from David Singer and Maciej (from Apple) <change> The default value for adom is false to indicate that the canvas subtree is only used as fallback content and may not be used as an accessible DOM subtree representation of what is drawn on canvas. </change> <to> The default value for adom is false to indicate that the canvas subtree is only used as fallback content and MUST NOT be used as an accessible DOM subtree representation of what is drawn on canvas. </to> |
| Martin Kliehm | Submit this proposal to the HTML WG as a decision of the task force. | |
| Chaals Nevile | Do not submit this proposal to the HTML WG for the following reasons. | This proposal forces authors to choose whether to provide a fallback for situations where canvas is not rendered, an accessible interaction model for the canvas which it suggests should consist of elements inside the canvas subtree (an unnecessary requirement), or build at least one of these alternatives in script and apply it based on a test, in order to allow both possibilities. It doesn't seem justified given that image maps already allow the creation of an interaction model based on elements inside the canvas subtree, and aria provides the ability to structure those (as does the HTML 4 image map model which allows block content). |
| Gregory Rosmaita | Submit this proposal to the HTML WG as a decision of the task force. | although i voted to submit the proposal to the HTML WG as a decision of the task force, as a member of that task force, i'd feel more comfortable moving in this direction if we simultaneously explore more fully -- optimally, with the help of opera engineers -- chaals' imagemap proposal, to ascertain if it is an alternate technique, an inferior technique, or an alternate approach |
| Cynthia Shelly | Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. | In the first paragraph When adom is set to "true" the elements within the canvas MUST be rendered transparently to ensure inclusion in the HTML keyboard navigation order without effecting the visible rendering of the web page. <ins>User agents that support an accessibility API MUST map the HTML elements in the subtree to the accessibility API, as they would map the same elements outside the subtree</ins> rationale: It's assumed that these would be mapped like other HTML elements, but I think it's worthwhile to make that explicit, as it is vital for this idea to work. |
| Matthew May | Submit this proposal to the HTML WG as a decision of the task force. | |
| Steve Faulkner | Submit this proposal to the HTML WG as a decision of the task force. | see Gregorys comments, with whicch i agree |
| Sally Cain | Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. | I echo others comments that we will need clear techniques for canvas. Sometimes visual content can't be made accessible to all and alternatives are needed that make the same information available but in a slightly different way. Eg a table instead of a pie chart was one example someone gave. |
| aurélien levy | Submit this proposal to the HTML WG as a decision of the task force. | but see Gregorys comments, with which i agree |
| Laura Carlson | Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. | I would feel more comfortable moving in this direction if the task force fully explored Chaals' imagemap proposal. http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom It would be helpful if the Change Proposal template was completed for this Canvas proposal so that task force participants are provided the standard summary, rationale, and impact information required of a HTMLWG change proposal. This would facilitate better understanding of the proposal. A framework is at: http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Change_Proposal_Action_165 Thanks. |
More details on responses
- Joshue O'Connor: last responded on 23, February 2010 at 13:45 (UTC)
- David Bolter: last responded on 23, February 2010 at 18:42 (UTC)
- Richard Schwerdtfeger: last responded on 23, February 2010 at 22:03 (UTC)
- Martin Kliehm: last responded on 24, February 2010 at 15:24 (UTC)
- Chaals Nevile: last responded on 24, February 2010 at 16:02 (UTC)
- Gregory Rosmaita: last responded on 24, February 2010 at 17:45 (UTC)
- Cynthia Shelly: last responded on 24, February 2010 at 20:50 (UTC)
- Matthew May: last responded on 24, February 2010 at 22:57 (UTC)
- Steve Faulkner: last responded on 25, February 2010 at 10:07 (UTC)
- Sally Cain: last responded on 25, February 2010 at 14:15 (UTC)
- aurélien levy: last responded on 25, February 2010 at 17:43 (UTC)
- Laura Carlson: last responded on 25, February 2010 at 20:31 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project