WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: What ARIA role should a pointer have?

for

From: Patrick H. Lauke
Date: Jul 23, 2018 5:37AM

Related to aria-roledescription, I'd be careful in embracing that. AT users know what certain specific roles are, and how they can be interacted with. While it's cute that we can give very custom and specific announced roles, they will invariable lead to confusion as AT users will potentially have no clue what, say, a "hotspot" is compared to a "button" or some other standard role.

P

> On 23 Jul 2018, at 11:21, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
>
> Thanks Birkir and Glen for your thought-provoking ideas.
>
> As you say, Glen, the area isn't really a hot spot but rather an
> answer to a question. I don't really want to give the pointer a button
> role, because screenreader users won't know it should be dragged
> rather than pressed. There isn't a role in the current spec that
> describes a pointer, and I'm not sure roledescription would suffice
> because it's not well enough supported yet, and because we deliver our
> software in multiple languages and the roledescription would need to
> be translated on the fly.
>
> a 2d range/slider type widget might be the thing if these existed.
>
> Birkir, although I like your clever car labelling idea, we aren't in
> control of the images that are being upload, and authors won't have
> the training or accessibility expertise to label them properly, so it
> wouldn't work in this situation, although I'm keeping it for future
> reference.
>
> Thanks again, Lynn
>
>> On 20/07/2018, glen walker < <EMAIL REMOVED> > wrote:
>> 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
>>>
>> >> >> >> >>
> > > >