An interactive website lets visitors do something beyond reading: adjust a calculator, configure a product, explore a demo, filter a catalogue, or watch a purposeful animation. Done well, interactivity answers a question faster than text can. Done badly, it slows the page, excludes some users and distracts from the offer. The test is simple: does the feature help a visitor decide or act?
When interactivity earns its place
Interactive features justify their cost when they replace a conversation or a long explanation.
| Feature | Earns its place when | Be cautious when |
|---|---|---|
| Calculator or estimator | Visitors always ask “how much” or “how long” and the logic can be stated clearly | You cannot stand behind the output, or it implies a firm quote |
| Configurator or product selector | There are many combinations and customers struggle to choose | Two or three options would do |
| Interactive demo | The product is hard to understand from screenshots | The demo hides what the product actually does |
| Filtering and search | The catalogue or content library is large | There are only a handful of items |
| Motion and scroll effects | Animation explains a process or guides attention | It is decoration that competes with the message |
| Quiz or guided finder | It routes visitors to the right service | It collects data you do not need |
For marketing and brochure sites, most pages work better as fast, readable HTML. Add interactivity at the specific points where it changes outcomes, and leave the rest alone. Our guide on what makes a business website convert covers the basics that interactive features sit on top of.
Progressive enhancement: start with a working page
Progressive enhancement means the core content and function work with plain HTML and links, and richer behaviour is layered on top. If a script fails, loads slowly or is blocked, the visitor still gets the information and can still reach you.
Practical examples:
- A calculator can be a standard form that submits and returns a result, enhanced with JavaScript so it updates live.
- A filtered list can be a real list of links, enhanced with in-page filtering.
- A product configurator can show the available options as readable text first.
This also helps search. Google’s JavaScript guidance says Google crawls, renders and indexes JavaScript pages, but rendering can take longer than a few seconds, and it recommends server-side rendering or pre-rendering because it helps users and crawlers that cannot run JavaScript. It also says links should be <a> elements with an href, and that client-side routing should use the History API with real paths rather than fragments (Google Search Central: JavaScript SEO basics). If your key content only appears after a script runs, you are relying on rendering to succeed.
Keep interactive components small and targeted
Frameworks such as Astro take a component-islands approach: most of the page is static HTML and CSS, and JavaScript loads only for the components that need it. In Astro, a directive such as client:visible loads a component when it enters the viewport, and client:idle waits until the browser is idle (Astro Docs: Islands). The principle applies on any platform: ship code for the interactive piece only, and defer it until needed. For how this differs from a traditional CMS, see Astro vs WordPress.
Performance: protect Core Web Vitals
Interactivity is the usual cause of poor Interaction to Next Paint. web.dev explains that long main-thread tasks, often caused by script parsing and execution, delay the page’s response to input, and recommends yielding to the main thread, doing minimal work in event callbacks, avoiding layout thrashing and keeping the DOM small (web.dev: optimize INP). The “good” INP threshold is 200 milliseconds or less, alongside LCP of 2.5 seconds or less and CLS of 0.1 or less at the 75th percentile (web.dev: Web Vitals).
Layout shift is the other risk. Interactive widgets that load late can push content around, so reserve their space in advance with a fixed height or aspect-ratio, and animate with transform rather than properties that trigger layout (web.dev: optimize CLS). Our Core Web Vitals guide shows how to check real-user results.
A performance budget helps. Agree a limit on script size for each interactive component before building, and test on a mid-range phone, not just a developer laptop.
Accessibility: design it in
Interactive features are where accessibility most often breaks. Key WCAG points:
- Keyboard access (2.1.1, Level A). All functionality must be operable through a keyboard interface, with the exception of things that depend on the path of movement such as freehand drawing (W3C: Keyboard). Test by tabbing through your widget without a mouse.
- Target size, focus and dragging (WCAG 2.2). WCAG 2.2 added a minimum pointer target size of 24 by 24 CSS pixels (or adequate spacing), a requirement that focused elements are not hidden by sticky content, and that dragging interactions have a single-pointer alternative, such as buttons to reorder items (W3C: What’s new in WCAG 2.2). A drag-only slider or sortable list fails this unless it has another method.
- Labels and states. Every control needs a name, and changes (such as a calculated result) should be announced to assistive technology, which usually means using native HTML controls wherever possible.
Respecting reduced motion
Some people experience dizziness, nausea or migraines from animation, and parallax and scroll effects are particular triggers. The prefers-reduced-motion media query detects an operating-system setting asking for less motion. web.dev recommends wrapping decorative animations in @media (prefers-reduced-motion: no-preference), removing animation for users who ask, listening for changes in JavaScript, and keeping purposeful feedback in a reduced form (web.dev: prefers-reduced-motion).
WCAG’s Success Criterion 2.3.3, Animation from Interactions, is Level AAA and informative rather than a baseline requirement, but it states that motion animation triggered by interaction should be able to be disabled, unless essential, and lists the CSS query as a technique (W3C: Animation from Interactions). Treat it as best practice: it costs little and prevents real harm.
A build checklist for any interactive feature
- Define the job. Write one sentence: “This helps visitors do X faster.” If you cannot, skip it.
- Design the no-script version first. Content and a way to contact you must work without JavaScript.
- Use native HTML controls (buttons, inputs, selects) before custom widgets.
- Set a script budget and defer loading until needed.
- Reserve layout space to avoid shifts.
- Test keyboard-only use, target sizes and focus visibility.
- Add
prefers-reduced-motionhandling for any non-essential animation. - Track outcomes. Mark meaningful actions (such as completed estimates) as events so you can tell whether the feature helps.
- Be honest in outputs. A calculator should state its assumptions, and an estimate should not read as a binding quote.
- Retest after changes, especially after adding third-party scripts.
Where Radiance Impact fits
Radiance Impact’s Technology division builds business websites, landing pages and interactive pieces, and its automation demos show how in-browser interactive logic can work. If you have an interactive idea and want to test whether it is worth building, see our Technology services or contact us.
Sources
- JavaScript SEO basics, Google Search Central
- Islands architecture, Astro Docs
- Web Vitals, web.dev (Google)
- Optimize Interaction to Next Paint, web.dev (Google)
- Optimize Cumulative Layout Shift, web.dev (Google)
- prefers-reduced-motion: Sometimes less movement is more, web.dev (Google)
- Understanding Success Criterion 2.1.1: Keyboard, W3C
- Understanding Success Criterion 2.3.3: Animation from Interactions, W3C
- What’s new in WCAG 2.2, W3C
