WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [External Sender] Accessible tooltips for on boarding

for

From: Renato Iwashima
Date: Oct 7, 2019 1:58PM

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