The button works on the developer's laptop. On your phone, the cookie banner still covers it. Both observations can be true, which is why “fixed” needs a little more detail before a website ticket is closed.
To retest a website fix, repeat the steps that originally failed on the released version, check the expected result, and try the nearby actions the change could affect. Keep the URL, device, steps and evidence together. A screenshot of the improved page is useful, but the acceptance decision should follow what the visitor can actually do.
This guide gives a business owner or marketer a practical way to review repairs without turning every small change into a full website audit. Start with the broken journey, then expand only where the change creates a reason to check more.
Turn “the mobile button is broken” into a repeatable test
Consider a fictional home-services website. Its quote page has a fixed “Request a quote” button at the bottom of the screen. A cookie notice sits in the same space. A new visitor can see part of the button but cannot tap it without first dismissing the notice. A returning visitor who already made a cookie choice never sees the problem.
The original ticket says “CTA not working on mobile.” That leaves several questions unanswered: which page, which button, which visitor state, and what should happen after the tap?
Here is a more useful repair record:
| Field | Completed example |
|---|---|
| Page and entry | Quote page, opened directly from the campaign link |
| Starting state | New browser session with no saved cookie choice |
| Device | iPhone Safari, portrait; record the actual model and browser version |
| Steps | Open page, leave cookie notice visible, try Request a quote |
| Observed failure | Notice overlaps the action; tap does not open the quote form |
| Expected result | Notice and action remain readable and usable without covering each other |
| Nearby checks | Cookie choices still work; form opens after a choice; page footer remains reachable |
| Acceptance evidence | Released page, timestamp, short recording of the same steps and the completed result |
The visitor state is the useful clue. If the reviewer tests only a browser that already remembers a cookie choice, the original bug has quietly disappeared from the test rather than from the website.
Keep consent behavior intact while repairing the layout. The point is to make the controls usable together, not to remove a choice or silently change what the visitor agreed to.
Set the acceptance condition before reviewing the repair
Describe the result in ordinary language. “The quote button opens the correct form while the cookie notice is visible” is something a reviewer can test. “Improve mobile UX” is an objective, but it does not tell anyone when this repair is finished.
Separate functional acceptance from a business hypothesis. A usable quote button does not prove that more visitors will request quotes. It establishes that the action is available in the tested circumstances. Whether the change improves qualified inquiries needs separate measurement over an appropriate period.
For a form, a useful acceptance condition might be “An invalid email shows an understandable error, preserves the other fields and allows correction.” For an article link, it might be “A direct visit and a link from the article hub both open the complete article.” Choose the condition that matches the reported failure.
If the issue involves a saved request, email or payment, agree on the receiving system and authorized test method first. Use staging and test modes where possible. A layout check does not require sending a real inquiry or placing an order. The contact form audit guide covers the additional receiving-system checks when those are in scope.
Repeat the original steps on the released version
Ask which version is ready for review and where it is available. A working preview can establish that a proposed repair behaves correctly there. It cannot establish that the production page has received it.
Open the exact URL from the record. Recreate the starting state and follow the same steps. For the quote-page example, that means a session without a stored cookie choice, the notice still visible, and the same entry link. Do not take a detour through a different page that changes the conditions.
If you cannot reproduce the original starting state, write down the limit. “Passed in desktop Chrome; iPhone Safari review pending” is more useful than an unqualified pass. A team can then assign the missing check instead of discovering it through another visitor complaint.
Use browser tools for an initial narrow-screen review, then check a relevant real device for touch, keyboard or browser-specific behavior. Chrome's Device Mode documentation describes its simulation as an approximation. A responsive preview helps expose overlap, but it does not reproduce every aspect of an actual phone.
Check the small circle around the change
A regression check asks whether the repair broke something that previously worked. Keep it tied to the change. Moving a fixed mobile bar creates a reason to inspect the cookie controls, form opening, footer and on-screen keyboard. It does not automatically require retesting every account setting.
For the fictional quote page, walk through three states: notice visible, consent choice saved, and form open with the phone keyboard displayed. Check that the action remains reachable, that focus is visible when using a keyboard, and that the form's bottom controls are not trapped behind the fixed bar.
Try a wider screen too if the same component is shared across layouts. If the repair changed a common header, repeat a small sample of pages using that header. If it changed only one article's text, a much narrower review is sensible. The useful question is which other journeys depend on the thing that changed.
The W3C accessibility Easy Checks include keyboard access, visible focus, text resizing, labels and errors. They are a starting review, not a complete accessibility evaluation. Record the specific check performed instead of calling a handful of successful clicks an accessibility certification.
Keep evidence that explains the decision
A good closing note lets someone else understand the test without repeating the conversation. Include the release or revision identifier if available, public URL, review time, browser or device, starting state, steps, result and remaining limits. Use test details you control and keep customer information out of shared screenshots.
For the quote-page example, a useful note could read:
Accepted on the released quote page. In a new iPhone Safari session, the cookie notice and Request a quote button are both visible and operable. The button opens the intended form before and after a cookie choice. With the keyboard open, the form's final controls remain reachable. Desktop Chrome check also passed. Private inquiry delivery was outside this layout ticket.
That is an illustrative acceptance note, not a report of a test we performed on a real business. Its value is the connection between the original bug, the repaired behavior and the limits of the review.
If one relevant state still fails, keep the ticket open or create a clearly linked follow-up with an owner. For example: “Still failing when the keyboard opens on the quote form. The final field is covered by the fixed bar. Frontend owner to adjust the keyboard layout, then repeat the new-session and saved-choice checks.” That note gives the next person a reproducible state and a bounded repair. Do not bury the failure under a green score. An automated audit can help identify issues to investigate; it cannot independently confirm private inbox receipt or every interaction a visitor will attempt.
Close the ticket with a clear next step
Use one of three plain outcomes: accepted in the stated test conditions, failed with reproduction steps, or awaiting a named check. Avoid “seems fine,” which transfers uncertainty to the next person without telling them what to do.
For your next website repair, add the starting state and expected result to the ticket before reviewing it. Repeat the original path on the released page, test the nearest affected controls, and save the evidence beside the decision. If you are still deciding what to fix first, use the website audit checklist before buying traffic. The goal is a visitor journey you can explain and reproduce, with any unfinished checks visible to the person responsible.