shadcn.io is not affiliated with official shadcn/ui
Support Ticket FAQ Block for Svelte
A ticket form that tries to make itself unnecessary, for a form builder: common questions at the start, and at the end a form on a card in card whose subject finds matching answers as you type.
Installation
Overview
A support ticket FAQ for Svelte with Ark UI. The start column holds the title and four common questions as accordion rows, each with a chevron at its start. The end column, behind a split divider, holds the ticket form on a card in card that follows your theme: a subject, a "Maybe these help" list, a topic Select, a message and the Shine Button. Before anything is typed that list shows three more questions under "Also asked"; as the subject is typed, up to three that match its words replace them, found by matching words against seven questions, not by a model, and the copy says so. Sending shows a confirmation with a reference number in the form's own space, so the card never changes height. It's built from Accordion, Field, Input, Textarea, Select, Guides and Shine Button, with CSS transitions for the entrance and your theme's tokens for every colour. For help pages that would rather answer a question than receive a ticket for it.
FAQ
Does the form send anything?
No: nothing leaves the page. submit checks the subject and the message, shows the confirmation after a short simulated wait (LATENCY) and makes the reference number from the text, so the same ticket reads the same. Replace the body of the timeout with a call to your help desk, and show the confirmation when it answers.
How are the suggestions found?
tipsOf splits the subject into words, drops common ones, cuts each to a stem of five letters and counts how many start a word in a question or its keywords. The best three with at least one match show, best first. There's no model and no request: the same words always give the same list. Add keywords to a question to catch the words people use that the question doesn't. The list keeps a floor height, so typing never moves the form, and a polite status line says how many answers match once typing pauses.
How are mistakes handled?
Both text fields are required and the message needs at least twenty characters. Submitting with a problem shows a message under each field that's wrong, marks it invalid, and moves focus to the first one; typing in a field clears its message. The form isn't validated on each key, only on Send. The topic always has a value, so it can't be wrong.
How does the topic Select work?
TOPICS holds the labels and values. The Select has an accessible name ("Topic") that matches the label you see above it.
It reads a list collection built from TOPICS and gives its value as an array.
Are the closed answers in the page's markup?
Yes. The Accordion takes lazyMount={false} and unmountOnExit={false}, so every answer renders from the start, hidden until its question opens.
The suggestions list isn't in the markup until a subject matches, because it's built from the subject.
How does it work with a keyboard and a screen reader?
The questions are buttons in h3 headings; the fields have visible labels; errors are tied to their field. Tab goes through the questions, then the subject, topic, message and Send. After a successful send focus moves to the confirmation, and "Open another ticket" empties the form and puts focus back in the subject. One polite status line says "Sending your ticket…" and how many answers match.
The Up and Down arrows also move between questions in the list.
How does it fit on a phone?
The header and the four questions come first, then the form's card under its own rule with + marks, so a visitor reads the answers before writing. The suggestions area reserves room for three matches, so nothing jumps while typing, and nothing scrolls sideways at 320 pixels.