E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Isabel Holdsworth
Date: Fri, Jul 20 2018 6:44AM
Subject: What ARIA role should a pointer have?
No previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS 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?
>>>> >
>>>> > -----Original Message-----
>>>> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>>>> > Of
>>>> > Isabel Holdsworth
>>>> > Sent: Friday, 13 July 2018 10:03 PM
>>>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>>>> > Subject: Re: [WebAIM] Multiple documents in a single webpage
>>>> >
>>>> > Thanks Glen - lots of good food for thought here.
>>>> >
>>>> > The dialog is draggable using the keyboard. When the whole dialog has
>>>> > focus,
>>>> > as I think it does once the button to open it has been pressed, drag
>>>> > handles
>>>> > appear and the dialog can be moved using the mouse or arrow keys.
>>>> >
>>>> > There's not a quick skip link to move to the dialog at the moment. We
>>>> move
>>>> > focus straight there as soon as it opens, and pressing Close or
>>>> > Escape
>>>> > hides
>>>> > it again and moves focus back to the opener.
>>>> >
>>>> > The dialog is at the end of the DOM, and I'm suggesting its title is
>>>> > an
>>>> H1
>>>> > heading. I could suggest a skip link back to the main document, but
>>>> > where
>>>> > in
>>>> > the document should it move the focus to? The opener perhaps, Or the
>>>> first
>>>> > H1?
>>>> >
>>>> > Thanks again, and have a great weekend.
>>>> >
>>>> > Lynn
>>>> >
>>>> > On 12/07/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>>> >> You said the dialog visually looks like a draggable non-modal
>>>> >> dialog.
>>>> >> Is it really draggable or can it be moved via the keyboard? Or is
>>>> >> it
>>>> >> really a fixed location on the screen and you're just styling it to
>>>> >> look like a moveable dialog?
>>>> >>
>>>> >> Is there a quick keyboard way to move the focus from the "regular"
>>>> >> part of the page to the dialog area? A landmark would help an AT
>>>> >> user
>>>> >> but browsers have not surfaced landmark navigation to keyboard users
>>>> >> yet so you'd need a skiplink or shortcut key (that's discoverable).
>>>> >>
>>>> >> Any time the page is updated with new info, you should notify the
>>>> >> user.
>>>> >> That's often done with aria-live regions.
>>>> >>
>>>> >> You'd also have to decide whether to move the focus. In general,
>>>> >> moving the focus after selecting a button is shied away from, but in
>>>> >> your case, if I were using a screen magnifier and could only see the
>>>> >> button and a limited region around it, I might not notice that
>>>> >> somewhere else on the screen was updated unless the focus was moved
>>>> >> to
>>>> >> it (causing my magnified viewport to move to the newly focused
>>>> >> area).
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Thu, Jul 12, 2018 at 6:49 AM, Isabel Holdsworth <
>>>> >> = EMAIL ADDRESS REMOVED = > wrote:
>>>> >>
>>>> >>> Hi all,
>>>> >>>
>>>> >>> We have a webpage with a button that, when pressed, loads a
>>>> >>> document,
>>>> >>> spreadsheet or image into a dialog that's positioned at the bottom
>>>> >>> of
>>>> >>> the DOM. So we effectively have two items of content residing on
>>>> >>> the
>>>> >>> same webpage.
>>>> >>>
>>>> >>> Currently there's nothing to distinguish the new content from the
>>>> >>> existing apart from an H1 heading and a div that looks visually
>>>> >>> like
>>>> >>> a draggable non-modal dialog box.
>>>> >>>
>>>> >>> I'd really appreciate your thoughts on the best way to structurally
>>>> >>> present the new content so it's distinguishable as a separate
>>>> >>> entity
>>>> >>> from what was already on the page.
>>>> >>>
>>>> >>> Thanks as always, Lynn
>>>> >>> >>>> >>> >>>> >>> archives at http://webaim.org/discussion/archives
>>>> >>> >>>> >>>
>>>> >> >>>> >> >>>> >> archives at http://webaim.org/discussion/archives
>>>> >> >>>> >>
>>>> > >>>> > >>>> archives at
>>>> > http://webaim.org/discussion/archives
>>>> > >>>> >
>>>> > >>>> > >>>> > >>>> > >>>> >
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
>

