Stark’s New Issue Tracking Can Help Agencies Triage Accessibility Fixes
An accessibility audit can leave an agency with a familiar problem: a list of findings, several client assets, and no obvious place to start. Stark’s October 1, 2026 update adds issue labels that give teams more context as they review findings, along with support for adding multiple assets of the same type to one project.
The labels won’t repair a page or choose the most urgent task. They do offer a way to sort what a team sees in the asset detail view, which can make a growing audit easier to review. For agencies balancing more than one client deliverable, that extra context can help turn a long findings list into a more useful conversation.
A clearer view of what needs attention
Stark’s October 1 release notes introduce three labels in the asset detail view: new issues, stale issues, and duplicate issues. Each describes a different kind of context around a finding.
New issues are findings that weren’t present in previous scans. That gives a team a way to spot what has appeared since an earlier review. A newly surfaced issue may deserve a prompt look, especially if it affects a key page or a shared part of a design. But “new” describes when it appeared in scan results, not how serious it is. A label isn’t a substitute for judgment, which remains stubbornly human.
Stale issues are findings that have been around for a while. Teams can change the stale time in the Governance tab, so the cutoff can reflect how they want to review older work. That may help an agency bring persistent findings back into view rather than letting them blend into a familiar report. The label says an issue has lingered; the team still needs to decide why it remains open and what should happen next.
Duplicate issues are findings that appear on multiple pages within one asset. Stark gives a page footer as an example. If the same issue shows up across several pages, a shared component might be involved. That’s a useful lead for investigation, not proof that every instance has one cause or will be corrected by changing a single element.
Use the labels to sort the work
An agency might begin a review by looking at new issues, then compare those findings with the previous scan and check the pages where they appear. The aim isn’t to treat every new item as an emergency. It’s to see what has changed and decide whether a new finding affects an important task, appears on a prominent page, or merits a closer check before other work continues.
Stale issues can prompt a different discussion. A team could review older open findings during a client check-in or before preparing the next round of recommendations. Some may still need a fix. Others may need context: perhaps a change is waiting on a design decision, or the team needs to confirm whether the finding still applies. The label makes age easier to spot; it doesn’t explain the history for them.
Repeated findings offer another useful path. If a duplicate issue appears across pages that use the same footer, the agency could inspect that shared component and see whether addressing it would help across those pages. If the pages don’t share a component, the repeat may instead point to several similar instances that need separate attention. Either way, the label gives the reviewer a reason to look for a pattern rather than assume one.
These are ways a team could use the labels, not an automatic priority system. New, stale, and duplicate describe issue history or where a finding appears. They don’t, by themselves, rank severity, assign an owner, or make the correction. A short list organized by useful clues can still save time in a review meeting, even if it doesn’t turn the meeting into a magic trick.
Keep more client assets in one project
The October 1 update also lets teams add multiple assets of the same type to one project. Stark’s example is a project containing several design-system files. Teams can also add the same file or URL more than once with different pages, and rename assets to make them easier to identify at a glance.
For an agency audit, that opens up a more flexible way to arrange related material. A team working across several design-system files could keep those assets within a single project rather than having to treat each as the only asset of its type. When the same URL is added with different pages, asset names can help distinguish those entries during review. Names such as “Checkout flow” and “Account settings” are easier to read than a row of identical links.
Clear labels on the assets can also make issue review less confusing when a team moves between files or page groups. A duplicate finding still refers to multiple pages within one asset, not automatically to the same finding across every asset in the project. Keeping that distinction in mind helps the team follow a clue without assuming the product has already connected every instance across client work.
For agencies, the practical value is in having more ways to group and identify audit material in a project. It can support work that covers several related assets, while asset names provide a quick visual cue about what each entry represents. It doesn’t, on its own, create a full client-management system or tell a team how to structure every engagement.
A practical addition, still taking shape
Stark says it plans to expand these issue details, making this an early addition rather than a finished prioritization system. For now, the labels provide a few useful handles: what appeared since previous scans, what has been around for a while, and what repeats across pages within one asset. Agencies can use those clues to guide review, then make their own calls about order and next steps.
Inspire Studio provides a workspace for agencies and their clients, intended to help manage asset workflows. Visit Inspire Studio to learn more about its workspace.