WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: What ARIA role should a pointer have?

for

From: glen walker
Date: Jul 20, 2018 9:18AM

I'm not sure how well it's supported yet but it sounds like
aria-roledescription is exactly what you want. You have a widget that
doesn't really fall into any of the current roles

https://www.w3.org/TR/wai-aria/#aria-roledescription

You still have to give the element a valid role, but you can change how
that role is announced.

Is the object you're moving around on the diagram really being used as a
hotspot? A hotspot is typically an area on an object that you can click on
to get more info or select it. It sounds like your object is being used to
answer a question and that no one is going to click on that object later.

If the object will be a hotspot in the true sense of the word, that is
someone will be able to click on it later, then button would be an
appropriate role and perhaps an aria-roledescription of "hotspot". But if
the object is just an answer to a question, then you probably want a role
that doesn't imply that there's an interaction associated with the object
and still specify an aria-roledescription. That would rule out any of the
widget roles but only leaves document structure and landmark roles, neither
of which sound appropriate either.

role="separator", while listed under the widget roles because it could be a
divider between to resizable areas, is also the role used for the native
<hr> element, which is not interactive. Semantically, "separator" doesn't
make sense but it's pretty innocuous, and perhaps paired with
aria-roledescription="pointer" or "answer" might be as good as you can get.

I haven't tested any of this. Just tossing ideas out there that will
hopefully cause someone else to come up with a better idea.

Glen

On Fri, Jul 20, 2018 at 7:17 AM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> I guess you could go with "button", that is if you can move it around
> with the keyboard, maybe clicking it/activating it with the enter key
> indicates you've decided on the location on the image.
> So it could have role="button" and aria-label something like "select
> location".
> I remember working on widget for car insurance claims where user
> could click on an area of the car with the mouse to indicate where
> damage occurred.
> We implemented a series of checkboxes with descriptive names (back,
> front, passenger door etc.) that we served up alongside the image for
> screen reader/keyboard only user. Checking the checkbox highlighted
> the relevant area on the image so it was descriptive for the screen
> reader user and made the selection keyboard accessible.
> Of course this requires quite a lot of work so might not work well
> when you have a lot of images.
>
>
>
> On 7/20/18, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
> > Hi all,
> >
> > We are creating a widget that allows users to move a pointer in order
> > to select a "hot spot" on an image.
> >
> > As an example, if we were to display an image of a diseased heart,
> > accompanied by a question about the locus of the disease, mouse users
> > could drag the pointer to the desired spot on the image.
> >
> > Our pointer is keyboard accessible, but it's not feasible to make it
> > screenreader-accessible because we don't have any control over the
> > images that will be uploaded so we can't describe which part of the
> > image is under the pointer.
> >
> > Nevertheless, the pointer is focusable and draggable using a keyboard,
> > and I'm wondering whether we should give it an ARIA role so that it at
> > least makes sense to screenreader users when it receives focus.
> >
> > But I can't think of a role that would suit it.
> >
> > Any thoughts welcome.
> >
> > Cheers, Lynn
>