An Annual Subscription to the Same Defect

Illustrative scenario. Records, events and arithmetic are constructed examples, not findings about a named organisation.

Ticket A11Y-184 closes on Friday. On Monday, an editor publishes the same unnamed button on another page. The repair changed the rendered instance. The component still permits the label to be omitted.

The audit has acquired a renewal date.

Publishing cannot stop while every template and interaction is rebuilt. The team fixes reported defects while keeping applications, bookings and service information available. Some controls come from suppliers whose release schedules the institution cannot dictate.

With a fixed release calendar, several publishing teams and a supplier contract that separates component changes from content support, the people repairing individual pages have chosen work they can complete now over promises that depend on approvals they cannot issue.

They made the page work.

A training session cannot make a field mandatory. A poster about inclusion cannot supply an accessible name to a control. The people doing the repairs know this because they have corrected the same omission in several places.

They are not short of concern. They are short of a publishing path that preserves the correction.

You have seen this queue.

Take thirty instances of one defect, twenty minutes per correction and four release cycles. That is forty staff-hours spent applying the same repair, before retesting or coordination.

At an assumed A$100 loaded hourly cost, the total is A$4,000 for that defect alone. These are illustrative quantities. They do not establish the incidence or cost in any particular organisation.

The queue records productivity.

Each closure demonstrates activity. Unless the source component changes, the next publication can reproduce the condition that generated the ticket. The reporting method counts recovery and leaves recurrence elsewhere.

The CMS supplier owns the component. The agency inherited it. The editor selected an option the interface offered. The audit arrived after the release scope was agreed.

These are material facts. A third-party control may require escalation rather than a local patch. Budget and access can restrict which repairs the team can make.

The supplier boundary deserves examination. It also supplies a place to leave responsibility indefinitely.

No.

You closed the tickets. You left the mechanism that makes them.

Trace the defect from the published page to its template, component and authoring rule. Establish whether the correction belongs in code, content, validation or a supplier release. Name the owner and test the publishing path again.

Automated checks can cover some conditions. Keyboard and assistive-technology testing still require attention to the actual interaction. A closed ticket proves only the work its acceptance criteria describe.

Your team’s care has become a recurring substitute for a rule the system does not enforce.

The next audit will find the same care at work.