Testimonial Block Builder

A testimonial works for one reason. The reader believes it. A stranger cannot test your product before buying it, so they borrow the experience of someone who already did, and the quote on your page stands in for that experience. That is what makes a testimonial persuasive, and it is also what makes a false one harmful. It is evidence, and evidence that was invented is a lie told in somebody else’s voice.

The rest follows from that idea. If a quote is evidence, it must come from a real person who said it. If it is borrowed, the person must have agreed to lend it. If something changed hands, the reader deserves to know, because a payment changes how much the evidence weighs. And if it is somebody else’s words, the page should say so in a way that software as well as people can read.

What the rule actually says

In the United States the clearest statement is a Federal Trade Commission rule, 16 CFR Part 465, the Rule on the Use of Consumer Reviews and Testimonials. The Federal Register notice that published it gives the effective date as October 21, 2024. It also names one practical change: the notice says the rule will enable the Commission to seek civil penalties against violators. Everything below is a reading of US rules, and it is not legal advice. Other countries have their own rules, and some are stricter.

The rule defines a consumer testimonial as an advertising message that people are likely to believe reflects the opinions or experience of a consumer who actually bought or used the product. Section 465.2 then makes it a violation for a business to write or create one that misrepresents that the person exists, that they used the product, or what their experience was. A business also may not publish a testimonial it knew or should have known was false in any of those ways.

Read that list slowly and the boundaries become clear. A testimonial written by the marketing team and signed with a plausible name is out. So is a real customer’s name attached to words they never wrote, and so is a real quote stretched to claim an experience the customer did not have. The older Endorsement Guides, 16 CFR Part 255, say the same thing in general terms: an endorsement must reflect the honest opinions, findings, beliefs or experience of the endorser, and when an advertisement says the endorser uses the product, they must have been a genuine user when they said so.

In short, there are three things a testimonial cannot be: invented, borrowed without consent, or stretched past what the person actually said and experienced.

The Guides add a detail that matters for anyone editing a quote. An advertiser need not use an endorser’s exact words unless the advertisement represents that it is presenting their exact words, and quotation marks are the guides’ own example of such a representation. A testimonial block is nothing but quotation marks. So the words inside it should be the customer’s words, and any shortening should be done with their agreement and without changing what they meant.

None of these rules uses the word permission the way a small business would. But a quote you have no right to use is a quote you cannot defend, and a record of who agreed, when and how is the simplest proof that the person exists and said what you print. That is why the builder asks for a private permission note with every quotation. The note lives in your project file and in a permissions log you can download as a spreadsheet. It never appears on the page. Photographs and logos need the same care: a portrait shows a person and a logo belongs to its owner.

The second question the builder asks is whether the person was paid or given anything. The Endorsement Guides call this a material connection. Section 255.5 lists money, free or discounted products, other benefits such as the chance to win a prize, and business, family or personal relationships. When such a connection might affect how much weight a reader gives the endorsement, and the audience would not expect it, it has to be disclosed clearly and conspicuously.

The new rule defines that phrase in detail. A visual disclosure must stand out by its size, contrast and placement. In an interactive medium such as a web page it must be unavoidable, and the rule spells out what fails: a disclosure is not clear and conspicuous if a reader must click a link or hover over an icon to see it. Section 465.5 applies the same test to testimonials from a business’s own officers, managers, employees and agents when the relationship is not otherwise clear.

So the disclosure in a generated block is a plain sentence inside the card, beside the words it qualifies, styled like body text. It is never a tooltip, an asterisk or a footnote. It appears exactly when the “paid or given” answer says something was given, and it disappears when the answer is no. A tool cannot know the truth of that answer. It can only make the honest answer easy to give and impossible to hide.

Marking up somebody else’s words

The HTML Standard has an element for exactly this. The blockquote element represents a section quoted from another source, and the standard is specific about attribution: if there is any, it must be placed outside the blockquote. The figure element groups self-contained content with an optional caption, and figcaption is that caption. Put together, a testimonial becomes a figure holding a blockquote with the customer’s words and a figcaption with their name, role and organisation. A screen reader, a search crawler and a reader skimming the page all get the same answer to the question of who said what.

