W3C home > Mailing lists > Public > public-svg-a11y@w3.org > August 2015

Re: chart info from NCAM and other issues from SVG A11Y meeting August 14

From: White, Jason J <jjwhite@ets.org>
Date: Tue, 18 Aug 2015 20:33:37 +0000
To: Fred Esch <fesch@us.ibm.com>
CC: "public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
Message-ID: <70B1035F-0C15-42BD-B6F2-550041282956@ets.org>

> On Aug 18, 2015, at 16:15, Fred Esch <fesch@us.ibm.com> wrote:
> 1. Define each “dimension” of the data so that its type is clear to the UA/AT.
> fe: I think the proper place to define a dimension is on a visible scale - either an visible axis or a legend. If there is no axis/legend for a dimension, then we should not try to define that dimension for the audience as the visual user doesn't get that information and the author may not intend the scale to be metric.
It’s the author who decides whether to include markup to define the dimension, so I don’t think it matters much whether the relevant property is placed on the SVG content that renders as a visible scale or whether it’s otherwise associated with the data values. Authors (or developers of tools that generate SVG) won’t supply information that they don’t wish to supply, e.g., because it isn’t available or cannot be represented accurately.

I wouldn’t oppose a decision to follow your recommendation above, however.

> For example, an application may use a proprietary algorithm to rank order a list. Instead of presenting a list, they choose to present the results as a bar chart with the largest bar on the left and the bars in descending order as you go right. In this case, the author does not want you to compare categories using value ratios - so they do not have a Y axis on the chart. The visual user looks at the left most category on the X axis and knows this category has the highest value, they don't know what that value is. The user can't compare a ratio value for two categories as they are not given a Y axis as a scale - which is what the author intends.
In that case, the author wouldn’t define the scale in any ARIA markup either.
> 2. Use an ARIA property to declare its visual representation. Thus, for a numerical value, the visual presentation could be declared as, e.g., “bar height”, “bar width”, “point” (in a coordinate plane), “sector” (as in a pie chart), etc.
> I think this is valuable and interesting. However, it think it can be difficult for an author to articulate and thus won't be used much. How does an author articulate a color in a continuous color scale? ( ColorBrewer 2, has great categorical color scales. ) How does an author provide names for custom shapes?
I think it depends on the level of detail required to make the representation comprehensible to the user. The advantage of a property is that the vocabulary is standardized and can be localized by the rendering software when presented to the user. Author-supplied descriptions are variable in quality and not standardized, so there’s a decision to be made regarding (1) what level of etail is needed concerning the visual presentation, and (2) whether having standard terms defined in ARIA properties is desirable. My suggestion assumed that the trade-off was worth making, but not that the exact visual representation of each data item needs to be recoverable from a non-visual rendering. Rather, the idea was to represent the visual property that is being used to denote a data dimension without necessarily describing or classifying the appearance of the individual data items. How useful that would turn out to be is a question that merits further thought, of course.


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

Received on Tuesday, 18 August 2015 20:34:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:28:17 UTC