Accessibility Started Catching Product Problems I Wasn’t Looking For
I used to think accessibility was mostly a checklist near the end.
Keyboard.
Contrast.
Labels.
Reduced motion.
Screen readers.
Important.
But separate from the main product.
That was wrong.
The more seriously I tested accessibility across Verbal, Quant and Intelligence, the more it started exposing product problems I was not looking for.
A keyboard trap is an accessibility problem.
It is also a navigation problem.
An unlabeled chart is an accessibility problem.
It is also an information-design problem.
A state that depends entirely on colour is an accessibility problem.
It is also a clarity problem.
Accessibility started acting like a stress test for the interface itself.
Keyboard-only use is brutally honest
A mouse can hide bad structure.
You can click almost anywhere.
You can visually hunt for the next action.
A keyboard forces the interface to reveal its order.
What receives focus first?
Where does Tab go next?
Can I reach every action?
Can I escape a dialog?
Does focus return somewhere sensible after closing it?
Can I answer a question without losing context?
If the focus order is weird, the information architecture is probably weird too.
That made keyboard testing much more useful than I expected.
Focus after state changes mattered even more
Opening a sheet.
Closing a sheet.
Submitting an answer.
Moving to the next question.
Returning from a detail view.
Those interactions change the page.
Where should focus go?
If it disappears to the top of the document, the user has to rediscover the interface.
If it lands on something hidden, the experience is broken.
That sounds like a niche concern until you realise:
The same issue can affect anyone using the interface quickly.
Good focus management makes the product feel more deliberate.
Reduced motion forced me to justify animation
I like motion.
Charts drawing in.
Cards lifting.
Progress moving.
Small celebrations.
Accessibility testing asks a useful question:
Does the interface still make complete sense when the motion disappears?
If the answer is no, the animation is carrying meaning it should not own.
That helped clean up several interactions.
Motion can enhance.
It should not be required to understand state.
High contrast exposed weak hierarchy
A beautiful interface can depend too heavily on subtle gradients and low-contrast text.
Force stronger contrast and suddenly some visual relationships disappear.
That reveals which distinctions were structural and which were decorative.
Primary action.
Secondary action.
Disabled.
Selected.
Error.
Warning.
Success.
Locked.
Those states need more than tasteful colour.
They need shape, text, border, iconography or other redundant signals.
That improves normal use too.
Charts became one of the biggest lessons
Quant and Intelligence both use increasingly rich visual analytics.
Radar.
Trends.
Heatmaps.
Speed versus accuracy.
Skill graphs.
Those are great for someone who can read the visual.
They should not become the only representation of the evidence.
So charts need:
Text alternatives.
Labels.
Readable summaries.
Keyboard-selectable elements where interaction matters.
Equivalent information somewhere the learner can inspect without relying on shape or colour alone.
That forced me to ask a deeper question:
What is this chart actually trying to say?
If I cannot explain that in text, maybe the chart is decorative.
Empty states are accessibility too
This surprised me.
Imagine an empty analytics card.
Visually, the learner may infer:
No data.
But what does a screen reader announce?
Nothing?
A heading and silence?
That is not enough.
The interface should explain:
What is missing.
Why.
What action creates evidence.
The same is true for:
Offline.
Stale.
Loading.
Error.
Locked.
Insufficient evidence.
Those states need actual language.
Not only visual treatment.
Mobile accessibility exposed cramped navigation
Small screens already punish overstuffed navigation.
Accessibility makes it worse.
Touch targets need room.
Labels need clarity.
Focus order still matters.
Screen zoom should not destroy the layout.
The keyboard can cover content.
Safe areas matter.
A six-destination navigation that technically fits may still be a bad mobile design.
This is where accessibility started influencing product prioritisation.
Maybe the answer is not smaller icons.
Maybe fewer things deserve the first level of navigation.
Screen-reader labels forced better naming
Buttons like:
View
More
Open
can make sense visually because the surrounding card provides context.
Read alone, they are terrible.
Accessibility forces the control to carry enough meaning.
Open Quant mastery details
is much clearer.
That clarity often improves the visible copy too.
Vague interaction labels are usually a sign the product itself has not decided what the action means.
Status messages need to be announced
Correct.
Incorrect.
Saved.
Sync failed.
Session complete.
Recommendation updated.
These things can change without moving focus.
A sighted user sees the page update.
A screen-reader user may hear nothing unless the state change is announced properly.
That pushed me to think more carefully about feedback as a system.
Not:
Did the colour change?
But:
Did the user receive the information?
Accessibility also challenged gamification
A celebration that flashes, shakes and vibrates can feel great to one person.
Annoying or physically uncomfortable to another.
So preferences matter.
Motion.
Haptics.
Audio.
The product should adapt without making the reduced version feel broken.
That aligns almost perfectly with the behavioural philosophy I already wanted:
Reinforcement without coercion.
Energy without overload.
Automated checks are not enough here either
Code can catch a lot.
Missing labels.
Some role problems.
Some contrast issues.
Type errors.
Regression patterns.
That is useful.
It cannot fully simulate:
A real screen reader.
A real phone.
High zoom.
One-handed use.
OS-level accessibility settings.
Physical keyboard navigation.
Real human confusion.
So accessibility has the same evidence problem as everything else in this project.
Automated confidence is not complete confidence.
Physical testing still matters.
Accessibility made the product less fragile
That is the part I did not expect.
Once an interface works through multiple input modes, multiple visual settings and explicit state descriptions, it becomes more resilient generally.
The hierarchy is clearer.
The copy is better.
The state machine is more explicit.
The controls are easier to identify.
The layout handles stress better.
Accessibility did not feel like adding a parallel version of the product.
It felt like removing assumptions from the main version.
I started treating accessibility as product QA
Not a compliance pass.
Not a badge.
A way to ask:
Does the interface still work when the learner does not interact exactly like I do?
That is a very good question.
Especially for a product I eventually want other students to use.
The weird part is that accessibility testing started catching things that had nothing to do with disability directly.
Bad hierarchy.
Ambiguous copy.
Overloaded navigation.
Invisible state changes.
Unnecessary motion.
Those were product problems all along.
Accessibility just made them harder to ignore.