Overlays Underwhelm: a11y NYC

Following is the live stream of the talk from YouTube. Owing to Fat Tuesday, I stepped away from a feast of gumbo, jambalaya, red beans & rice, and etouffee to give this talk (and went back for king cake immediately after). Which explains the beads. Which, it turns out, were a terrible idea to wear for the entire video.

a11y NYC The rest of this post is a collection of images, videos, tweets, articles, and links referenced in my talk.

The typeface in my slides is Atkinson Hyperlegible, a free font from Braille Institute of America.

Intro

I had the title before I had the content. I tried to shoehorn this over / under theme into the talk. Maybe not my best idea.

Slide 4: Tim Berners-Lee

The actual Tim Berners-Lee quote:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

The gag is that this quote is used in so many intro accessibility talks that it has become an unfortunate cliché. Which is why I used Patrick Lauke’s and Bruce Lawson’s Tim Berners-Lee Quote’o’matic fictitious quote generator.

Overview Understated

What is an overlay? A tool that provides some sort of accessibility or usability feature that may not be built into the underlying site; sometimes it replicates native features and sometimes it offers some other affordance.

Slide 7: Browsealoud

As you can see, it offers no context for what is being read, visible or not. It was never meant to replicate screen readers. Instead it is akin to a feature you can find built in to browsers today, such as Edge’s Immersive Reader.

Announcement of the Browsealoud rebrand, and more info on the crypto-jacking of the Browsealoud script.

Slide 9: Text Resize Widget

Annoted demonstration of the New York Times text resizing widget using Edge 14. I did not choose Edge because it behaved any worse or better in that browser. The bullet list preceding this video is the description of what is happening.

Originally from my 2016 post Don’t Re-Create Browser Features.

Slide 11: Hand Talk

Hand Talk presents the content of the page in sign language. To its credit, it is not finger spelling everything it encounters.

Hand Talk’s post announcing version 4.0.

Overstate Underperform

Overlays tend to overstate their abilities. In technical reviews, they consistently underperform.

Slide 15: accessiBe versus Axe

Axe showing 4 violations before running the accessiBe overlay on the AI page. Axe showing 12 violations after running the accessiBe overlay on the AI page.
Running Deque’s Axe browser plug-in reveals more WCAG violations after enabling the accessiBe overlay, from 4 to 12.

Slide 16: accessiBe versus ARC Toolkit

ARC showing 19 violations before running the accessiBe overlay on the AI page. ARC showing 38 violations after running the accessiBe overlay on the AI page.
The Paciello Group’s ARC browser plug-in also shows a jump from 19 violations to 38 after running the accessiBe overlay.

Slide 17: accessiBe versus WAVE

WAVE showing 0 violations before running the accessiBe overlay on the AI page. WAVE showing 0 violations after running the accessiBe overlay on the AI page.
WebAIM’s WAVE checker browser plug-in returned no violations aside from a single contrast violation. These results are not surprising given it may be spoofing WAVE and I get the WAVE warning when I use the bookmarklet.

Slide 19: MaxAccess and its Failure to Stop

The ‘Stop Animations’ button on this overlay fails to stop the auto-playing background video. To compound the confusion, the button changes only its accessible name when pressed. It does not use aria-pressed to indicate it has been activated.

See the unstoppable background video in action at the bottom of this page.

Slide 20: EqualWeb Traps Keyboards

I tried the keyboard navigation feature of one vendor. Even after I activate the feature, focus styles are still missing. Eventually a new box appears, with different links. I was tabbing so much already I tabbed past the item that displayed the instructions. To drive home the point, it drops me into a de facto keyboard trap in its cookie pop-up.

You can try your luck at the vendor’s home page.

Slide 22: When the Overlay Itself Violates WCAG

4 views of the overlay, each one has white text on a light gray background and hover styles that are minor changes in size.
The overlay is long, so this image captures 4 screenfuls. The screen shot is from Chrome 87 on Windows, a common browser, though it behaves this way across browsers. The image is a link to a larger file where you can try to guess over which control I am hovering.

You can visit the example site, Aquis.com, and try it for yourself.

Slide 23: When the Overlay Itself Violates WCAG, Proof

