Known Issues Are Better Than Surprise Issues

Known issues are not the goal.

But they are better than surprise issues.

That can sound strange at first. Nobody wants accessibility problems sitting on a list. Nobody wants to tell a reviewer, stakeholder, or vendor that something is not fully resolved yet.

But pretending a gap does not exist does not make the experience better.

It only makes the risk harder to manage.

A known issue gives the team something to work with.

It can be described. It can be prioritized. It can be assigned. It can be discussed with a vendor. It can be paired with a workaround or alternative path if one is needed. It can be tracked through remediation instead of rediscovered in every review cycle.

A surprise issue arrives differently.

It shows up when the team thought the work was done. It may affect schedule, scope, approval, user support, or trust. It may force the team to reopen decisions that would have been easier to handle earlier.

That is why review readiness is not about showing up perfect.

It is about showing up informed.

A team that knows its issues can have a better conversation:

• Here is what we checked.
• Here is what we found.
• Here is what we fixed.
• Here is what remains.
• Here is who owns the next step.
• Here is where we need guidance.

That is a very different posture from:

• We assumed it was fine.
• We did not check that path.
• We did not know the vendor had that limitation.
• We did not realize the generated document mattered.
• We thought accessibility would be handled during final review.

Known issues are especially important with vendor tools.

A vendor may already know about limitations in a product. A VPAT may list partial support. A support article may describe a keyboard issue. A release note may mention an accessibility fix that is not available in the version being used.

If the project team never brings those details into the implementation conversation, the issues can still become surprises later.

Naming an issue does not mean accepting it forever.

It means the team is no longer relying on invisibility.

Sometimes the right next step is remediation before launch. Sometimes it is a vendor escalation. Sometimes it is changing configuration. Sometimes it is documenting a temporary workaround while a fix is tracked. Sometimes it is deciding that the risk is too high for the planned approach.

Those are project decisions.

They are better made with the issue visible.

This is also where tone matters.

A known issue list should not become a blame document. It should be a working map of what the team understands about the experience.

The question is not, "Who failed?"

The question is, "What do we know, what affects users, and what are we doing about it?"

Accessibility work gets harder when every issue is discovered at the most expensive moment.

Known issues are not success by themselves.

But they give the team a chance to act before the problem becomes a surprise.

Previous note

Vendor Accessibility Still Needs Ownership sets up why ownership includes naming, tracking, and following up on accessibility risks instead of letting them become surprises.