There is one tempting mistake. The cite element sounds right for a person’s name, but the standard says it represents the title of a work and states plainly that a person’s name is not the title of a work. Names therefore go in an ordinary span inside the figcaption. Ratings follow the same logic of saying things in words. A rating line appears only when the customer actually gave one, and it reads as text, such as “Rating given: 4 out of 5”, rather than a row of decorative stars that some readers cannot perceive.

Layout is where good markup can quietly go wrong. A grid places cards in rows, reading left to right, which matches the order of the list in the code. A masonry look is usually built with CSS columns, and the Multi-column Layout specification fills columns sequentially: content continues in the next column only when the first one is full. The order a screen reader follows is the order of your list, down the first column and then the next, while a sighted reader may scan across the top row first. Neither order is wrong, but you should know which one you chose.

Why carousels that move by themselves fail people

The most familiar testimonial widget is the rotating carousel, and it is the one most likely to fail its readers. The W3C carousel tutorial puts the problem plainly: users must be able to pause carousel movement because it can be too fast or distracting, making text hard to read. The Authoring Practices pattern describes the screen reader version of the problem. A listener reads one slide, asks for the next element, and hears something from a different slide that rotated in underneath them.

WCAG 2.2 turns this into a requirement. Success Criterion 2.2.2 says that moving content which starts automatically, lasts more than five seconds and is shown alongside other content needs a mechanism to pause, stop or hide it. The Authoring Practices pattern adds the details of a good one: a rotation control that comes first in the tab order, rotation that stops when keyboard focus enters the carousel and does not restart on its own, and rotation that stops while the pointer hovers over it.

That is why the stepper this tool writes does not move by itself unless you switch that on. It is a horizontal scroller using CSS Scroll Snap, so even with no script at all every card can be scrolled to and reached with the Tab key. The optional script adds previous and next buttons. If you also ask for automatic steps, it writes a Pause button first, stops on hover and on focus, waits at least five seconds between steps, and never starts for readers whose system asks for reduced motion, a preference Media Queries Level 5 defines as a request to minimize non-essential motion.

Many page builders make the rotating version the default. It should be the exception, chosen on purpose, with its off switch written before anything else.

The temptation of stars in search results

Review stars beside a search result are attractive, and Schema.org offers a Review type, described as a review of an item such as a restaurant, movie or store, with properties for the item reviewed and the rating. It is easy to assume that wrapping your testimonials in that markup will put stars next to your name.

Google Search Central closed that door in September 2019. Its post “Making Review Rich Results more helpful” called reviews self-serving when a review about an entity is placed on that entity’s own website, whether in its own markup or through an embedded third-party widget. Review rich results stopped appearing for the LocalBusiness and Organization types in that situation. The current review snippet documentation still lists those types only for sites that capture reviews about other businesses or organizations. So the builder writes no review markup at all: on your own site, about your own business, it would describe something search engines say they will not show.

A worked example, and what a tool cannot do

Open the tool and the first thing you see is a finished block of four example testimonials, each badged EXAMPLE. Every one of them has seven text fields that hold example values: the words, the name, the role, the organisation, who agreed, the date and the permission note. The first also carries an example logo drawn in code. Four times seven plus one is 29 fields, and the status line says exactly that. Replace 28 of them and the export stays locked, with the last one named. Replace the 29th, and give every quotation a real permission date that is not in the future, and the download unlocks.

The colours are checked the same way. WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for ordinary text and 3:1 for the parts of a control that identify it. The ratio uses the relative luminance formula the standard defines, which gives #777777 on white about 4.48:1, just short, and #767676 about 4.54:1, just over. With the default accent the builder’s own words on cards measure about 18.4:1 in light colours and 15.9:1 in dark.

What the tool cannot do is know whether your customer exists, whether they agreed, or whether you gave them anything. It records what you tell it and makes the honest version the easy one. It cannot make a fabricated quote truthful, and it cannot tell you what the law requires where you sell. It writes the markup properly, keeps your records beside it, and leaves the evidence to you.