Define the question before drawing stars
A row of five stars does not tell a customer what is being rated. Specify one subject and one time frame: for example, satisfaction with the collection experience just completed. Decide whether one means very dissatisfied and five means very satisfied, or whether the scale has a different meaning. Show that interpretation near the control in both languages. If an unanswered rating is allowed, leave the initial state unselected and tell the customer that skipping is acceptable. If it is required, explain why at the point of use rather than surprising the customer after submission. The W3C guidance on labels and instructions requires enough information to know what an input expects; the graphic shape itself is not a substitute for a clear question and value labels.
Use one choice group for one answer
For a short, discrete five-value scale, native radio inputs grouped by a fieldset and legend are a practical starting point. Each option gets a visible text label such as “1 of 5 — very dissatisfied”, not an isolated star glyph. Radios share one field name and each carries a distinct value, so the browser submits only the selected choice. A decorative star can sit inside the label, but the actual input remains available to keyboard and assistive technology. W3C's rating radio example demonstrates the interaction pattern while warning that its custom ARIA code is illustrative, not production-ready. If the team instead builds custom graphics, it inherits the work of implementing names, selection state, focus and keyboard behaviour that native controls already provide.
Make focus and selection visible
A keyboard user should be able to Tab to the group, learn which value is selected, change the choice with the expected radio interaction, and leave without getting trapped. The W3C radio group pattern describes arrow-key movement among options and Space to check the focused radio; native browser details can vary, so test the chosen implementation rather than promising identical keystrokes everywhere. A focus indicator must remain visible against selected and unselected styling. Hover must not be the only preview of a choice. Keep the selected score visibly stable after the pointer moves away, and avoid submitting a form simply because a score receives focus. If the business wants immediate submission on choice, ask whether the user can review and correct the selection first.
Design for fingers, zoom and contrast
A star may look large while its clickable area is tiny. Make the visible label and its associated input form a comfortable touch target, with enough separation to avoid picking the adjacent score. Test on a narrow phone in portrait orientation and at browser zoom, where explanatory labels can wrap; do not let wrapping detach a label from its value. Use more than colour to distinguish selected, hovered and focused states, since monochrome or forced-colour displays may hide a fill change. Preserve the native radio control or an equally clear outline when high contrast is enabled. The intended score should remain visible after submission and on return to the form. These checks are about the input's actual usability, not merely whether a screenshot looks balanced.
Write labels that carry the same meaning
English “good” and Chinese 「滿意」 are not always the same response category. Draft the five anchors as a scale, then read the two versions side by side with a person familiar with local usage. Decide whether the middle value is neutral, mixed, or merely average, and keep that decision consistent in the interface, saved data and reports. Do not translate a label mechanically while changing its intensity. A user who selects the third value on either page should be answering the same question. If the feedback is optional, “no response” must remain distinct from the middle score; storing both as zero or three would corrupt later interpretation. The visible language can change, but the stable internal values and question version should remain identifiable.
Walk a real feedback journey
Suppose a customer collects an item and is asked to rate that collection experience. The form states that one is very dissatisfied and five is very satisfied, with no answer preselected. On a phone, the customer taps the label for four and sees “4 of 5 — satisfied” remain visible. A keyboard tester tabs to the same group, uses the radio interaction to choose two, then tabs to a comment field; the form has not submitted. A screen-reader tester hears the group question and each value, including which is checked. If the customer later changes to three, the submitted value and confirmation must show three. This simple rehearsal exposes broken label targets, silent state changes and accidental submissions before customers do.
Handle missing or invalid values honestly
If the rating is optional, an empty value is a valid response and the form should proceed. If required, a missing score should produce a text explanation tied to the group, with a route back to it; W3C's error-identification guidance says automatically detected errors must identify the item and describe the problem in text. Do not auto-select a middle value just to silence validation. Server-side validation must accept only the defined scale values and preserve the distinction between absent and malformed input. If a customer edits an earlier response, show which answer will be replaced before saving. For an anonymous survey, explain whether ratings are aggregated or linked to a transaction; interface copy must reflect the actual data handling rather than implying anonymity by default.
Verify the control on the shipped page
Acceptance should cover mouse, keyboard, touch, screen reader and high-contrast use on the actual page, in both languages. Check the default state, each of the five choices, changing a choice, leaving it unanswered, validation errors, submission and return to edit. Inspect the submitted value rather than assuming a lit star matches the data sent. Run the checks at mobile width and increased text size, where labels may wrap. Compare the rendered control with the W3C pattern as a guide, but do not copy its demo code as a production guarantee; that page explicitly warns about support gaps. The simplest release criterion is that every tester can state the question, identify the current selection, change it and confirm the saved answer without guessing from colour or star count alone.
Decide whether a score is even the right input
A numeric scale is only useful when the business has a clear decision to make from it. If staff need to know whether a collection was late, a direct yes-or-no question with a comment may be more actionable than a star score. If the business wants a quick sentiment measure, explain the scale and allow a comment for context. Avoid asking the same customer to rate a purchase before delivery when the intended question is about delivery quality. Establish the moment of asking, what experience is in scope, and whether the answer can be revised. These choices make the control meaningful and reduce the risk that a well-built widget collects an ambiguous number.
Do not confuse input with an average display
An input asks the customer to choose a value; an aggregate display reports existing responses. The two need different semantics. A decorative five-star graphic next to an average should be accompanied by readable text identifying the score, scale and count where appropriate; it should not receive keyboard focus as if it were an editable field. Conversely, a rating input needs controls and a selected state, not merely text saying “four stars”. Keep labels such as “Your rating” and “Average customer rating” distinct. If the business publishes ratings, the moderation and display policy is a separate editorial decision. The current acceptance test is about whether one customer can knowingly submit one chosen value.
Record a compact acceptance result
For each tested combination, note the browser, device or assistive technology, language, action and observed result. A useful record says, for example, that a tester entered an unselected group by keyboard, selected the fourth value, heard or saw the fourth value announced, and confirmed the server received four. “Accessibility checked” is too vague to reproduce. Include one negative case, such as submitting a required rating blank, and verify the text error points back to the same question. Repeat after visual changes because hiding a native radio or changing label layout can break a previously passing interaction. The record should guide a concrete fix, not become a claim that every possible device behaves identically.
Before release
- The question and every value have visible labels
- Keyboard, touch and screen reader users can choose and change a score
- Unanswered and middle values remain distinct
