Re: ARIA roles for graphics


> On May 25, 2015, at 19:19, chaals@yandex-team.ru wrote:
>> LJW: Conceptually this makes sense, but I think it might be difficult to distinguish between an image and a graphic in a practical sense. Throwing some alternative name suggestions out there… “datachart”, “infographic”, “structuredimg”, or “compleximg”?
>>
Perhaps structuredimg would be appropriate, although any similar name would convey the concept.
> compoundImage? Trying to think through examples:
>
That’s a good proposal.
> Is the *point* of this role that it should be in a table of contents?
>>
I don’t think so. My understanding, which may be wrong, is that the effect of this role would be to include the element in the accessibility tree, contrary to the default of assigning role=none to graphical elements.

For screen readers, it should be possible to move point of regard to such an element.

>> • icon
>> • A graphical element which conveys a simple concept or category using a symbolic image.
>> • Differs from an image in that a short name is all that is expected; a detailed description of the visual representation is not required to convey the meaning of the icon.
>> • Children are presentational -- an icon is an atomic element.  It should never have component parts with interactivity of their own descriptions -- use "graphic" instead.
>> • The fallback role would be img.
>> • This could be the default role for <use>, so that authors would have to explicitly over-ride the role if they wanted the browser to include the cloned content in the accessibility tree.
>>
> I'm not sure about the last point - I'd like to see it explained in terms of use cases and requirements, but otherwise this makes a lot of sense.

I think the argument would be that the essential information about an icon is what it represents rather than the details of its visual appearance. The latter may however be useful to know in some contexts, thus I would suggest including a brief description in DESC and a label designating the purpose of the icon in TITLE. Unfortunately, this would preclude providing help text usable as a tool tip in DESC. However, if the icon is associated with interactive behavior, then a widget role such as button should be used instead, presumably.

To make interactive icons more non-visually accessible, a case can be made for a three-way distinction:

1. Short label indicating the purpose or referent of the icon.

2. Help text (optional).

3. Brief description of visual appearance (optional).

Both 2 and 3 are desirable but not essential.
>
>> • shape
>> • A basic geometric shape.
>> • The main purpose of this role, as distinct from img or icon, is so that accessibility tools can communicate what type of shape it is.  A new ARIA property would allow the author to convey the shape type separately from the label and description.  For example, in a flow chart, the shape of nodes often conveys meaning, but you don't want to repeat that in the label, which should focus on the substantive information.
>> • Children are presentational.
>> • The fallback role would be img.
>> • This would be the default for all the basic SVG shapes if they met the criteria for inclusion in the accessibility tree.
>> • All the standard SVG shapes except path would have default shape-type descriptions that the browser should localize by default.
>> • You could also use the shape role on a group if that group represented a single graphical element (e.g., if it contained a basic shape plus its visible label, or a shape that has been duplicated and layered for graphical effect).
>>
> I'm not convinced that children should be presentational.
>
> Consider the shape "a triangle extended over an almost-square rectangle, with a small sqaure-topped vertical riser on one side". This is a common enough shape represented by a group. It may have two or four children whose shape is basically "a square, or almost-square", and one vertically-sligned rectangle. (typically the rectangle will be in the middle, anchored at the bottom of the parent shape,  while the two squares will be on either side of it, floating toward the top of the rectangle section of the parent shape. There may also be a "collection of circles" or some "wavy lines" extending up from the vertical protrusion on the triangle that is the top of the parent shape.
>
> For those who gave up drawing mental pictures, I'm describing the way kids draw a house, as the first of a few examples that popped into my head.
>
This is a good example. Note also that there are textbook geometry problems that depend on embedded shapes of just this kind.

If the children of “shape” were presentational, the author would have to apply the “shape” role explicitly to all of the component shapes, a result which I would prefer to avoid. If there are many use cases in which the components of shapes are purely presentational, then obviously I would adjust my view, as we are here defining the default, which ought to be correct in a majority of actual cases.

While we’re discussing examples, consider how we might represent a paradigmatic drawing of a right triangle. There is typically a small square symbol inside the triangle which, by convention, indicates a right-angle. Given the above mini-taxonomy, I would apply the “shape” role to the triangle and an “icon” role to the symbol with title “right angle” and possibly a description.

Perhaps the central distinction we need here, at a high level, is that between a “structured graphic”, one which has semantically significant components, and “atomic graphic” which does not. The question about shape, then, is whether it should inherit from the “atomic” or “structured” role.

I would envisage “atomic graphic” and “structured graphic” as concrete rather than abstract roles in the taxonomy, and I would allow other concrete roles to inherit from them.


________________________________

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, 26 May 2015 15:53:18 UTC