WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: AccessiBe! Help!!

for

From: Sandy Feldman
Date: May 27, 2022 8:34AM

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Max, thank you so much for taking the time to look at this. This
is a really usable example. Fingers crossed it's going to work!</p>
<p>Thank you, everybody on the list, for your support in a
frustrating situation.<br>
</p>
<div class="moz-signature">Sandy
<p><a href="https://sandyfeldman.com">sandyfeldman.com</a>
<br>
<a href="https://www.a11yready.com/">a11yready.com</a><a>
</a></p>
<a><br>
<br>
</a></div>
<div class="moz-cite-prefix">On 2022-05-27 10:26 a.m., Max
Starkenburg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+yoswsa2Yma1ugaFvydpwgbwYnM= <EMAIL REMOVED> ">
<pre class="moz-quote-pre" wrap="">Hi Sandy,

Here's a concrete example of where I'm finding AccessiBe to make this site
less accessible: If I keyboard-navigate to the search icon (magnifying
glass button), and then hit Enter or Space to open the search input, a
second or two later (after I might have already started typing my query),
focus is stolen away from the search input. A little black dialog appears
at lower left reading "Popup panel. Press ESCAPE to close, navigate with
TAB. / [n] Seconds until closing. Playing to screen readers." Besides this
seeming terrible COGA-wise, pressing Escape not only does NOT close this
AccessiBe-generated dialog, it instead collapses the search input, once
again losing my focus (both keyboard-wise and metaphorically). (Small
caveat: it seems this behavior requires first that a check icon appear next
to the AccessiBe gear icon (I think supposedly indicating you've started
configuring it), but all that's required for that check icon to appear is
for me to Tab through the 3 "skip" links that AccessiBe generates.) I'm
seeing this happen across Safari, Mac Chrome, and Mac FF (though today I
also learned that the uBlock Origin add-on on FF was blocking AccessiBe
from loading ... nice!). Also, if I just wait out the "[n] Seconds until
closing", focus does not get returned to the input.

I wondered if this experience might be different with a screen reader on,
and though I'm not an SR user, I turned on VoiceOver and once again
navigated to the search input in Safari, and it seems no better. If
anything it seem worse, because there's no aural indication of why focus
was stolen; instead of AccessiBe "playing to screen readers" (as it claims
it's doing), VO just announces "You are currently in a banner, inside of
web content" (whereas if focus hadn't been stolen, it would instead be
announcing things about the text input).

Best of luck,

Max
</pre>
</blockquote>
</body>
</html>