From: Birkir R. Gunnarsson
Date: Fri, Jul 20 2018 7:17AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS 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?
>>>>> >
>>>>> > -----Original Message-----
>>>>> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>>>>> > Of
>>>>> > Isabel Holdsworth
>>>>> > Sent: Friday, 13 July 2018 10:03 PM
>>>>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>>>>> > Subject: Re: [WebAIM] Multiple documents in a single webpage
>>>>> >
>>>>> > Thanks Glen - lots of good food for thought here.
>>>>> >
>>>>> > The dialog is draggable using the keyboard. When the whole dialog
>>>>> > has
>>>>> > focus,
>>>>> > as I think it does once the button to open it has been pressed, drag
>>>>> > handles
>>>>> > appear and the dialog can be moved using the mouse or arrow keys.
>>>>> >
>>>>> > There's not a quick skip link to move to the dialog at the moment.
>>>>> > We
>>>>> move
>>>>> > focus straight there as soon as it opens, and pressing Close or
>>>>> > Escape
>>>>> > hides
>>>>> > it again and moves focus back to the opener.
>>>>> >
>>>>> > The dialog is at the end of the DOM, and I'm suggesting its title is
>>>>> > an
>>>>> H1
>>>>> > heading. I could suggest a skip link back to the main document, but
>>>>> > where
>>>>> > in
>>>>> > the document should it move the focus to? The opener perhaps, Or the
>>>>> first
>>>>> > H1?
>>>>> >
>>>>> > Thanks again, and have a great weekend.
>>>>> >
>>>>> > Lynn
>>>>> >
>>>>> > On 12/07/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> >> You said the dialog visually looks like a draggable non-modal
>>>>> >> dialog.
>>>>> >> Is it really draggable or can it be moved via the keyboard? Or is
>>>>> >> it
>>>>> >> really a fixed location on the screen and you're just styling it to
>>>>> >> look like a moveable dialog?
>>>>> >>
>>>>> >> Is there a quick keyboard way to move the focus from the "regular"
>>>>> >> part of the page to the dialog area? A landmark would help an AT
>>>>> >> user
>>>>> >> but browsers have not surfaced landmark navigation to keyboard
>>>>> >> users
>>>>> >> yet so you'd need a skiplink or shortcut key (that's discoverable).
>>>>> >>
>>>>> >> Any time the page is updated with new info, you should notify the
>>>>> >> user.
>>>>> >> That's often done with aria-live regions.
>>>>> >>
>>>>> >> You'd also have to decide whether to move the focus. In general,
>>>>> >> moving the focus after selecting a button is shied away from, but
>>>>> >> in
>>>>> >> your case, if I were using a screen magnifier and could only see
>>>>> >> the
>>>>> >> button and a limited region around it, I might not notice that
>>>>> >> somewhere else on the screen was updated unless the focus was moved
>>>>> >> to
>>>>> >> it (causing my magnified viewport to move to the newly focused
>>>>> >> area).
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Jul 12, 2018 at 6:49 AM, Isabel Holdsworth <
>>>>> >> = EMAIL ADDRESS REMOVED = > wrote:
>>>>> >>
>>>>> >>> Hi all,
>>>>> >>>
>>>>> >>> We have a webpage with a button that, when pressed, loads a
>>>>> >>> document,
>>>>> >>> spreadsheet or image into a dialog that's positioned at the bottom
>>>>> >>> of
>>>>> >>> the DOM. So we effectively have two items of content residing on
>>>>> >>> the
>>>>> >>> same webpage.
>>>>> >>>
>>>>> >>> Currently there's nothing to distinguish the new content from the
>>>>> >>> existing apart from an H1 heading and a div that looks visually
>>>>> >>> like
>>>>> >>> a draggable non-modal dialog box.
>>>>> >>>
>>>>> >>> I'd really appreciate your thoughts on the best way to
>>>>> >>> structurally
>>>>> >>> present the new content so it's distinguishable as a separate
>>>>> >>> entity
>>>>> >>> from what was already on the page.
>>>>> >>>
>>>>> >>> Thanks as always, Lynn
>>>>> >>> >>>>> >>> >>>>> >>> archives at http://webaim.org/discussion/archives
>>>>> >>> >>>>> >>>
>>>>> >> >>>>> >> >>>>> >> archives at http://webaim.org/discussion/archives
>>>>> >> >>>>> >>
>>>>> > >>>>> > >>>>> archives at
>>>>> > http://webaim.org/discussion/archives
>>>>> > >>>>> >
>>>>> > >>>>> > >>>>> > >>>>> > >>>>> >
>>>>> >>>>> >>>>> >>>>> >>>>>
>>>> >>>> >>>> >>>> >>>>
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> >>> >>>
>>
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Fri, Jul 20 2018 9:18AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
>

