E-mail List Archives

Search E-mail List Archives for

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

From: Renato Iwashima
Date: Thu, Oct 03 2019 4:22PM
Subject: Accessible tooltips for on boarding
No previous message | Next message →

Hi,

It is quite common to find some applications that do a little introduction
of their software on first load by having a step-by-step on boarding
tutorial with tooltips that point to specific areas or controls on the
screen explaining what that area or object does. They usually behave like a
modal, meaning it blocks the whole screen only allowing you to interact
with the tooltip or with the control it is pointing to.

Since this interaction is very visually oriented (because it points to
things on the screen), I'd like to know what can be done to make this
experience accessible. What are the best practices for this? Has anyone
seen a good accessible on boarding experience?

Thanks!

From: Brian Lovely
Date: Fri, Oct 04 2019 8:08AM
Subject: Re: [External Sender] Accessible tooltips for on boarding
← Previous message | Next message →

I would word the text in the modal to ensure non-visual users can
understand what's going on. Assuming all page content is semantically
correct and has perceivable names (and descriptions, if applicable) then I
would refer to things by their role and perceivable name. For instance "the
profile button allows you to view and update your profile information"
instead of "this" (graphic of an arrow pointing to profile button) "allows
you to..."

On Thu, Oct 3, 2019 at 6:23 PM Renato Iwashima < = EMAIL ADDRESS REMOVED = > wrote:

> Hi,
>
> It is quite common to find some applications that do a little introduction
> of their software on first load by having a step-by-step on boarding
> tutorial with tooltips that point to specific areas or controls on the
> screen explaining what that area or object does. They usually behave like a
> modal, meaning it blocks the whole screen only allowing you to interact
> with the tooltip or with the control it is pointing to.
>
> Since this interaction is very visually oriented (because it points to
> things on the screen), I'd like to know what can be done to make this
> experience accessible. What are the best practices for this? Has anyone
> seen a good accessible on boarding experience?
>
> Thanks!
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__list.webaim.org_&d=DwICAg&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=MMimM36KI-FWX0bnlG1RIV6Bl3MtdwmuKJCwL2Q3WrQ&m=JLR9yovR7J9IblXyPyvrSDvNEWYXIKADLJ6WlLOwCTw&s=HV1IvhZ6tP5tGl4JZGIVY76L08x9ZN2HLjnK3dPxFQk&e=
> List archives at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__webaim.org_discussion_archives&d=DwICAg&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=MMimM36KI-FWX0bnlG1RIV6Bl3MtdwmuKJCwL2Q3WrQ&m=JLR9yovR7J9IblXyPyvrSDvNEWYXIKADLJ6WlLOwCTw&s=F7m0YfnsVhKVqLZto6D_RlABzlcY0WiS5K6qqcvpnuo&e=
> >


--
*Brian Lovely*
Capital One Digital Accessibility
804.389.1064




The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: Mallory
Date: Sat, Oct 05 2019 2:16AM
Subject: Re: [External Sender] Accessible tooltips for on boarding
← Previous message | Next message →

Ah, coachmarks. They are difficult to do well for low-vision and blindness. It should be okay for people to skip these and still be able to generally find stuff as they use the page.

I second Brian's recommendation, however with an extra: if possible, see if the thing being pointed to can be recreated in the coachmark/tooltip itself. This because I'm assuming the rest of the page is getting a dark or faded overlay? and with low-vision and zooming, we don't necessarily have a great idea of where on the page layout we are being pointed to... so we may try to get a good look at where the coachmark is referring to-- if there's an icon, a name, or both, we want to see it and try to remember it. (If that's already visible then don't add it again to inside the coachmark.)
If the thing being pointed to is inside some kind of named panel or toolbar or whatnot, mention it (I hope/assume all the parts of the page have consistent naming, both in any documentation you have for users as well as how the pages refer to themselves internally... like, if you call something a "Help Drawer" then hopefully everything everywhere calls it a "Help Drawer").

If there are focusables inside the coachmarks (usually there are, Back, Next, OK buttons?), if focus moves either to them or to the coachmark itself (similar to setting focus to a whole modal with tabindex="-1") then in supporting browsers, the screen magnification will move the user's viewport to that coachmark. I suppose if you do that though then you'd need to do other modal-style techniques (accessible name and some role on them) if they are large and you don't want screen readers auto-reading a huge pile of text just because the whole element got focus. On the other hand, if they are short this might be exactly what you want.

