- From: Fred Esch <fesch@us.ibm.com>
- Date: Thu, 19 May 2016 09:40:55 -0400
- To: <public-svg-a11y@w3.org>
- Message-Id: <201605191349.u4JDn2ce023899@d01av03.pok.ibm.com>
All, The SVG AAM suggests that something must be rendered to the screen in order for it to be passed to the accessibility tree. In section 5.1.2 Including Elements in the Accessibility Tree it states. (Yellow highlighting and bold italics on word rendered is my emphasis). SVG user agents MUST provide an accessible object in the accessibility tree for rendered SVG elements that meet any of the following criteria, unless they are excluded from the accessibility tree per the rules in Excluding Elements from the Accessibility Tree And in section 5.1.1 Excluding Elements from the Accessibility Tree it states: For the purpose of SVG, an element is considered hidden if it is neither visible nor interactive, and is therefore not perceivable to visual users. User agents SHOULD NOT expose to accessibility APIs any element that is hidden in this sense. This includes graphics elements that have the following computed style values, unless the element can receive user input (pointer events or keyboard focus) as described under Including Elements in the Accessibility Tree: a value of hidden for the visibility property a value of none for both the fill and stroke properties of text or shape elements Note the last bullet states if shape's fill is none and the shape's stroke is none - the shape (and it's associated data) should not be passed to the accessibility tree. I do not believe being rendered should be a factor on whether something is passed to the accessibility tree or not. If a user adds an aria-label to a shape that has a stroke of none and fill of none, the data/aria-label may still be important information for the user. Missing data and no response data might not rendered on a chart. When missing/no response data is not rendered, it does not mean a visual graphic/chart/map user won't be aware of the missing/no response data and isn't prevented from being aware of the significance of the missing/no response data. Here is an example, you have a monitoring system that plots a dot for the value of a sensor at every time interval t. Just before time 23t connection with the sensor is broken and the value recorded in the log is - 23t missing. Since the data is missing, a dot is added to the SVG graphic with a stroke and fill of none and an aria-label 23 t (missing). A visual user of the monitor can see that at 23t through 28t there is a gap in reporting from the sensor and can verify this by looking at the log. Someone using the accessibility tree would not know what happened between 23t through 28t if the data associated with the dot (with fill none and stroke none) were not passed to the accessibility tree. Another example, an aeronautical chart with a blank space in it, lets the pilot know that the area has not been mapped and therefore the pilot will not know how many vertical obstructions exist in the area and won't know the heights of vertical obstructions in the area. Missing data can be very important to a user. The purpose of most informational graphics is to convey information and for graphs and maps the purpose is to convey data to a user through visual means. Often important information is not rendered but can be put in the SVG. All important information needs to be passed to accessibility tree whether rendered or not. I suggest we remove dependence on whether something is rendered for deciding on whether something goes into the accessibility tree. We can simply have inclusion based on aria properties overrule exclusion based on not being rendered. I do think we need a method for authors to include/exclude objects and since roles (none, presentation) aren't strong enough we could rely on display none. We do need a simple way for authors and script writers to show/hide data that affects both visual and the accessibility tree, however I do not think that stroke and fill are appropriate for doing this. Regards, Fred Esch Watson, IBM, W3C Accessibility IBM Watson Watson Release Management and Quality
Attachments
- image/gif attachment: 0F662591.gif
Received on Thursday, 19 May 2016 13:49:38 UTC