WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: What ARIA role should a pointer have?

for

From: Jim Homme
Date: Jul 25, 2018 8:16AM

Hi,
I agree with Patrick. As a screen reader user, I think the verbal and cognitive overload of figureing out what the extra landmark labels do degrades usability within accessibility.

Jim



=========Jim Homme
Product Manager
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
People with disabilities, access job openings at https://www.benderconsult.com/careers/job-openings


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Patrick H. Lauke
Sent: Monday, July 23, 2018 7:37 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] What ARIA role should a pointer have?

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
>>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
>