Tabs, accordions, and sliders all depend on JavaScript to respond to clicks and taps — switching which panel shows, expanding a section, advancing a slide — and when that script fails to load, throws an error, or conflicts with another script on the page, the element typically still displays visually but simply stops responding to any interaction at all. This distinction between visual display and interactive behaviour is exactly what makes the fault confusing at first glance, since everything about the element looks entirely normal right up until someone actually tries to use it.
Check the browser console for a script error
Read-only. Click the unresponsive element, then open your browser’s developer console (F12, or right-click and Inspect) and look for a red error message appearing at the moment you click.
An error naming a specific script or plugin is a strong, specific clue worth having ready, even if you don’t recognise what it refers to. Trying the same interaction in a different browser is also worth a moment, since a result that changes between browsers points toward a browser-specific script issue rather than a universal one.
Tab, accordion & slider script errors
A tab, accordion, or slider on your site has stopped responding to clicks, or displays incorrectly. We isolate the script conflict and repair it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| A tab, accordion, or slider displays but doesn’t respond to clicks | This fix covers it |
| The element doesn’t display at all, not just fails to respond | A different, display-specific fix |
| A sticky header specifically is the element misbehaving on scroll | Sticky header & scroll behaviour repair, a different fix |
| A popup or modal specifically is the element failing to trigger | Popup & modal conflict resolution, a different fix |
| The block editor itself throws an error when adding this element | Block editor not loading – diagnosis, a different fix |
What you are seeing
- Tabs, accordion panels, or slider controls that don’t respond when clicked or tapped
- The element displaying its initial state correctly but never changing on interaction
- A browser console error appearing at the moment of the failed interaction
- The issue appearing after installing a new plugin or updating an existing one
- Inconsistent behaviour between different browsers or devices
Common causes
- A JavaScript conflict between two plugins both trying to control the same element type
- A caching plugin serving an outdated or incomplete version of the required script
- The script failing to load at all due to a blocked request or missing file
- A theme update changing markup structure the script depends on to function
- A duplicate instance of the same script loaded twice, causing the two copies to conflict
What we do
- Reproduce the failure and capture the specific console error involved
- Trace the error back to the conflicting plugin, script, or markup change responsible
- Resolve the conflict, correcting or removing whichever source is causing it
- Confirm the element responds correctly to clicks and taps after the fix
- Test across the browsers and devices that matter for your visitors
- Check other instances of the same element type elsewhere on the site
What is included
- The specific script conflict identified and resolved
- Testing across browsers and devices to confirm the element responds correctly
- A check for the same issue on other instances of the same element
- The pre-fix backup, kept for 30 days
Not included
- Redesigning the element’s appearance beyond restoring correct interaction
- Fixing a different type of interactive element, even on the same page
- Building a new tab, accordion, or slider feature from scratch
- Ongoing monitoring for future plugin updates reintroducing the conflict
Questions about this fix
Will updating the plugin fix this on its own?
Sometimes, though updates as often introduce this kind of conflict as resolve one already present, so we check whether an update is genuinely the safe path forward first.
Could a caching plugin really break something as specific as this?
Yes, if it's serving a script version from before a recent update, the mismatch between old script and current markup can produce exactly this kind of silent failure.
Why does the element look completely normal if it's not working?
Because the visual display and the interactive behaviour come from separate parts of the code — the markup and styling can render perfectly while the JavaScript that should respond to clicks fails independently.
Does this happen more with certain plugins than others?
Popular interactive-element plugins do tend to conflict with each other somewhat more, simply because more sites run combinations of them, though the underlying cause is the same regardless of which plugins are involved.
Will this fix affect other interactive elements on the same page?
Not unless they share the same underlying script conflict — we scope the fix to what's actually causing the reported failure, and check other instances rather than assuming they're affected.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.