If this is a dashboard-type thing that isn't viewport-responsive (it maintains its width for intrinsic reasons, like Photoshop does, and so users must scroll in two directions most of the time), then think hard about how you want to refer where page chunks and panels are: while linear users like screen reader users benefit from "before" and "after" as placement references, for low-vision users adding in "left side" and "right side" may be helpful. If the page is responsive though then you can never know if users are getting any "sides" or if it's all been collapsed into a single column, so sticking to only "before" and "after" makes more sense (WCAG mentions being careful with visual placement names, so again I'm only suggesting they might be helpful if added *in addition to* linear references). I know that when I'm using ZoomText I do try to keep a mental model of what's on the left or right, like when I'm using the Gimp to edit images.

Try using your coachmarks with both deep browser zoom (~400%) or if you can with screen magnification, or play with a piece of paper with a small card-sized hole cut out and go through the coachmarks. What visual landmarks can you find? Do you get an idea of where things are on the page visually, from the text, or iconography? Your content writers might come up with good text while keeping it from getting verbose.

When you think you've got something decent, try to find a variety of users to test: those with zero familiarity with these kinds of things and those who've encountered similar ones, and see how oriented they say they feel afterwards.

Finally: sometimes they're just an irritating waste of time. When the first one pops up, offer an option to skip the whole damn thing. Those of us who wipe all our cookies every time we close the browser tend to get coachmarks (and GDPR and cookie warnings) over and over again.

All of the above is just my opinion, though I did spend too many months thinking about these at a previous job where they were painful to implement.

cheers,
_mallory

On Fri, Oct 4, 2019, at 4:08 PM, Brian Lovely via WebAIM-Forum wrote:
> I would word the text in the modal to ensure non-visual users can
> understand what's going on. Assuming all page content is semantically
> correct and has perceivable names (and descriptions, if applicable) then I
> would refer to things by their role and perceivable name. For instance "the
> profile button allows you to view and update your profile information"
> instead of "this" (graphic of an arrow pointing to profile button) "allows
> you to..."
>
> On Thu, Oct 3, 2019 at 6:23 PM Renato Iwashima < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi,
> >
> > It is quite common to find some applications that do a little introduction
> > of their software on first load by having a step-by-step on boarding
> > tutorial with tooltips that point to specific areas or controls on the
> > screen explaining what that area or object does. They usually behave like a
> > modal, meaning it blocks the whole screen only allowing you to interact
> > with the tooltip or with the control it is pointing to.
> >
> > Since this interaction is very visually oriented (because it points to
> > things on the screen), I'd like to know what can be done to make this
> > experience accessible. What are the best practices for this? Has anyone
> > seen a good accessible on boarding experience?
> >
> > Thanks!
> > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__list.webaim.org_&d=DwICAg&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=MMimM36KI-FWX0bnlG1RIV6Bl3MtdwmuKJCwL2Q3WrQ&m=JLR9yovR7J9IblXyPyvrSDvNEWYXIKADLJ6WlLOwCTw&s=HV1IvhZ6tP5tGl4JZGIVY76L08x9ZN2HLjnK3dPxFQk&e=
> > List archives at
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__webaim.org_discussion_archives&d=DwICAg&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=MMimM36KI-FWX0bnlG1RIV6Bl3MtdwmuKJCwL2Q3WrQ&m=JLR9yovR7J9IblXyPyvrSDvNEWYXIKADLJ6WlLOwCTw&s=F7m0YfnsVhKVqLZto6D_RlABzlcY0WiS5K6qqcvpnuo&e=
> > > >
>
>
> --
> *Brian Lovely*
> Capital One Digital Accessibility
> 804.389.1064
>
> >
>
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The
> information transmitted herewith is intended only for use by the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that any
> review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
>
>
>
> > > > >

From: Renato Iwashima
Date: Mon, Oct 07 2019 1:58PM
Subject: Re: [External Sender] Accessible tooltips for on boarding
← Previous message | No next message

Thanks a lot Brian and Mallory! These are great information and I'll make
sure to use them.

On Sat, Oct 5, 2019 at 1:17 AM Mallory < = EMAIL ADDRESS REMOVED = > wrote:

> Ah, coachmarks. They are difficult to do well for low-vision and
> blindness. It should be okay for people to skip these and still be able to
> generally find stuff as they use the page.
>
> I second Brian's recommendation, however with an extra: if possible, see
> if the thing being pointed to can be recreated in the coachmark/tooltip
> itself. This because I'm assuming the rest of the page is getting a dark or
> faded overlay? and with low-vision and zooming, we don't necessarily have a
> great idea of where on the page layout we are being pointed to... so we may
> try to get a good look at where the coachmark is referring to-- if there's
> an icon, a name, or both, we want to see it and try to remember it. (If
> that's already visible then don't add it again to inside the coachmark.)
> If the thing being pointed to is inside some kind of named panel or
> toolbar or whatnot, mention it (I hope/assume all the parts of the page
> have consistent naming, both in any documentation you have for users as
> well as how the pages refer to themselves internally... like, if you call
> something a "Help Drawer" then hopefully everything everywhere calls it a
> "Help Drawer").
>
> If there are focusables inside the coachmarks (usually there are, Back,
> Next, OK buttons?), if focus moves either to them or to the coachmark
> itself (similar to setting focus to a whole modal with tabindex="-1") then
> in supporting browsers, the screen magnification will move the user's
> viewport to that coachmark. I suppose if you do that though then you'd need
> to do other modal-style techniques (accessible name and some role on them)
> if they are large and you don't want screen readers auto-reading a huge
> pile of text just because the whole element got focus. On the other hand,
> if they are short this might be exactly what you want.
>
> If this is a dashboard-type thing that isn't viewport-responsive (it
> maintains its width for intrinsic reasons, like Photoshop does, and so
> users must scroll in two directions most of the time), then think hard
> about how you want to refer where page chunks and panels are: while linear
> users like screen reader users benefit from "before" and "after" as
> placement references, for low-vision users adding in "left side" and "right
> side" may be helpful. If the page is responsive though then you can never
> know if users are getting any "sides" or if it's all been collapsed into a
> single column, so sticking to only "before" and "after" makes more sense
> (WCAG mentions being careful with visual placement names, so again I'm only
> suggesting they might be helpful if added *in addition to* linear
> references). I know that when I'm using ZoomText I do try to keep a mental
> model of what's on the left or right, like when I'm using the Gimp to edit
> images.
>
> Try using your coachmarks with both deep browser zoom (~400%) or if you
> can with screen magnification, or play with a piece of paper with a small
> card-sized hole cut out and go through the coachmarks. What visual
> landmarks can you find? Do you get an idea of where things are on the page
> visually, from the text, or iconography? Your content writers might come up
> with good text while keeping it from getting verbose.
>
> When you think you've got something decent, try to find a variety of users
> to test: those with zero familiarity with these kinds of things and those
> who've encountered similar ones, and see how oriented they say they feel
> afterwards.
>
> Finally: sometimes they're just an irritating waste of time. When the
> first one pops up, offer an option to skip the whole damn thing. Those of
> us who wipe all our cookies every time we close the browser tend to get
> coachmarks (and GDPR and cookie warnings) over and over again.
>
> All of the above is just my opinion, though I did spend too many months
> thinking about these at a previous job where they were painful to implement.
>
> cheers,
> _mallory
>
> On Fri, Oct 4, 2019, at 4:08 PM, Brian Lovely via WebAIM-Forum wrote:
> > I would word the text in the modal to ensure non-visual users can
> > understand what's going on. Assuming all page content is semantically
> > correct and has perceivable names (and descriptions, if applicable) then
> I
> > would refer to things by their role and perceivable name. For instance
> "the
> > profile button allows you to view and update your profile information"
> > instead of "this" (graphic of an arrow pointing to profile button)
> "allows
> > you to..."
> >
> > On Thu, Oct 3, 2019 at 6:23 PM Renato Iwashima < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > > Hi,
> > >
> > > It is quite common to find some applications that do a little
> introduction
> > > of their software on first load by having a step-by-step on boarding
> > > tutorial with tooltips that point to specific areas or controls on the
> > > screen explaining what that area or object does. They usually behave
> like a
> > > modal, meaning it blocks the whole screen only allowing you to interact
> > > with the tooltip or with the control it is pointing to.
> > >
> > > Since this interaction is very visually oriented (because it points to
> > > things on the screen), I'd like to know what can be done to make this
> > > experience accessible. What are the best practices for this? Has anyone
> > > seen a good accessible on boarding experience?
> > >
> > > Thanks!
> > > > > > > > >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__list.webaim.org_&d=DwICAg&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=MMimM36KI-FWX0bnlG1RIV6Bl3MtdwmuKJCwL2Q3WrQ&m=JLR9yovR7J9IblXyPyvrSDvNEWYXIKADLJ6WlLOwCTw&s=HV1IvhZ6tP5tGl4JZGIVY76L08x9ZN2HLjnK3dPxFQk&e=
> > > List archives at
> > >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__webaim.org_discussion_archives&d=DwICAg&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=MMimM36KI-FWX0bnlG1RIV6Bl3MtdwmuKJCwL2Q3WrQ&m=JLR9yovR7J9IblXyPyvrSDvNEWYXIKADLJ6WlLOwCTw&s=F7m0YfnsVhKVqLZto6D_RlABzlcY0WiS5K6qqcvpnuo&e=
> > > > > >
> >
> >
> > --
> > *Brian Lovely*
> > Capital One Digital Accessibility
> > 804.389.1064
> >
> > > >
> >
> >
> > The information contained in this e-mail is confidential and/or
> > proprietary to Capital One and/or its affiliates and may only be used
> > solely in performance of work or services for Capital One. The
> > information transmitted herewith is intended only for use by the
> > individual or entity to which it is addressed. If the reader of this
> > message is not the intended recipient, you are hereby notified that any
> > review, retransmission, dissemination, distribution, copying or other
> > use of, or taking of any action in reliance upon this information is
> > strictly prohibited. If you have received this communication in error,
> > please contact the sender and delete the material from your computer.
> >
> >
> >
> > > > > > > > > >
> > > > >