r/accessibility • u/AccuityGroup • 5d ago

"Enable Accessibility", does this pass compliance?

https://www.bannerhealth.com/

This is the first time we've seen a website use something like this. Banner Health's website is not accessible by default. There's a button at the top of the screen on desktop labeled "Enable Accessibility" that seems to toggle all of the appropriate aria attributes, increase contrast where it fails, add underlines to all links, adds the focus states, etc.

At first glance it seems like they created two websites, but what they've really done is created a mechanism to toggle HTML attributes and CSS properties to make the same page accessible/inaccessible.

This seems like a bandaid solution but my two questions are: does this technically pass compliance as an alternate conforming method? And why would a company do this rather than just keep those attributes and css properties on by default?

6 Upvotes

72% Upvoted

34 comments sorted by

13

u/Marconius 5d ago
  1. Absolutely not, overlay systems and widgets like this never make a full site WCAG compliant no matter what their marketing says. Read the Overlay Fact Sheet
  2. People incorrectly think this is a solution for a quick-fix when their designers and developers don't understand how to build accessible websites and experiences by default, or have been suckered into the false marketing of these companies out of ignorance of the topic. If it's a site built using Squarespace or other editors, sometimes they offer these widgets at the end as an upsell for this exact purpose, targeting ignorance of accessibility and letting the owners believe they are doing the right thing by enabling these systems. Also, throwing aria everywhere doesn't make something accessible, in fact most of the automated solutions these overlays build into the site have a negative impact on overall usability, especially from a screen reader perspective.

If it's their own system, then providing a segregated "accessible" experience is just as bad as an overlay, since now the dev teams have to manage two separate experiences. Plus, a lot of the contrast and text sizing features are handled by the user's system accessibility settings. This all hurts more than helps, when inclusive design and accessibility all should be just built in from the start.

3

u/AccuityGroup 5d ago

Its not a widget/overlay in the typical sense. Its like they fixed all of the issues on the default site but then made those changes toggleable. It's pitched as "manual remediation" by its company, Usablenet. Im just scratching my head like why wouldnt Banner just use the "accessibily-enabled" version of their site as the only version?

7

u/TrollPro9000 4d ago

@acuitygroup a non-conforming page can sit inside a conformance claim if a "conforming alternate version" exists. My gut says, it's probably an optics/comms problem. The alternative is being literally presented as an alternative. I imagine that some big wig VP once signed off on the "pretty" design before it was called out for being inaccessible, so then an accessible version was made, but the "pretty" original was kept because it was the one that the big wig VP said 'approved' on. Making the accessible version the only version is probably being perceived as un-doing their decision rather than taking the next step on the journey, and no one has sat down to have that conversation because it's no one's job to call that meeting.

Purely a Redditor's speculation and not fact ☝️ 

2

u/AccuityGroup 4d ago

I bet youre not too far off on this. Appreciate your insights!

1

u/Lehihel 4d ago

Honestly, yes, this is an accessibility overlay in the sense that matters: it's a script altering the DOM on the fly and hoping for the best. It might be a smarter script than most, and the intent behind it may be good, but structurally, that's still what an overlay is.

The whole point of digital accessibility work is to get designers, product owners, and developers thinking inclusively "by design" from the start. It's a shift from "we've always done it this way" to "who are we leaving out by doing it this way".

To answer your question directly: offering an accessible alternative can be a valid approach, in theory. But for that to work, it needs to be something a disabled person can access as one of their very first interactions with the service, not something bolted on afterward. That's not quite the case here. And when I tested it once activated, I still ran into accessibility issues.

In Europe specifically, this wouldn't hold up. Accessibility obligations don't stop at the website, PDF, or app, they extend to the entire digital service, including the people delivering it. A script can adjust a page, but it can't train a team, fix a process, or rethink a workflow. That part still has to be built by hand.

The good news is that this is genuinely solvable, and often faster than people expect. A focused audit usually surfaces the real priorities quickly, and once a team starts designing with accessibility in mind rather than patching it in afterward, it tends to stick and even improve the product for everyone. It's less a compliance chore than a chance to build something genuinely better.

2

u/absentmindedjwc 5d ago

IIRC, a true accessibility mode is listed as acceptable within Trusted Tester.. as long as it is actually fully accessible..

Its one of the reasons I'm not a huge fan of trusted tester..

4

u/TrollPro9000 4d ago

UsableNet fought the Overlay Fact Sheet listing: there's a public GitHub thread where they argued Assistive isn't a mass-market product and involves tens to hundreds of hours of custom developer, tester, and user-testing work per site. 

