WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: What ARIA role should a pointer have?

for

From: Birkir R. Gunnarsson
Date: Jul 20, 2018 7:17AM

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
>
> On 20/07/2018, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
>> Apologies - it's been a while :-)
>>
>> The position of the document isn't reported back to AT as it is
>> dragged. Nor do users know what's being covered up. Realistically, the
>> drag functionality is more for keyboard users who can see the screen.
>>
>> The dialog sits on top of the originating document, and users will
>> most probably read the content in there and then close it before
>> continuing, but they do have the option to leave it open and drag it
>> somewhere unobtrusive such as to one side away from the main content.
>>
>> Thanks as always, and have a great weekend.
>>
>> On 14/07/2018, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
>>> I think it's fine to move focus to a document when it is displayed as
>>> the result of activating a link or a button.
>>> It would be bad if it is displayed as a result of changing the setting
>>> of a component (selecting a radio button, checking a checkbox,
>>> selecting from a dropdown etc.). You can see a lot of discussion about
>>> this in the understanding WCAG SC 3.2.2 documentation.
>>> You can enhance this by referencing visually hidden text on the button
>>> that says "moves focus to the document display area".
>>>
>>> I'd suggest to use something like role="region" and
>>> aria-label="document" for the container element.
>>> This is what aria-roledescription could be useful for, but so far it
>>> has limited support and even does more harm than good (e.g. in IE it
>>> overrides the semantics inside the document, with Jaws at least).
>>>
>>> If you have
>>> <div role="region" aria-roledescription="document panel"
>>> aria-label="document name">
>>> <h1>main heading</h1>
>>> <p>text.</p>
>>> <h2>Heading 2</h2>
>>> ...
>>> </div>
>>>
>>> an navigate to the headings inside the document, the headgs and levels
>>> are no longer announced by Jaws, only the role description "document
>>> panel" and the name.
>>>
>>> Does the document region contain a button to close or move focus back
>>> to the webpage?
>>>
>>>
>>>
>>>
>>>
>>> On 7/13/18, glen walker < <EMAIL REMOVED> > wrote:
>>>> I think what Sean was asking about was moving the dialog itself. Since
>>>> the
>>>> dialog can be moved by dragging it or using the move handles (nice job
>>>> allowing that from the keyboard), how does the AT user know where the
>>>> dialog is now?
>>>>
>>>> With powerpoint, which I think I mentioned in some other thread, the
>>>> location of the object is announced as you move it around. You're also
>>>> notified if the object moves over the top or underneath another object.
>>>> Is
>>>> anything like that announced when you move your dialog? Is the dialog
>>>> truly "on top" of the page in the background, or does stuff reflow
>>>> around
>>>> it as you move it around? If it's on top, when it first appears, does
>>>> anything in the background get covered up? I'm guessing as you move
>>>> it,
>>>> other stuff on the main page might get covered up?
>>>>
>>>>
>>>> On Fri, Jul 13, 2018 at 7:17 AM, Isabel Holdsworth <
>>>> <EMAIL REMOVED> > wrote:
>>>>
>>>>> If we didn't move the focus, screenreader users would be unlikely to
>>>>> know that some new content had appeared. And it may be difficult for
>>>>> them to find. If they pressed the button to open the dialog, chances
>>>>> are they're interested in what's in there, so why not position the
>>>>> cursor so they can begin reading at the correct place?.
>>>>>
>>>>> The focus should rarely be moved programatically, but I think this is
>>>>> one of those times when it's acceptable and even advisable.
>>>>>
>>>>> On 13/07/2018, <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:
>>>>> > I have one question. How does the screen reader user know where they
>>>>> > are
>>>>> > when you move the document within the page? What is the purpose of
>>>>> > moving
>>>>> > the document?
>>>>> >
>>>>> >