This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is related to Issue 74. Currently, the HTML accessibility task force is proposing an API that authors would use to report the selection position to a browser when editing text. This would be used by the user agent to support accessibility services to drive magnification during content selection. This approach requires an additional work by the author. It would be better if the author have a method to draw a highlighted selection of content on the canvas in such a way as to also support screen magnifiers. This method would need to report the current selection position to assistive technology using accessibility services layers for each platform. Windows allows for caret tracking so this position would drive a caret tracking. This would also be the case for UNIX systems. On the Mac selected text is processed differently and the current selection position (the position you are pointing at during a selection drag must be reported to assistive technologies). As a minimum the new method should take an element that pertains to the element having the caret in the fallback content or if Charles McCathieneville's proposal is accepted an element in an area map. It must be possible for the user agent to assess the coordinates used to draw the selection. This can be done by either using the drawing path or by passing a rectangle with coordinates. Carets often very in width and style. For example, they may be drawn using with a blinking rectangle that inverts the fill area of the rectangle. The severity is marked as normal. However if the proposed caretselectionrect function is not adopted as as part of Issue 74. This becomes a blocker.
This is related to Issue 74. Currently, the HTML accessibility task force is proposing an API that authors would use to report the selection position to a browser when editing text. This would be used by the user agent to support accessibility services to drive magnification during content selection. This approach requires an additional work by the author. It would be better if the author have a method to draw a highlighted selection of content on the canvas in such a way as to also support screen magnifiers. This method would need to report the current selection position to assistive technology using accessibility services layers for each platform. Windows allows for caret tracking so this position would drive a caret tracking. This would also be the case for UNIX systems. On the Mac selected text is processed differently and the current selection position (the position you are pointing at during a selection drag must be reported to assistive technologies). As a minimum the new method should take an element that pertains to the element having the caret in the fallback content or if Charles McCathieneville's proposal is accepted an element in an area map. It must be possible for the user agent to assess the coordinates used to draw the selection. This can be done by either using the drawing path or by passing a rectangle with coordinates. Carets often very in width and style. For example, they may be drawn using with a blinking rectangle that inverts the fill area of the rectangle. The severity is marked as normal. However if the proposed setCaretSelectionRect method is not adopted as as part of Issue 74. This becomes a blocker.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html The bug triage sub-team recommends the accessibility task force follow this.
This is NEEDSINFO for the same reasons as bug 10248. 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: Partially Accepted Change Description: see diff given below Rationale: Need a proposal for how to do this. I can't find any that would work.
Assign to rich to elaborate or close http://www.w3.org/2011/02/03-html-a11y-minutes.html#item01
Users will need the ability to select content in <canvas> for a broad number of reasons and low vision users require the ability to track the selection with their magnifiers. As the canvas subtree is designed to represent a one for one representation of what is drawn on the visual canvas, we do have the ability to use the <mark> element in the canvas subtree and apply the aria-selected property to it. This would require a small modification to the ARIA specification to make aria-selected a global attribute. This allows us to annotate the canvas subtree for screen reader vendors so that they can detect the selected content. We could also use the selection range APIs from the various browsers to do the same thing. What we still lack is the ability of the author to convey where a user is selecting content in canvas during a point and drag operation to be able to drive a magnifier. This requires two things: 1. Convey the caret or selection position during the selection process to a screen magnifier so that the magnifier can zoom at the point on the screen where the author is currently performing the selection. 2. Convey the location of selected content on the screen to a screen reader so that it can zoom to and along the selection area. To address 1. we have a modification to the Canvas2DAPI that will allow an author to update the caret or selection point for a screen magnifier during the selection process. We are discussing whether this should belong in the Canvas2dAPI spec. as this is also needed for SVG.
mass-move component to LC1
It's unclear to me what I'm supposed to be doing here. What is the proposal?
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: see comment 7
Moved to HTML.Next on request of Rich Schwerdtfeger.
Created attachment 1568 [details] HTML5 code for difference between images, shapes, pictures, canvas elements, maps, objects with no given or null field for image source in http HTML5 code for difference between images, shapes, pictures, canvas elements, maps, objects with no given or null field for image source in http. I could put an alt=" " but not necessary. What is the HTML rule on this object, picture of a shape for a logo at the head of the body or first header?
Created attachment 1569 [details] HTML5 code for difference between images, shapes, pictures, canvas elements, maps, objects with no given or null field for image source in http. I could put an alt=" " but not necessary. What is the H HTML5 code for difference between images, shapes, pictures, canvas elements, maps, objects with no given or null field for image source in http. I could put an alt=" " but not necessary. What is the HTML rule on this object, picture of a shape for a logo at the head of the body or first header?
Rich, is this still an issue?
This appears to relate to the Canvas spec. If it does relate to HTML, please file an issue here: https://github.com/w3c/html/issues