Thanks to a comment on my post #accessiBe Will Get You Sued, I found UserWay had taken the meat of that post, re-cast as its own effort, and was using it as a marketing effort to frame its overlay as a better product than accessiBe.
For some reason, in its response UserWay decided linking to Gareth Ford Williams’ post What are accessibility overlays good for? somehow validated it and its overlay.
Unlike my post #accessiBe Will Get You Sued, I am not going to give UserWay free technical or business advice. I learned that lesson when accessiBe used it to attenuate its messaging (but, interestingly, not fix its product). I am going to paint with some broad strokes, however. I am also skipping some of the claims that I cannot validate (because I have no access to their servers and/or the statements are fluff).
Lie: Makes your site ADA compliant
This statement misrepresents the ADA. UserWay is taking advantage of ongoing misunderstandings with what the ADA covers, what case law says it covers, and what people buying these products thinks it covers.
If we take ADA at face value, this is similar to saying UserWay makes your site FDA compliant. If we take ADA as interchangeable with WCAG, then a quick automated check will demonstrate otherwise.
Axe, which prides itself on no false positives, finds 3 WCAG issues tied to testable WCAG Success Criteria on that page. ARC Toolkit finds 4, matching Axe and adding another valid problem. WAVE finds none, but does raise 202 alerts, including 111 cases of suspicious image alternative text. My favorite example of this is the image of the accessiBe widget that has the alternative text Picture of UserWay widget.
UserWay Causes WCAG Failures
Added 31 October 2021. The article Technology can’t solve the problems ableism creates at The Stanford Daily talks about the hype around the “laser cane” intended for blind people. It also unintentionally makes a statement on overlays, with UserWay’s tool providing the metaphor.
Here UserWay reduces contrast on a site, causing a 1.4.3 Contrast (Minimum) violation. When you re-open the overlay to undo it (at 0:16), the overlay sends you to the UserWay site, a 3.2.2 On Input violation.UserWay offers to make links more visible, but when you undo it the icon links all but disappear, resulting in a 1.4.11 Non-text Contrast violation. At 0:14 you can see UserWay’s overlay again cause a 3.2.2 On Input violation.This is not a WCAG violation, but the use of dyslexia-specific fonts as a catch-all has been debunked. Trying to swap to any other typeface triggers the 3.2.2 On Input violation, which you can see at 0:17, 0:25, and 0:34.Good news for UserWay here — the text on the page gets larger. Unfortunately, UserWay’s own widget gets smaller as you go. It seems unlikely this will satisfy 1.4.4 Resize text. I avoided the 3.2.2 On Input violation here by closing the page.
Update: 21 March 2022
After my conversation with UserWay’s COO, I evaluated the single site example in this post. To the COO’s credit, he is correct that someone fixed the problems I identified at The Stanford Daily — by removing the UserWay overlay.
The Stanford Daily article seemingly uses the WP Dark Mode plug-in instead of UserWay now, which (unlike UserWay’s solution) works if you use a pointer. Keyboard users are stuck because the control is a <div> with no role, no ability to give it focus, and no keyboard handler. Yet this is still somehow better because at least some users will get a functional dark mode.
Lie: Strong reputation with the disabled community
Nearly 600 people in and supporting the disabled community have said very much the opposite. They have signed on to the Overlay Fact Sheet which includes this statement:
More specifically, we hereby advocate for the removal of accessiBe, AudioEye, UserWay, User1st, MK-Sense, MaxAccess, FACIL’iti, and all similar products and encourage the site owners who’ve implemented these products to use more robust, independent, and permanent strategies to making their sites more accessible.
Questionable: Privacy by design, data minimization
I cannot look into UserWay’s systems to understand what it does with the data it captures. I can, however, look at how it presents privacy and compliance to users. It has an alphabet soup of related and unrelated laws linked from its footer: HIPAA, GDPR, COPPA, FERPA (it also lists ATAG and WCAG, which are outside the scope of privacy). I was surprised PCI-DSS wasn’t in there just for more letters.
Following each link brings you to a page describing the law but not how UserWay conforms — let alone how it is relevant. HIPAA, for example, has no bearing on UserWay (egad, I hope no patient portals are using it). Just like anti-vaxxer claims that asking for proof of a vaccine is a HIPAA violation, UserWay is happy to capitalize on that same misrepresentation.
UserWay is, however, happy for you to contact it instead of telling you how any of these apply: To learn more about how UserWay’s Accessibility Widget complies with HIPAA regulations, please contact us. The contact us link is the same destination as the free trial link that immediately follows.
Haben Girma has been advocating on behalf of the disabled community for years. She wrote about being the first Deafblind person to graduate from Harvard Law School. When she weighs in on overlays, it is not just from personal experience but also based on her recognition of the harms the tool is creating.
Criticism from Twitter Users
I am a bit amused that UserWay thinks users critical of accessiBe automatically equates to support of UserWay. I mean, I get it, for the people they are targeting that is probably more than adequate.
But half of the people behind the tweets quoted on that page are signatories to the Overlay Fact Sheet. They have explicitly stated UserWay is one of the bad options. UserWay is intentionally misrepresenting their statements as a result. And they are not cool with that.
Anti-accessiBe Press is Critical of UserWay Too
UserWay makes it a point to reference articles that are critical of accessiBe explicitly. More accurately, it references two news pieces and two opinion pieces. One opinion piece is my post #accessiBe Will Get You Sued, which I have updated to include a note about UserWay.
Remember, these are pieces critical of accessiBe that go out of their way to note that all overlays are a problem.
But over the past several months in particular, as AccessiBe’s footprint has spread, many people with disabilities have grown increasingly angry at it and other automatic web overlay companies. The tools often make websites less usable than they were before, and the companies’ marketing strategies, they say, emphasize the need for business owners to avoid lawsuits rather than actually make their websites usable.
Greco, at the University of California, Berkeley, said other companies have similar products that have many of the same technical issues AccessiBe does. But AccessiBe stands out because of its rapid growth, heavy marketing and defensive style of engagement with blind people who claim it hasn’t worked for them.
The other opinion piece is a Forbes Sites piece (these are written by people who pay to host their articles under the Forbes banner, they are not Forbes writers) that says:
First and foremost, there remains one key principle to keep front of mind — currently, there exists no overlay technology on the market that can, by itself, render a website fully accessible and protect it from ADA lawsuits.
This Is Just UserWay’s Marketing Response
That gray bar under the breadcrumb? Just accessiBe’s developers thinking making it into a clipped scrolling area is somehow better than just letting text wrap.
This post from UserWay is just a response to accessiBe’s own claim that UserWay will put you at risk, except in this case UserWay uses the title of my post (ostensibly to reduce its legal exposure). Obviously, there is evidence that sites with accessiBe still get sued, but UserWay’s argument is that accessiBe’s overlay is somehow unique for that.
UserWay has removed the abstract and link to my post, but it has not removed the title of my post. That title, accessiBe Will Get You Sued, still lives on the UserWay page in an <h2>. The heading suggests they like the link juice too much and the quotes imply some level of distance should accessiBe’s lawyers come calling (by claiming they are simply quoting me).
Olympics and #WeThe15
UserWay proudly advertises its use on the Tokyo Paralympics web site. Another site from the Paralympic Committee, #WeThe15, was launched to promote disability awareness and end discrimination. It also had the UserWay overlay.
#WeThe15 fixed it by removing UserWay from its site, along with a couple tweets acknowledging and apologizing.
I am not surprised the Paralympic folks have done nothing. Partly because they were not directly engaging the community, and partly because between taking the inspiration porn angle and failing to make its videos accessible (that it borrowed from WeThe15), it seems fair to assume they were not really invested in the message.
Wrap-up
Will UserWay get you sued? Maybe. We already know that users can disable overlays, scripts can fail, connections can be dropped, and features can collide. Even if the product itself performed as it claims, there is always a chance it will not function. As such, it is a poor substitute for building your thing the right way the first time.
I cannot say if UserWay is as bad as accessiBe on the technical side, because I am not giving away free reviews anymore. I cannot even say if UserWay is as amoral as accessiBe, simply because UserWay has less money to spend. I can say, however, that the trends are clear — UserWay lies about its offering and lies about community support. I doubt it is in any way better, no matter how low the bar is that accessiBe has set.
UserWay and accessiBe are two rotten peas in a dirty dirty pod.
Removed: 19 September 2021
UserWay made a smart call and removed the page from its site. If you go there now you will get a 404 page. Had you gone there Friday, you would have seen they had removed my name (as I noted above).
UserWay has made no apologies nor explanations. I leave it to the reader to guess why UserWay decided now to remove it, and wonder how many other false claims and stolen material UserWay is passing off as its own truthful content. If nothing else, UserWay has demonstrated it has a credibility problem.
Update: 21 March 2022
After my conversation with UserWay’s COO, he asked me to remove this post, believing that since UserWay had deleted the page with my stolen content there was no longer a reason for me to leave it. I pointed out that UserWay never publicly acknowledged it had taken my content, mis-represented my words, and used my name in its marketing efforts all without my consent. Even today that page is a 404 instead of a public apology, which I explained demonstrates how UserWay believes it did no wrong and only moved to limit its reputational harm.
This post will remain, even if UserWay finally demonstrates contrition, because it is a record of UserWay’s unethical business practices and its failure to take steps to correct them. The best predictor of future behavior is past behavior, and we need to remember how UserWay (and its leadership) has operated in the past before trusting it in the future. We can only hope it is willing to make that difficult journey to rehabilitate its products and services before trying to do so with its image.
Even with the benefit of Firefox warning that the Black Friday dialog is inaccessible to keyboard users, UserWay chose to post content that violates WCAG in at least three different ways.
The code also demonstrates UserWay does not understand ARIA. While aria-label does not belong on a <div>, maybe UserWay’s hope was to override all the content within (because that’s what aria-label does). Though if the aria-hidden="true" on the images with alt="" wasn’t a head scratcher on its own, given the context of the aria-label wrapper it is certainly one now.
As part of this Black Friday deal, UserWay’s spam emails are also promising full WCAG coverage (emphasis theirs). That is clearly not true.
UserWay Buys Positive Reviews
Added 22 November 2021. Not to be outdone by accessiBe’s practice of paying for praise, UserWay is offering its customers Amazon gift cards to leave positive reviews at software review site G2.com.
In this UserWay Black Friday spam message (source), UserWay is offering a $30 Amazon gift card for a positive review, and $50 for a positive video review. Note it also promises full WCAG coverage, a lie since we have seen UserWay is more likely to introduce WCAG issues.
The UserWay reviews on G2.com are not from end users, but from UserWay customers. To reiterate, the people rating the product are not disabled end users who need accessibility affordances, they are from business owners who are being compensated to leave positive reviews. Note that UserWay says it will review submissions before compensation.
If you want to see what contributors and editors for WCAG, ARIA, and HTML specifications, internal accessibility experts for companies, internal accessibility experts from higher education institutions, lawyers for the disabled, contributors to assistive technology software such as JAWS and NVDA, and scores of end users with disabilities think about UserWay, then visit the Overlay Fact Sheet.
None of the names on the Overlay Fact Sheet were paid for their signature.
If you have other examples of false advertising (perhaps you have received marketing emails, or been pitched by your web site vendor / overlay reseller) or links for filing consumer complaints in other countries, then please submit a GitHub issue.
As part of the 2021 Digital Accessibility Legal Summit, Jeremy Horelick, Jason Taylor and Richard Hunt discuss widgets, plug-ins and overlays being marketed as one-step software solutions to website accessibility. They provide a brief review of terminology and differences between the various products, followed by an examination of whether these tools will do what they promise—in terms of both actual accessibility and protection from website accessibility litigation.
When asked if overlays reduce litigation expense or risk, the answer was a resounding no. You can jump to 31:46 of the video and listen/read for yourself, but I have quoted the salient bit:
They absolutely do not. And there are two reasons why this is true. The first reason is simply because they don’t actually fix websites. […]
The other reason is because the law firms, not all the law firms, but many of the law firms that are in this area do not care whether the website is really accessible or not. Their desire is to find something that they can identify as an error, usually by measuring it against WCAG, and if they can find that error, they can file a lawsuit in good faith. Remembering that their goal is to settle the lawsuit as soon as possible.
On slide 31 I referenced a claim by UserWay that there were no lawsuits mentioning UserWay. I said I could not verify that claim. Thanks to UserWay saying the talk was not accurate, I was motivated to dig up a suit that mentions UserWay. Remember UserWay’s now-deleted claim was live as far back as 9 September, and most certainly earlier.
In Paguada v. YieldStreet, YieldStreet attempted to get the lawsuit dismissed by adding the UserWay plug-in sometime in March 2021. In April 2021, an expert witness identified barriers and WCAG failures that persisted despite (and/or because of) the plug-in. The motion to dismiss was denied, signed 20 October 2021.
UserWay was not named in the original suit, only the motion, and UserWay’s failure to provide the required cure was not official until more than a month after the earliest date of that post I could find. Though UserWay knew its failure of compliance by April 2021 given that it responded to the failure. Not enough to assert UserWay lied, but enough to make me wonder what UserWay considers a gray area.
After a Conversation with the COO: 21 March 2022
While at CSUNATC this year (2022), the Chief Operating Officer (COO) of UserWay intercepted me as I entered the opening night mixer, before I got to talk to anyone else. He wanted 10 minutes of my time, which I begrudgingly granted him even though it was not a public conversation.
I understand he spent much of CSUN asking for one-on-one conversations with known practitioners, something I later counseled people against accepting (also in real life) when I found out.
UserWay’s COO said he watched my a11yNYC talk about overlays and had read this post. He said the issues I raised had since been fixed but my material did not reflect that. So I went back through this post and the talk to see what warranted an update.
The following anchor links will take you to the appropriate part of this post:
My other findings — reputation, privacy guarantees, IAAP membership, criticisms, failures under WCAG, buying reviews, false advertising, legal claims — all still hold true.
UserWay Tries to Cash in on W3C Brand: 19 June 2022
The same day the Community Group was proposed, the UserWay COO, The UserWay CEO, two UserWay Advisors, and an Accessibility Evangelist at AudioEye all signaled their support and the group was formed at 7:56pm ET on 26 May 2022. This was announced on Twitter via an automated tweet from the W3C. At launch, the group had only two of the people who signaled their support, plus one other person, for a total of three (3) participants.
The automated tweet directed users to the seemingly auto-generated Call for Participation in Overlay Community Group, asking for people to join. On 27 May 2022 at 7:38pm ET I left the following comment on the Call for Participation:
I think it is crucial that a W3C Community Group is founded with accurate information, especially when soliciting participation.
Some notes on the premise of overlays as stated in this announcement:
> These function by adding a snipet of javascript into a web content provider’s page.
The “snippet” is a script reference to a library of code that comprises a good deal more functionality than a snippet would imply. That script reference is then loaded by the end user’s browser and applied to the web page by the end user’s browser.
> Typically, this single line of additional code functions to enable, on each page load, additional content processing, delivered through the overlay provider’s servers, before the content is delivered to the end user.
Again, this “single line” is a reference to a URL where a much larger library of code lives (even if it has been minimized to have no line feeds).
The “content processing” is not done on page load. It is performed after the script has been fetched, parsed, and applied to the web site DOM by the end user’s browser.
The statement that this happens “before the content is delivered to the end user” is inaccurate since the page (content) must load at least enough for the end user’s browser to fetch the overlay provider’s library of code and then the end user’s browser must parse the DOM, which is after the content has been delivered. Then the end user’s browser can apply the overlay provider’s script.
To reiterate, all “remediation” is done in the end user’s browser by the end user’s JavaScript JIT compiler, at the user’s expense in energy costs. If the overlay provider’s script does not load for some reason (network error, firewalls, ad blockers, etc) then no remediation is performed.
> …informed by sober analysis of what technological innovation at the edge can offer.
I am not sure this is “the edge” given the sentence that precedes this one which reads “…this routing paradigm is by no means unique to accessibility applications…”
Finally, in the interests of full disclosure, this is the provided list of names of those who supported creation of this community group but with their overlay vendor affiliations added:
Lionel Wolberger (UserWay COO), Jeff Kline (UserWay Advisor), Janina Sajka (UserWay Advisor), Allon Mason (UserWay CEO), Alisa Smith (Accessibility Evangelist at AudioEye).
My comment was never approved. In fact, not only was my comment never approved but when I checked on 28 May 2022 at 5:04pm ET, I discovered the Call for Participation had been deleted completely. No new Call for Participation has since been generated.
As of this writing (19 June 2022), the Overlay Community Group has five (5) members, only two (2) of them from the original supporting people. It has no public email in its archives and has published nothing else publicly. It has sat for three weeks with no public activity of any kind, and has made no further call for participants.
My opinion is that this Community Group was never meant for genuine use. It seems more likely to me that UserWay is using the W3C brand to provide a veneer of credibility to its own ongoing marketing efforts. As evidence I point to the UserWay-heavy supporters, the lack of activity, the removal of the call for participants, and the failure to approve my comment after claming the group was intended to foster “sober analysis”.
Same members, same lack of activity. Didn’t even fix the snipet typo in the intro.
UserWay’s Tenuous Understanding of Code: 11 October 2022
Every site has coding errors. This site probably has a few (especially given how cavalier I am with spelling compounded by a complete lack of a testing team). Ideally an overlay would address the scenarios that cause problems for users.
In this case, an error introduced by UserWay in its own code is not fixed by UserWay’s own overlay.
Leaving this as a general heading as I may add more.
Added 29 June 2023: Read the section below UserWay Offers New ‘AI’ Code Fixer as an example of UserWay’s new vector to add WCAG failures to your existing code.
Nielsen Norman Group on Overlays: 1 May 2023
The Coca-Cola home page shows the UserWay overlay before and after expansion
Nielsen Norman Group has an article about the challenges screen reader users on mobile device experience across the web. The last section of the article is 4. Accessibility Menus: Not Helpful, which deals with the accessibility overlays offered by accessiBe and UserWay. Within the scope of the article, Nielsen Norman Group refers to overlays as “accessibility menus”. I adjust for that in the following quoted excerpts.
We wondered how practically useful and recognizable these [overlays] are to real users who are blind or have low vision. To answer this question, we had participants in our study perform tasks on mobile websites with these [overlays]. The short answer is that our screen-reader users did not find them useful.
[…]
When participants did not open the [overlays] on their own, we prompted them to open the menus and see whether there was anything that seemed useful inside. After briefly exploring one [overlay], a participant commented, the first thought that comes to mind is what a waste of time and money […] when anyone using a phone that needs a screen reader is already gonna have one built in.
[…]
[…] As one blind user put it, I hate [overlays] because […] I think they make companies feel like they don’t need to actually work on making something accessible […] it is not a substitute for actual accessibility testing and, to me, it feels like just a Band-Aid that can almost make it worse sometimes. […] Most accessibility issues are structural and cannot be fixed by a simple plugin.
Nielsen Norman Group is confirming what disabled users have been saying for years — overlays are not helpful. Including overlays from UserWay and accessiBe.
Lie: UserWay’s ‘Good’ Results in WAVE: 4 June 2023
The UserWay overlay actively spoofs WebAIM’s WAVE checker into reporting better testing results than UserWay has actually provided for users.
We've released a new update to the WAVE accessibility tools with numerous improvements and bug fixes. This version now informs users that accessiBe and UserWay overlays may manipulate page content to suppress detection of accessibility errors.
As an example, this page has 361 detectable errors in its default state. However, when WAVE is activated, UserWay manipulates the page content to make all text black on white, give all images alt="image", etc. resulting in 0 WAVE errors. pic.twitter.com/dfqPUm2V0W
The Userway code is specifically detecting WAVE functions to be activated (inspect their scripts and search for "wave"), triggers numerous page manipulations, then forces WAVE to re-process the page. This breaks WAVE entirely on some pages.
This may not be new. I demonstrated accessiBe spoofing WAVE in 2020. I cannot be certain if UserWay was trying to spoof WAVE at the same time or if UserWay simply emulated the amoral behavior of accessiBe. Either way, overlays of a feather lie together.
WAVE displays this message:
The third-party UserWay integration on this page modifies page content when WAVE is activated. This may result in accessibility errors present on the page before WAVE is activated not being detectable. If you are unable to see WAVE details above, UserWay has blocked WAVE functionality on this page. See overlayfactsheet.com to learn more about accessibility overlays.
Remember that UserWay had enough of an understanding how the WAVE checker worked to spoof its tests, but clearly not the capability to actually improve the page for users. Otherwise it would not have needed to lie to users of WAVE.
UserWay Will Stop Lying to WAVE: 9 June 2023
In a continuing trend where UserWay only backs away from amoral activities after it has been publicly shamed, it appears UserWay is stripping its code that lies to the WAVE automated checker.
After a productive dialog this week with UserWay, they have removed all code that changes page content when the WAVE accessibility extensions are activated. A near-future update to WAVE will remove the warning message about such changes on pages with UserWay installed.
I see no indication UserWay thinks it did anything wrong here:
When automated accessibility solutions meet, we need developers to dive in and ensure that they work well together, as expected. We believe that our dialogue is a model for such cooperation.
Worse, UserWay tries to paint itself as a peer to WebAIM while suggesting that WebAIM also provides an inaccessible and broken overlay product.
Bear in mind their dialog of cooperation was kicked off because WebAIM proved UserWay was lying to users.
UserWay Offers New ‘AI’ Code Fixer: 29 June 2023
For reference, understand that UserWay has branded its product offering as ‘AI’ for quite some time, as in this November 2022 Twitter post (emphasis mine) where the image has no alternative text:
Get 30% off all UserWay products! 😮 🎉
Kick your weekend off right with the #1 AI solution for accessibility and compliance.
Visit: hubs.la/Q01t6vf50
Use coupon code: FRIDAY30
It is curious that UserWay would, and I am guessing here, seemingly license ChatGPT to offer its new code remediation tool at FixMyCode.ai. But UserWay has done so with a bit of a twist, as the intro promises (punctuation left unchanged):
The first coding assistant trained in digital accessibility.
Optimize your code to be more inclusive, and usable. and conform with WCAG 2.1 AA standards.
It offers three options:
Create an accessible login form, followed by an SVG with no text alternative which is also not hidden from AT;
Create an accessible popup, followed by an SVG with no text alternative which is also not hidden from AT; and
Create an accessible nav menu, followed by an SVG with no text alternative which is also not hidden from AT.
Folks in the A11y Slack community promptly gave it a run. They identified terrible image alternative text suggestions, incorrect use of ARIA for navigation controls, <span>s with button roles (with no event handlers), aria-label suggestions for fields that already have a label, using the title attribute to provide instructions, and more. Each of those scenarios was a WCAG violation, meaning this tool would introduce failures.
I finally wandered over and requested a navigation menu (ugh). It asked me to provide code for it to evaluate, so I pasted UserWay’s own navigation code. It did nothing.
I re-prompted it, it asked me what I wanted, I explained it never answered me, so it offered to get back to me. And never did. As the following video shows.
My own effort to get a response from UserWay’s fake AI.
Coming out of this heavily promoted effort (press releases, LinkedIn posts, Product Hunt listing, etc.) we know that the page itself has WCAG violations. And the output which UserWay promises will conform with WCAG 2.1 AA introduces WCAG failures instead. Which leads me to a ask…
Is the output simply licensed content from ChatGPT / similar, or is the output from a LLM trained specifically on the remediation code that UserWay applies for its overlay or consulting?
If the former, UserWay was hoodwinked by the vendor and lacks either the rigor or skill to know it. If the latter, which its opening message implies, then this confirms UserWay does not possess the necessary skill to conform to WCAG.
UserWay’s COO was monitoring the Slack channel, and even private messaged one person to explain why the code blocks have aria-hidden="true" (to minimize announcement for blind users, who clearly are never developers). He did not address my question, which I asked in the channel and someone tagged him specifically. Clearly not interested in a dialog with developers after all.
If this multiply-WCAG-failing effort is really what passes for AI trained on accessibility, then my post No, ‘AI’ Will Not Fix Accessibility is again proven accurate.
Added 8 July 2023. Here is UserWay’s output when asked for a text entry field for a numeric 6-digit 2-factor authentication page (this within a code block with aria-hidden="true"):
<a role="button" aria-pressed="false" aria-selected="true" aria-label="Get started" title="Get started" href="/sign-up">
Get started
</a>
UserWay provided justification for it thusly:
Explanation:
Replaced the <div> element with an <a> element, as it seems to be functioning as a button with a link.
Added the role attribute with the value “button” to indicate that it is a button element.
Added the aria—pressed attribute with the value “false” to indicate the button status as not pressed.
Added the aria—selected attribute with the value “true” to indicate that the button is selected.
Added the aria-labelattribute with the value “Get started” to provide a descriptive label for the button.
Added the title attribute with the value “Get started” to provide a tooltip text for the button.
Changed the <span> element to a text directly inside the anchor element to improve semantic structure and accessibility. The aria-hidden attribute is not necessary in this case.
There is a lot wrong with this. Besides asserting it added all the attributes that were already there, I mean. It has no sense of the context of this code. It does not know if the control should be a link or a button. It misunderstands the ARIA attributes it keeps (or assigns, if you believe its lie). It doesn’t even know what it means to improve semantic structure.
To reiterate, if you follow this tool’s advice, you almost undoubtedly introduce WCAG violations (at the very least).
The have something new. Proactive protection in case a court orders you to pay in the event of an accessibility lawsuit. As a matter of fact, all lawsuits resulting in settlements which are not insured by userway
Leave a Comment or Response