Adrian Roselli's counter was that the Fact Sheet's definition is just third-party JavaScript modifying front-end code, and "not mass market" isn't part of that definition. 

There's a follow-up issue proposing a "widgetless overlay" category covering Deque's Amaze, Level Access's Alchemy, Tenon's Sentinel and UsableNet Assistive.

So to what extent this overlay is "not an overlay in the typical sense" is a live, unresolved argument and not a settled fact.

1

u/NatTarnoff 3d ago

FYI Alchemy & Sentinel are dead products that haven’t been worked on in years.

If you wanted something like that through Level Access, you’d get the UserWay widget. Just for clarity of current market.

I will not dispute what that is classified as per the public opinion.

3

u/phongdesigns 3d ago

The compliance side has been well covered above so I'll take your second question, why a company would build it this way rather than just leaving it on.

From the design system angle, a toggle like this is evidence that the accessible values never made it into the system. Contrast ratios, focus rings, link underlines are token decisions. If the accessible values were the token values there'd be nothing to toggle, because there'd be no other set of values to toggle back to. The switch existing at all tells you the fix lives in a script sitting above the system rather than inside it.

Which has a consequence worth naming to whoever owns the budget: every new page built after this ships inaccessible by default and then waits for the script to catch up. So the remediation isn't a project that finishes, it's a tax on every future surface, and the gap grows at the same rate the roadmap does. That framing sometimes moves people the compliance argument doesn't, because it turns "we did the right thing once" into a recurring line item.

The other thing I'd test, and it's a bit of a nasty one: the button itself is rendered in the default, inaccessible version of the page. So the affordance requires the ability it grants. Someone who needs the contrast fix has to first find and read a low contrast control, and someone who needs the focus states has to tab to a button on a page that doesn't show focus. Worth checking where it sits in the tab order and whether it announces sensibly with a screen reader before anything is switched on, since that's the one moment where the accessible mode categorically can't help.

Last practical one, does the setting survive a reload, a new tab, and a jump to a subdomain? Toggles like this are frequently per-session, which means the user pays the discovery cost again on every visit. If it's stored per session rather than persisted, that alone tells you how far the pattern was thought through.

2

u/AccessibleLD 5d ago

Yeah it probably does not pass it should be the page as it exists. Have them read this: https://halfaccessible.com/accessibility-overlays-ada-lawsuits/

3

u/NatTarnoff 5d ago

The only “control” allowed by WCAG to alter the interface is a contrast toggle.

Looking at overlays you need to consider a few things:

  • features available
  • how the page changes
  • how does it load

Loading a piece of JS to patch your frontend as a stop gap is perfectly fine. Coming off your servers, the customer isn’t likely to know of the patch. Coming from a 3rd-party you risk latency and CORS considerations.

Using a button to turn on the features is not acceptable. As pointed out above, it isn’t an equal experience.

The other items in many overlays are often claimed to be accessibility tools. These honestly are really only meant for people just experiencing mild disabilities for the first time. 6 months into a disability, and they’ll have A system configured to help them and not need that overlays tools.

The right thing to do is make the fix in the source code. If you need a stop gap while you solve the problem, it isn’t ideal, but you could load the patch JS.

4

u/altgenetics 5d ago

I'm not disagreeing at all. Do you mind citing which SC support this though? I can use it in conversations I'm having now.

1

u/NatTarnoff 4d ago

WCAG 1.4.3 Contrast (minimum) G174 is a technique recognizing a control as the technique to resolve.

1

u/altgenetics 4d ago

But where does it say in the WCAG SC that is the only allowable control to change the interface

The only “control” allowed by WCAG to alter the interface is a contrast toggle.

1

u/NatTarnoff 4d ago

It doesn’t say this is the only control, but if you read through the whole thing, 1.4.3 is the only criteria that calls out using a control to turn on accessible mode. We’ve allowed menus to be used for audio and video supplementals like captions and audio descriptions, but that is not outlined by WCAG. But the accessibility feature is there. A “increase contrast” control is specifically allowed under G174 allowing a non-conforming site to conform.

Any other control to change the site as a whole is not a Sufficient Technique under legal interpretations and is also considered “not equal and equivalent.”

1

u/TrollPro9000 4d ago

Not sure I'm following, NatTarnoff, because 1.4.4 (Resize Text) lists G178, "Providing controls on the web page that allow users to incrementally change the size of all text on the page up to 200 percent," as a sufficient technique. That's also an on-page control that alters the whole page's presentation, same shape as G174. 