From: Isabel Holdsworth
Date: Mon, Jul 23 2018 4:21AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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
>>
> > > > >

From: Patrick H. Lauke
Date: Mon, Jul 23 2018 5:37AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
>>>
>> >> >> >> >>
> > > >

From: glen walker
Date: Mon, Jul 23 2018 7:14AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | Next message →

Yes, I was hesitant to point it out but the problem was that there was not
an existing role that fit and aria-roledescription seems to be the way to
solve that. Would love to hear if you have a better idea.

Another option that sorta kinda works if you use your imagination, is to
use a role="definition" and role="term", but again I'm not sure how well
supported they are. role="definition" has been around since ARIA 1.0 but
role="term" is new in 1.1. Native <dl>, <dd>, and <dt> has various support
(I know NVDA and JAWS treat them differently) so these roles might be
treated similarly.

Since you are asking a question and the answer relies on moving the object
to the right spot, the answer could be considered the "definition". I
suppose you could use role="term" on the question but am not sure that's
necessary, although the doc of "definition" says you should pair it with
"term". With role="definition" on the moveable object in combination with
aria-roledescription, it might be enough to get your point across. Not
perfect, but better than nothing.


On Mon, Jul 23, 2018 at 5:37 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> 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.
>
>

From: Isabel Holdsworth
Date: Mon, Jul 23 2018 7:42AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | Next message →

If I came across a focusable element with a role of "definition", I'm
not sure I'd have the first clue what to do with it. Role="pointer" or
something similar would be great here, but I don't suppose such a role
would have many use cases.

I guess this is more of a box-ticking exercise than anything else. We
don't like to create widgets with poor semantics, and we feel this one
kind of falls into that ballpark, but it wouldn't be terribly useful
to screenreader users even if there was a perfect solution.

Cheers for your thoughts though - if nothing else they've validated
our position that there's no suitable role for our pointer scenario.

Thanks, Lynn

On 23/07/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, I was hesitant to point it out but the problem was that there was not
> an existing role that fit and aria-roledescription seems to be the way to
> solve that. Would love to hear if you have a better idea.
>
> Another option that sorta kinda works if you use your imagination, is to
> use a role="definition" and role="term", but again I'm not sure how well
> supported they are. role="definition" has been around since ARIA 1.0 but
> role="term" is new in 1.1. Native <dl>, <dd>, and <dt> has various support
> (I know NVDA and JAWS treat them differently) so these roles might be
> treated similarly.
>
> Since you are asking a question and the answer relies on moving the object
> to the right spot, the answer could be considered the "definition". I
> suppose you could use role="term" on the question but am not sure that's
> necessary, although the doc of "definition" says you should pair it with
> "term". With role="definition" on the moveable object in combination with
> aria-roledescription, it might be enough to get your point across. Not
> perfect, but better than nothing.
>
>
> On Mon, Jul 23, 2018 at 5:37 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> 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.
>>
>>
> > > > >

From: Jim Homme
Date: Wed, Jul 25 2018 8:16AM
Subject: Re: What ARIA role should a pointer have?
← Previous message | No next message

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 ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Monday, July 23, 2018 7:37 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
>