Re: ARIA roles for graphics

Thanks to Fred for copying over the key points of this discussion to the
wiki:

   - https://www.w3.org/wiki/ARIA_roles_for_graphics

I've added a few comments/clarifications to try to clarify why I had
proposed the distinctions I did.  I'll follow-up later with some more
complete examples and use cases.

Amelia



On 27 May 2015 at 06:15, Léonie Watson <lwatson@paciellogroup.com> wrote:

> From: White, Jason J [mailto:jjwhite@ets.org]
> Sent: 26 May 2015 16:53
>
> > On May 25, 2015, at 19:19, chaals@yandex-team.ru wrote:
> >> • 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.
>
> The most basic use case, is needing to know what an object is. The icon
> role would seem to satisfy this case.
>
> The rest is authoring practice. Knowing what an icon represents is
> definitely essential, and this could be accomplished with something like:
>
> <svg role="icon" aria-label="Delete">...</svg>
>
> I'm less sure that the use case for a description is strong enough. It
> would be good to gather some quantative data to work with if we can.
>
> I also have reservations about recommending <title> as an authoring
> mechanism to provide help.
>
> A scratch browser test this morning suggests that only Firefox renders
> <title> as a tooltip. Chrome, IE and Safari don't, and as a Webkit based
> browser I suspect Opera is unlikely to either.
>
> When it is rendered, <title> has the same UI as @title in HTML, so it
> comes with all the same accessibility/usability issues [1].
>
> Returning to the original thread, I agree with Chaals that some
> explanation of Ameila's last point would be helpful:
>
> >> • 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.
>
> Not sure if this is suggesting that img would be the default role? If so,
> why wouldn't an object with a role of img be in the acc tree already? Also
> not sure what content is/would be cloned?
>
>
>
> Léonie.
> [1]
> http://www.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/
>
>
>
>
>
>