A color contrast analyzer showing the white text against the very light peach background has a contrast ratio of 1.2:1.

This uses the Colour Contrast Analyser.

Slide 24: When Declining the Overlay Breaks the Page

The video shows the browser default focus ring, then the alert prompting the user to enable the overlay at :09. When declined, from :12 forward you can only tell that focus is changing by looking at the browser status bar.

Slide 25: When the Overlay Keeps Selling

Navigating to the Lawsuits page of the AccessUS web site. The page gets a gray overlay, and then audio starts to play with no visible video player or audio controls.

Give it a shot yourself at the AccessUS site, and maybe get startled by the hidden voices.

Slide 26: FACIL’iti Failures

Browser dev tools showing the multiple possible accessible names for the FACIL'iti button and absent focus styles.
The browser developer tools are the quickest way to see the multiple WCAG failures (1.1.1, 2.4.7, 2.5.3) on the control that is supposed to make the page more accessible.

Try it for yourself at the Abilities Expo site.

Slide 28: Overlay Guarantees

Does accessiBe protect me from lawsuits? Absolutely! accessiBe turns inaccessible websites into WCAG and ADA compliant websites. But not only that, accessiBe provides you with a Litigation Support Package, in case you need to prove your ADA website compliance, and guides you through the process. Does accessiBe cover all accessibility requirements? Yes! accessiBe covers the WCAG (Web Content Accessibility Guidelines) version 2.1 at the AA level success criteria, and in certain areas even level AAA. This is a step beyond what legislation requires.
accessiBe home page, captured 6 February 2021.

Slide 29: Reality of Overlay Guarantees

From the accessiBe Terms: "Standard" means WCAG 2.1 level AA success criteria.
accessiBe Terms of Service, captured 30 March 2021, dated 14 December 2020.

Slide 30: More Reality of Overlay Guarantees

From the accessiBe Terms: The functionality of the accessiBe Systems requires that the Licensee Website in which they are embedded be websites based solely on HTML files and tags, and that the source code be written according to the Standard of the World Wide Web Consortium (“W3C”), without any errors or validation warning in W3C’s troubleshooting inspections; please note that Licensee changes to such website may impact the functionality of the Service. By way of example, accessiBe Systems do not support other components, such as Canvas, Flash and/or SVG.
accessiBe Terms of Service, captured 30 March 2021, dated 14 December 2020.

Slide 31: Just a Few Overlay White Lies

UserWay list of claims. Compliance: Makes your site ADA compliant. Lawsuits: 0 lawsuits mentioning UserWay’s AI Solution. Reputation: Strong reputation with the disabled community. Privacy: Privacy by design, data minimization. Security: Privacy preserving, does not track user types/identify people with disabilites [sic].
UserWay vs accessiBe, captured 9 September 2021.

Slide 33: Lawsuits Naming Overlays

Page 13 of Blair Douglass v. Masterbuilt Manufacturing, LLC Page 7 of Fischler v Dorai Homes complaint Page 1 of Lighthouse et al v ADP Inc. Page 14 of Murphy v Eyebobs complaint Defendant’s online store includes an “accessibility widget” which shoppers may allegedly use to enhance their user experience. The widget supposedly helps shoppers increase color contrast, highlight links, and stop animations, among other things. To use the widget, shoppers must activate, or “click,” a floating button on the right side of the Website. Once activated, Defendant displays a pop-up window. Shoppers who perceive content visually can click the pop-up window to activate the widget’s various tools. Unfortunately, the Website does not alert Plaintiffs’ screen readers when this pop-up window appears. Instead, their screen readers remain locked on the Website’s underlying page, making it impossible for them to use the “accessibility widget” independently. Defendant’s online store includes an “accessibility widget” which shoppers may allegedly use to enhance their user experience. The widget supposedly helps shoppers adjust font and emphasize titles, among other things. To use the widget, shoppers must activate, or “click,” a floating button on the right side of the Website. Once activated, Defendant displays a pop-up window. Shoppers who perceive content visually can click the pop-up window to activate the widget’s various tools. Unfortunately, the Website does not alert Plaintiffs’ screen readers when this pop-up window appears. Instead, their screen readers remain locked on the Website’s underlying page, making it impossible for them to use the “accessibility widget” independently and thereby defeating its purpose.

