Re: ARIA roles for graphics

I think an icon role should be used on the svg element and would indicate
that the entire SVG is an graphic that represents something. I would go
further and say an appearance of an icon is unimportant, only that it is
recognized as the thing it represents. International signs (road signs,
bathroom signs) and symbols for common tasks (undo, help, next) are
examples of appropriate use.

If you want to apply an icon role to parts of an SVG then I think symbol
would be a better term.  The term symbol is already used in maps and
legends and the analogy works. Symbols represent things and their
properties (size, location, orientation) may be important.



                                                              
                                                              
                    Regards,                     Fred         
                                                              
                   Fred Esch                                  
       Accessibility, Watson Innovations                      
    AARB Complex Visualization Working Group                  
                     Chair                                    
        W3C SVG Accessibility Task Force                      
                   IBM Watson                                 
                                                              
                                                              






From: "White, Jason J" <jjwhite@ets.org>
To: "chaals@yandex-team.ru" <chaals@yandex-team.ru>
Cc: "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>,
            "Amelia Bellamy-Royds" <amelia.bellamy.royds@gmail.com>,
            "public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
Date: 05/26/2015 11:53 AM
Subject: 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 20:04:09 UTC