A campaign manager wants to add a sticky offer to the pricing page. The request sounds reasonable. Then someone opens that page on a phone: a consent panel is already open, chat sits in the corner and a feedback tab follows the scroll. Which control gets the space, and which visitor task matters first?
That is the job of a website clutter audit. You inventory the controls that stay on screen or appear over the page, test them together on important journeys, and make a decision for each one. The aim is not a website with zero widgets. It is a page where a person can understand, use and finish what they came to do.
This article turns the founder's argument about website clutter into 15 checks. Use the first pass to find obvious conflicts. Allow more time for keyboard testing, performance measurement, privacy review and changes that need specialist approval. A quick look is a starting point, not an accessibility or legal sign-off.
Make one inventory before judging any tool
Include the normal page and the states people actually see. A chat launcher may occupy one corner until opened. A consent panel may cover the lower half of a mobile screen. A promotional bar may appear after ten seconds. A feedback tab may sit above an important form field. “It looks fine in the design file” is not evidence about those combined states.
Start with two or three valuable journeys: for example, arrive from an ad and check a product claim; compare plans and ask a question; complete a form. Repeat them on desktop and a narrow phone, as a new and a returning visitor where saved choices change what appears. If the page has a mobile keyboard, zoom or orientation state that matters, test those too.
Give each control one row in a shared sheet. You can copy these fields:
| Record | What to write down |
|---|---|
| Page and visitor job | “Pricing page; compare two plans before enquiring” |
| Control and owner | “Chat launcher; Support team” |
| When and for whom | “Appears after 10 seconds on all devices for new visitors” |
| States to capture | “Closed, expanded, dismissed; screenshots or short screen recording” |
| Evidence of value or harm | “Questions answered, task notes, obscured controls, qualified enquiries” |
| Decision and due date | “Fix opening behaviour; Support owner; review after the next release” |
If you do not know a field, write unknown. Do not treat an unknown trigger, owner or data destination as a pass.
Run the 15-point EDGE audit
EDGE is a Barrava working aid: Essentiality and evidence, Duplication and distraction, Geometry and operability, Engineering and governance. It is a way to make team decisions visible, not a validated industry score, a WCAG certificate or a privacy audit. Mark each check pass, risk or unknown, and add the screenshot, observation or measurement behind the mark.
E — Does this control earn its place?
1. Name the visitor's job. “Help people find support during checkout” is testable. “Increase engagement” does not say who needs help or what useful outcome follows.
2. Check page fit. A live-chat route might help on a complex support page and interrupt a short campaign landing page. Record where the control appears, not just where its owner intended it to appear.
3. Look beyond the control's own clicks. A promotion may attract taps while fewer people finish the original page task. Choose a useful outcome such as a qualified enquiry, a completed booking or a resolved support question, then inspect that alongside interactions with the control.
4. Find the owner and expiry. Write who can change the control, who can turn it off, and when its purpose should be reviewed. Campaign controls especially need an end date or a deliberate renewal.
D — Are several controls fighting for the same moment?
5. Find duplicate routes. A floating “Contact” button, chat launcher and sticky “Ask us” action may be three versions of the same invitation. Keep different underlying services where needed, but ask whether their entry points can be clearer.
6. Check the page's main action. With every tool visible, can someone unfamiliar with the page still say what the primary next step is? Ask them to point to it; do not coach them.
7. Check the timing. A help option available on request is different from chat expanding before the visitor has read the headline. Google's guidance on intrusive interstitials and dialogs cautions against blocking access to content. Necessary notices have their own requirements; do not remove a consent choice just to make a campaign prompt fit.
8. Check dismiss and return. Can a person close an optional prompt, continue the task, and reopen help if needed? Record whether a dismissed promotion reappears on the next page or every visit.
G — Can people still use the page?
9. Check overlap in the full state. Open consent, chat and the promotion together on a narrow screen. Note any covered form field, page action, navigation control or piece of content. Test the on-screen keyboard and phone safe area where they change the available space.
10. Use the keyboard. Tab through the page and watch where focus goes. WCAG 2.2 Focus Not Obscured (Minimum) requires that a focused component is not entirely hidden by author-created content. That is a minimum; a button that is technically one pixel visible may still be awkward to use.
11. Check touch targets and labels. Can someone tell what each icon will do and tap it without hitting its neighbour? WCAG 2.2 Target Size (Minimum) sets a 24 by 24 CSS-pixel minimum for pointer targets with defined exceptions, including spacing. Aim for comfortable operation in the real layout rather than treating a minimum measurement as the whole answer.
12. Repeat after layout changes. Test zoom, larger text, orientation changes, expanded chat and the bottom of the page. The last form button or footer link should still be reachable. For a persistent mobile bar, this layout guide explains when to reserve space instead of placing an overlay above content.
E — Is the control governed and measured?
13. Check loading cost. Record the extra requests, JavaScript and response time for each third-party tool on a representative mobile page. Do not assume a vendor-hosted script is free to the visitor's browser. Compare a baseline with the control enabled and disabled where you can.
14. Watch for movement on load. If a late banner pushes the page down while someone is trying to read or tap, record it. web.dev's Cumulative Layout Shift guidance explains how content injected without reserved space can shift the page. A fixed overlay might avoid that particular metric yet still hide content, so inspect both movement and obstruction.
15. Check data and rollback. Who handles consent, personal data, vendor failure, change approval and turning the control off? A tidy interface does not make those responsibilities disappear. Confirm the specialist owner before combining entry points.
Turn marks into decisions: a mobile pricing-page example
Imagine the illustrative page from the opening at a 390-pixel width. The consent panel is open, chat is collapsed, a feedback tab follows the scroll and a sticky promotion offers a different plan. The visitor's task is to compare plans and decide whether to enquire. The first audit finds that the comparison table is partly covered and the lower “Ask about this plan” action is hard to reach.
The group does not begin by deleting every control. It works through the conflict:
| Control | What the audit finds | Decision to test |
|---|---|---|
| Consent panel | This visitor needs a clear choice; it occupies most of the lower screen | Keep and fix any focus or overlap problem with the consent owner; do not weaken the choice for the promotion |
| Chat launcher | Support is useful, but its panel opens over plan details | Fix its timing or opening behaviour; keep help findable on request |
| Feedback tab | It asks for a response before the visitor has compared anything | Move it to a later, relevant point or retire it from this page |
| Sticky promotion | It competes with the plan comparison and repeats another offer | Pause or retarget it while the team tests whether the main task becomes easier |
These are proposed actions for an example, not a promise of better conversion. After the changes, repeat the original task on mobile and desktop. Can people read the plan differences, use the consent controls, open help if they need it and reach the enquiry action? Compare qualified enquiries and task observations before crediting the redesign. If the plan information itself is unclear, reducing edge clutter will not fix that content problem.
The decisions fall into four useful verbs: keep a control that has a distinct job and works in context; fix a valid control's timing, layout or measurement; consolidate entry points when the specialist services behind them remain correctly owned; retire a duplicate, expired or unsupported prompt when no obligation requires it. Put an owner and review date beside each verb.
Apply the same test to Barrava
Barrava offers one configurable website toolbar for selected actions. In its current product, modules appear in a chosen order in a docked or floating bottom bar. That can give teams a clearer place for a call to action, search or feedback. Keep the site's existing chat and consent controls in the same page audit, even when Barrava handles other actions. Barrava does not replace those specialist providers, the website's main navigation, an analytics system or the team's legal review.
A single bar can still be crowded or cover something important. Put Barrava itself in the inventory. Test the ordered actions against the visitor's task, the mobile layout and the other tools already on the page. If two actions are enough, do not add a third merely because there is room in the Admin screen.
Start with the highest-value page and one shared sheet. The useful output is not a perfect score. It is a short list of visible problems, evidence for each one, and named people who can make the page easier to use.