From the ADP settlement agreement:

“Accessible” (or “Accessibility” or “Access”) means that blind and low vision individuals have independent access to the same information and equivalent ease of use of functionalities available to sighted individuals via the Website or Mobile Apps. For the purpose of this Agreement, “overlay” solutions such as those currently provided by companies such as AudioEye and AccessiBe will not suffice to achieve Accessibility.

Slide 34: Wired

Wired. November 11, 2021. This Company Tapped AI for Its Website—and Landed in Court. Under pressure to make their sites accessible to visually impaired users, firms turn to software. But advocates say the tech isn't always up to the task.
This Company Tapped AI for Its Website—and Landed in Court, November 11, 2021

These two paragraphs stood out to me:

In a statement, AccessiBe’s head of marketing, Gil Magen, said the company had analyzed Eyebobs’ website and found it complied with accessibility standards. AccessiBe offers clients assistance with litigation but Eyebobs declined, the statement said.

In its own statement, Eyebobs said AccessiBe failed to respond to requests for meetings with its lawyers. “Eyebobs is no longer working with AccessiBe nor will we in the future,” the statement said.

Slide 36: Overlays Sometimes Fail to Load

Firefox dev tools showing the link and raw HTML along with a script error that the widget was not initialized.
The browser is showing it cannot load the script, and the trigger to load the accessiBe overlay is a <div> with a tabindex and a button role.

Slide 37: Overlays as Malware

On July 27, 2020, Nycanuck said: I am trying to determine if the blocking of acsbap.com is legitimate. It looks like this may be a tracking service and is used by a number of vendors. Below is the block. Malware Bytes staff responds: Hello, thanks for bringing this to our attention. We've reviewed the site again and have determined it no longer warrants being blocked so we've removed it from our database. Removal should be reflected in the next database update going out in a few hours or so.

The forum entry.

Slide 39: Dodging Data Protection

Also from Léonie’s post AccessiBe and data protection?.

Slide 40: Third-Party False Choice

Browser alert: An embedded page at a40.usablenet.com says: Your web browser privacy settings are preventing the accessibility mode to stay enabled. Try enabling third party cookies to ensure you receive accessible updates to the website.
The DSW site uses UsableNet’s Assistive overlay. If you block third-party cookies, you get this browser alert. Nowhere does the user have the opportunity to understand how those third-party cookies will be used, what information will be shared. A user can then decide between disclosing their disability or using a broken site.

Overpromise Underdeliver

Overlays will over-promise in their marketing, making claims about their utility and popularity while under-delivering on them.

Slide 43: Villainizing

Cartoon. A man at a computer happily exclaims, "Finally, my website is up!" Two men in suits appear next to him holding legal papers and say, "Not so fast! Nice website, but it's not accessible! You've been served." Shows the man again, crying, hands up in the air, saying, "I'm broke now. Why bother?" In the background the two men can be seen walking away carrying bags of money.
The accessiBe LinkedIn post where this first appeared in May 2021 and, after getting some push back, removed and disabled comments.

Slide 44: Silent Majority

Slide 45: WordPress Ban

Headline on WP Tavern: WordPress.org Removes Fake Reviews for AccessiBe Plugin
WordPress.org Removes Fake Reviews for AccessiBe Plugin, February 18, 2021

Slide 47: NBC News

NBC News: Blind people, advocates slam company claiming to make websites ADA compliant. “If you have a website, do you want to include disabled people or do you want to exclude them? That’s why it's a civil right,” one expert said.
Blind people, advocates slam company claiming to make websites ADA compliant, May 9, 2021

Slide 48: Vice

Vice, Motherboard headline: People With Disabilities Say This AI Tool Is Making the Web Worse for Them AccessiBe aims to make the internet fully accessible to the visually impaired by 2025—but activists say the company's AI is making things worse.
People With Disabilities Say This AI Tool Is Making the Web Worse for Them, March 17, 2021

Slide 49: Mosen at Large

Mosen at Large: Episode 105: The AccessiBe controversy. Can AI make the web fully accessible in a few short years, or might it make matters worse?
Episode 105: The AccessiBe controversy. Can AI make the web fully accessible in a few short years, or might it make matters worse?, March 14, 2021

