How Far Accessibility Work Should Actually Go
Passing an audit and being usable are two different jobs. The legal position in Japan, the four checks worth doing first, and why retrofitting costs so much more than building it in.
Accessibility conversations arrive in two forms. Either a client or a tender has made it a condition, or someone has reported that they cannot use the product.
The first is satisfied by passing an audit. The second is not. They are not the same piece of work.
The position in Japan
The revision to the Act for Eliminating Discrimination against Persons with Disabilities made the provision of reasonable accommodation by private businesses mandatory from April 2024. It does not impose direct technical standards on websites, but the responsibility of the party providing a service is now clearly stronger.
The technical reference is JIS X 8341-3, which corresponds to the international WCAG guidelines. Public sector procurement frequently requires conformance, and it increasingly appears as a condition in contracts with large private companies.
In practice, then, it usually arrives as a commercial condition before it arrives as a legal one.
Passing an audit is not the same as being usable
Automated tools can judge a lot mechanically. Contrast ratios, alternative text, heading structure, focus order.
You can pass all of it and still be unpleasant to use for someone who cannot see the screen.
The reason is simple. Tools judge whether something is broken, not whether it works. It is entirely possible to conform on every checkpoint and still have a screen reader user take ninety seconds over something a sighted user does in four. No tool warns you, because nothing is wrong. It is just bad.
What to actually do
In order, by return on effort.
One, keyboard only. Put the mouse away and complete your main flows using tab alone. Getting stuck, losing track of where you are, being unable to escape a modal. This is where most problems are found and the fixes are usually straightforward.
Two, text and colour. Meet the contrast ratios. And do not carry information in colour alone. If red means error, something other than red also has to mean error.
Three, form labels. Whether inputs and their descriptions are properly associated. When that link is broken, a screen reader user cannot tell what a field is for.
Four, use it with the screen off. Twenty minutes with VoiceOver or NVDA on your own product. This produces information no report ever will. Your icon button announcing itself as "button", nothing being announced during loading so it sounds like the app died. Minutes, not weeks.
Why retrofitting is expensive
Because it is structural.
Visual fixes can be applied later. Information structure, interaction order, and how state is communicated are built into how the thing was made. Changing those afterwards is close to rebuilding.
Built in from the start, the additional cost is close to nothing, because you never build the inaccessible version and therefore never repair it.
When people say accessibility is expensive, they are almost always describing the cost of having deferred it.
The argument that actually persuades
Designing for someone who cannot see the screen forces the structure of the product to become explicit. What the hierarchy actually is, what this control does, what happens after it is pressed.
Those are design questions, not accessibility questions. Most teams never have to answer them precisely, because sighted users paper over vagueness by guessing visually.
Every project where I have properly designed for a screen reader, the visual version improved too. Labels got shorter and truer, steps got removed, and things that had been ambiguous had to be decided.
Captions help people on a loud train. Large touch targets help people with one hand full. High contrast helps everyone outdoors. That is not a stretch, it is the ordinary consequence of designing for the hardest case.
If you are commissioning it
A quote that says only "conforms to JIS X 8341-3" may mean passing an automated audit. If that is what you need, fine.
If you want it to be genuinely usable, write into the deliverable that the main flows are walked end to end with a screen reader. Whether that one line is present changes the nature of the work substantially.