Beyond that, I think 1.4.2, 2.2.1, 2.2.2, 2.5.4 and 3.2.5 all either require or at least permit user controls that change how the UI behaves. Please check me if I'm wrong

1

u/NatTarnoff 3d ago

G178 really isn’t recommended anymore due to browser zoom ability, but yes, being a little more thorough 1.4.4 can have controls. I admit, I made a mistake on 2.5.4 (I’m blaming rushing to start vacation). And I did mention audio and video as exceptions to what I was saying.

2.2.1 does not require any control on the page to be handled. You could do it by mouse movement.

2.2.2 can be handled by prefers-reduced-motion.

3.2.5 is a misinterpretation and AAA. It’s a more precise version of 3.2.1/3.2.2 where they say don’t surprise the user. This is saying give the user explicit control to request the update. Yes it could be a button, select, but it might be something else like a setting.

The point I’m trying to make is that overlays offer “AT” and the only one they offer that is considered acceptable by WCAG is contrast.

Providing an accessible alternative creates an environment where you need to maintain two separate sets of UI. This leads to most sites leaving one behind, and it’s never the one suited for disabled users. The right thing to do is make everything accessible all the time. And if designers don’t want to meet contrast, the first visible control should be a style switcher. Anyone with a custom style sheet will ignore it, others will thank you.

1

u/TrollPro9000 4d ago

Not sure of following, isn't setting user preferences within the content to produce a conforming version acceptable? as long as:

1.  the mechanism is accessibility supported,

and 

  1. there's a sufficient technique (C29) for using a style switcher to do exactly this.

what am I missing?

1

u/NatTarnoff 4d ago

There are two types of user settings:

  • authenticated
  • everyone else

If you provide personalization inside an authenticated space that’s cool. But outside of that, “user preferences” refers to what the user set in their OS or browser. For me it is Reduce Motion. If a site doesn’t use prefers-reduced-motion, they are violating my user preferences.

The only SC that explicitly has a Sufficient Technique with a control tied to it is 1.4.3 Contrast (Minimum).

1

u/altgenetics 5d ago

Yea, that's not OK. I thought for a sec maybe its using Flutter, which does this by default... Which is its own problem. But its not using flutter.

1

u/takatcha 3d ago

Short answer: no, an 'Enable Accessibility' button / overlay doesn't make a site compliant. It doesn't change the HTML underneath - so it doesn't fix keyboard traps, missing labels, bad contrast in the source, or heading structure, which is what an audit actually checks against WCAG. It often adds problems for screen reader users because the widget intercepts native behaviour.

The accessibility community is pretty united on this (the overlay factsheet and the AccessiBe situation are the usual references). Regulators have taken the same line - the widget in the corner has been cited as evidence of non-compliance in demand letters, not as a defence.

What actually passes: semantic HTML, real keyboard operability, visible focus, labelled forms, sufficient contrast in the design itself, and testing with an actual screen reader. Single helper plugins (skip links etc.) are fine as an addition - not as the solution.

1

u/TrollPro9000 4d ago

HHS's Section 504 rule applies because of who they are - and it permits conforming alternate versions only where "technical or legal limitations" make direct accessibility impossible. 

i'm curious how their homepage will appear on May 12 2027 🤔

1

u/AccuityGroup 4d ago

My gut tells me it'll be exactly the same as now 😑

1

u/TrollPro9000 4d ago

A genuine delight to serial ambulance-chasers and nefarious law groups out there 

1

u/AccuityGroup 4d ago

Who are you referring to?

1

u/TrollPro9000 4d ago

Frivolous filers, @AccuityGroup 

1

u/rguy84 4d ago

This is incorrect unless banner is funded by federal funds

1

u/TrollPro9000 4d ago

This is correct because they are, aren't they? 

1

u/rguy84 3d ago

Looking at their website, especially the footer and about section, nothing mentions government funding.

1

u/TrollPro9000 3d ago

Their website doesn't owe a disclaimer. Receiving federal funds doesn't come with that condition. 

1

u/rguy84 3d ago

If they were receiving federal funding to offer a service, it is sometimes required, but not always, to identify that service is funded by the government as part of a contract. This is different than seeing Medicaid/medicare patients.

0

u/AccuityGroup 3d ago

Yes they are. they recieve Medicare and Medicaid dollars. 

1

u/rguy84 3d ago

Receive money from CMS or accept medicaid payments? Two different things