Slide 50: Overlay Blockers

accessibegone. Instructions for blocking AccessiBe and similar intrusive overlays. Chrome Web Store: AccessiByeBye from Pneuma Solutions.
AccessiBeGone and AccessiByeBye

Slide 51: FACIL'iti and Frivolous Lawsuits

A view of the first two pages of the Mise en demeure from FACIL'iti to Koena demanding critical tweets be removed.
In April, FACIL’iti’s attorneys started sending letters demanding removal of any criticism. This letter to Koena shows two tweets about FACIL’iti.

Koena writes about the referenced demand letter in Koena mise en demeure par FACIL’iti. Another frivolous suit is outlined in Aide pour mes frais d’avocate dans mon procès contre FACIL’iti, which is also available in English.

15 November 2021: Koena has provided an update in Procès FACIL’iti : conclusions de Koena déposées le 12 novembre 2021.

Slide 53: National Federation of the Blind

National Federation of the Blind, press release dated June 24, 2021: National Convention Sponsorship Statement Regarding accessiBe

The full NFB press release.

Slide 54: CSUN Conference on Disabilities

Slide 55: We The 15

Slide 57: Overlay Fact Sheet

The Overlay Fact Sheet site showing the table of contents.

Visit the Overlay Fact Sheet and consider signing.

Slide 59: Borrowed Credibility

The footer from the MaxAccess site, showing the IAAP logo. The footer of the UserWay site, showing the IAAP logo.
UserWay and MaxAccess display the IAAP logo in their footer, using the weight of accessibility professionals (you) as a marketing boost.

IAAP promotes AudioEye and its post seemingly mostly lifted from the W3C.

Slide 60: IAAP Member Survey Responses

A large majority are not Overlay sellers (97%) and of the remaining percentage, again the majority (81%), do not compete with other companies that sell Overlays.

Of those surveyed, 90% say they have seen ‘false claims’ in the ‘advertising’” by companies about the technology.

[A] majority (86%) believe that the IAAP should comment on the marketing of accessibility technology and 90% of respondents say that the IAAP should comment about the marketing of Overlays specifically.

Overnight Undertake

Overlays cannot make your site, or your brand, better overnight. There are some steps you can undertake, however.

Slide 62: Plan Ahead

Slide 63: If You Already Have a Site

Slide 64: Overlay False Claims

Slide 65: Claim Your IAAP Credits!

This talk was not vetted by IAAP, but it was pre-approved for IAAP credits. So claim them and don’t forget to mention this talk as you ask IAAP to drop overlay vendors from its membership (read IAAP’s position statement).

5 Comments

Reply

I’ve spent a long time looking for comprehensive a11y advocates that could clearly outline the problem and provide a solution. Thank you for these slides, I’ll be sure to share this article with my coworkers.

Reply

Adrian, thank you for this. Hope it will be watched by everybody wanting to take accessibility shortcuts with overlays instead of really understanding and supporting all of their users.

Personally I always argue that overlays will be possible when automatic tools will find all errors and passes on a page. So, not in the near future. Even then there are plenty other obstacles, as you described so well.

I’ve decided to ask you about a detail from the speech that I would like to understand better. Nothing to do with overlays, but with WCAG;

I’m still learning about WCAG and was a bit confused when you mentioned the keyboard trap when demoing equalweb’s site with keyboard and landing inside cookie consent modal.
Is it really a keyboard trap if user can close it with activating “close”?

As I can see in the code it is coded as role=”dialog” and aria-modal=”true”, so I was thinking it is actually proper UX to keep focus inside for users to make a choice in a dialog.

I’ve read Understanding SC 2.1.2 and found:

A modal dialog box:
A Web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button.

So just wonder why would you fail it as a keyboard trap. Thought that was an intentional UX for dialogs and am a bit confused now…

A11y student; . Permalink
In response to A11y student. Reply

For later reference, this is the most recent version of the Understanding SC 2.1.2 document (the version you linked is for WCAG 2.0, though essentially the same).

I’m still learning about WCAG and was a bit confused when you mentioned the keyboard trap when demoing equalweb’s site with keyboard and landing inside cookie consent modal.

I said “de facto” keyboard trap. I included that qualifier because I did not test anything beyond using the Tab key (such as by activating “Close”).

Is it really a keyboard trap if user can close it with activating “close”?

Nope. But a user may not know if activating “close” equates to granting consent. Realistically, a privacy-minded keyboard-only user’s best option is to press Ctrl+W and close the tab.

As I can see in the code it is coded as role=”dialog” and aria-modal=”true”, so I was thinking it is actually proper UX to keep focus inside for users to make a choice in a dialog.

It is not a modal. At least not for me in Chrome this morning. It has no role:

<div id="topbar" style="visibility: visible; left: 1px; top: 1px;">
 <div class="modal-title" id="cookies-modal-title">This website uses cookies</div>
 <p>
  We use cookies to improve your experience on EqualWeb and provide you with more relevant and personalized services.
   By continuing to browse on EqualWeb you agree to our use of cookies.<br>
  <a target="_blank" class="ew-blue-text" href="https://www.equalweb.com/html5/sbs.py?_id=8615&did=1116&G=8593">Learn More</a>
 </p>
 <a href="" onclick="closebar(); return false" class="closeBtn">
  <span>Close</span>
 </a>
</div>

In fact, if you search this XPath in your dev tools, , you will see only one modal in the code (a <div> with role="heading" and tabindex="0").

If you are seeing a version of the page where the cookie box is properly marked up as a dialog, then ensure you cannot get to the underlying page in your screen reader. And see if it closes on Esc. My guess is they messed that up too.

So just wonder why would you fail it as a keyboard trap.

I wouldn’t; see my use of de facto above.

In response to Adrian Roselli. Reply

Thank you for your reply.

OK, will give more attention to the “de facto” statements in the future :)

Gotcha – consents like this are not consents at all :)

The modal actually modifies only after they convinced / forced me to go into their “accessibility mode”. Then the code was like:

<div class="responsiveBlock Sban_All_site" style="font-size: 14px; line-height: 18.2px; word-spacing: 1px;">
 <script type="text/javascript" src="/html5/Web/Adminstyle/js/sban.js"></script>
 <div id="topbar" style="visibility: visible; left: 1px; top: 1px; font-size: 14px; line-height: 18.2px; word-spacing: 1px;" role="dialog" aria-modal="true" class="INDblock INDdialog" aria-hidden="false" aria-labelledby="cookies-modal-title">
  <div class="modal-title" id="cookies-modal-title" style="font-size: 20px; line-height: 20px; word-spacing: 1px;">This website uses cookies</div>
  <p style="font-size: 14px; line-height: 15.4px; word-spacing: 1px;">
   We use cookies to improve your experience on EqualWeb and provide you with more relevant and personalized services.
    By continuing to browse on EqualWeb you agree to our use of cookies.<br role="none">
   <a target="_blank" class="ew-blue-text" href="https://www.equalweb.com/html5/sbs.py?_id=8615&did=1116&G=8593" style="font-size: 13px; line-height: 13px; word-spacing: 1px;" tabindex="20">Learn More</a>
  </p>
  <a href="" onclick="closebar(); return false" class="closeBtn" style="font-size: 13px; line-height: 13px; word-spacing: 1px;" tabindex="20" role="button" aria-label="Close dialog box">
   <span style="font-size: 13px; line-height: 13px; word-spacing: 1px;">Close</span>
  </a>
 </div>
</div>

But yes – a lot of other erorrs, even with “accessibility mode” on…

Once again – thanks – and I really hope folks find overlays for what they are – as described so good by you and other veterans of accessibility.

A11y student; . Permalink
In response to A11y student. Reply

You have to escape < and > in comments or WordPress eats it. I replaced what was left of the code you pasted with the raw code from EqualWeb after enabling its “accessibility mode”.

I am guessing you also noticed that “Close” link suddenly became gray on white, failing WCAG with a 2.3:1 contrast ratio. Plus the positive tabindex values. And the unnecessary aria-label. So EqualWeb’s remediated modal introduced at least one new WCAG issue. Which I guess warrants a slow clap.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>