“We know accessibility matters, but we don’t know where to start” — How we turned that anxiety into a practical WebOps workflow

“Accessibility is mandatory now, right?”
“Is our website okay as it is?”
“We know we should do something, but we don’t know where to start.”

We’ve been hearing questions like these more often from clients and teammates.

For people involved in website operations, the scope of work keeps expanding. There are daily updates, feedback requests, broken links, display issues, SEO settings, measurement tags, and client confirmations. When “accessibility” gets added on top of all that, it can become hard to tell what should be handled in daily operations and what requires specialist support.

We felt that confusion ourselves.

At first, we saw the word “mandatory” and assumed we had to bring every page into full compliance immediately. But as we looked into it and tried to apply it in real projects, our thinking changed.

What helped us move forward was not trying to solve everything at once. It was separating the work into two parts:

• what tools can detect automatically
• what humans need to review

From there, we built the parts we could handle into our day-to-day WebOps workflow.

This article shares how we organize that work on the ground, what we can realistically do, and where we draw the line.

---

Why this problem happens

Accessibility work becomes difficult not only because the subject is technical, but because the starting point is often unclear.

The word “mandatory” can create a sense of urgency.
Specialist audit reports can feel overwhelming.
And daily WebOps teams may not know which issues they can handle themselves and which ones require expert judgment.

That combination often leads to one result: the team freezes.

Background 1: “Reasonable accommodation” and “improving the environment” are easy to confuse

The first thing we had to do was sort out the terms.

On April 1, 2024, Japan’s revised Act for Eliminating Discrimination against Persons with Disabilities took effect, requiring private businesses to provide “reasonable accommodation.”

However, making a website accessible in advance falls under “improving the environment.” This is positioned as a best-effort obligation. JIS X 8341-3:2016 is used as a reference standard.

Put simply:

• Reasonable accommodation means responding when asked, within a scope that does not create an excessive burden. This is the mandatory part.
• Improving the environment means making the website accessible in advance. This is the best-effort part.

We initially mixed these up.

We thought “mandatory” meant every page had to be fully fixed right away. Once we understood that reasonable accommodation and improving the environment are different, it became easier to set realistic priorities.

The premise we now use is this:

It is not “fix everything immediately or you are breaking the law.” It is “gradually build, through operations, a state where you can respond when asked.”

That shift helped us move from panic to a workflow we could actually sustain.

Background 2: Trying to fix everything at once can stop the work entirely

Early on, we tried to achieve full compliance in one go on a client’s site.

We brought in an external specialist audit and tried to address every issue it surfaced. The findings came back by the dozen, and many of them included technical terminology that took time to understand.

We ran into several problems:

• We could not tell which issues needed to be prioritized
• We had no spare capacity to handle all findings alongside daily updates and feedback requests
• Just understanding each finding consumed a lot of time

In the end, the work stalled. We stopped opening the audit report.

The audit itself was valuable. But because we had no way to turn the findings into daily operations, the report did not lead to continuous improvement.

That experience changed how we approach accessibility-related work. Instead of trying to handle everything at once, we now start by separating what fits into regular WebOps from what belongs to specialist review.

---

Steps to move forward

The key is not to automate everything.

Some defects can be detected by tools.
Some accessibility-related items require human judgment.
Some areas should be left to specialists.

Once those boundaries are clear, it becomes easier to build a practical workflow.

STEP 1: Visualize the current state

The first step is to understand the current state of the website.

At this stage, the goal is not to determine full accessibility compliance. The goal is to identify basic defects that can make the site harder to use for anyone.

For example, MONJI+ website anomaly detection can flag items such as:

• broken links and failed image loads
• missing SEO settings such as title and description
• missing measurement tags
• layout breaks between desktop and mobile

These are not accessibility judgments in themselves.

However, a broken link, an image that does not display, or a mobile-only layout issue can directly harm usability. So we catch these automatically and turn them into feedback requests.

At the same time, we are careful about what we do not claim.

Whether an image has an alt attribute, whether the alt text accurately describes the image, whether headings follow the correct order, or whether information is conveyed by color alone cannot be fully judged by an automated crawl.

Those items require human review.

So we draw the line clearly: MONJI+ can help detect basic website defects, but accessibility-specific judgment still requires human eyes.

STEP 2: Turn human review into a monthly or pre-publish checklist

Next, we build the human-review items into our regular workflow.

If the process depends on memory or personal effort, the quality of checks varies from person to person. On busy weeks, items get skipped.

To avoid that, we register pre-publish review items in a MONJI+ checklist and confirm them whenever we create a feedback request.

For example:

1. Does the image have an alt attribute, and does the description represent the image content?
2. Are headings in the correct order, without skipped heading levels?
3. Is the link text more specific than just “click here”?
4. Is any information conveyed by color alone?

Turning these into a checklist helps prevent the process from depending on one person’s memory.

When checking with clients, we use a shareable feedback link so everyone can confirm on the same screen. Email threads can make it hard to track which issue was addressed and where. A shared screen makes the status easier to follow.

We also record team rules in a Wiki.
That way, even if the person in charge changes, the same checks can continue.

STEP 3: Use several months of records to guide future proposals

Accessibility-related work should not end as a one-time check.

When you keep records over several months, you can see what kinds of issues appear repeatedly, which items are being caught automatically, and which ones require human review.

For example, you can look back at:

• what defects were detected each month
• what pre-publish checklist items came up
• which issues could be handled in regular operations
• which issues may require specialist support

This makes it easier to explain the next step to clients.

Instead of saying, “We need to do accessibility,” in a vague way, you can say, “Here is what we are already catching in operations. Here is what still needs human review. And here is where a specialist audit may be necessary.”

That makes the conversation more concrete and easier to act on.

---

What changed in practice

After we separated the work into “what tools can detect” and “what humans review,” accessibility-related checks became less likely to stall.

Before, we would look at a specialist audit report and struggle to decide where to begin. The result was that nothing moved forward.

Now, we first catch basic defects such as broken links, failed image loads, missing SEO settings, missing measurement tags, and desktop/mobile display issues.

Then we review accessibility-specific items, such as alt text, heading structure, link wording, and color-only information, through a pre-publish checklist.

This two-tier setup helped us stop treating accessibility as a single overwhelming project.

It also made client communication easier.

We can now say:

“Here is what we can check within daily operations.”
“And here is where specialist verification is needed.”

That honesty matters. It avoids unnecessary fear, while still helping everyone move forward.

---

Notes and limitations

This workflow does not achieve full accessibility compliance.

We do not claim that we can prevent every issue or judge full conformance to a standard.

Actual verification using assistive technology, and formal judgment against standards such as JIS X 8341-3:2016, remain specialist areas. In those cases, we believe teams should work with accessibility experts.

What we can do is widen the range we can notice through WebOps.

That means:

• detecting basic website defects automatically
• turning human-review items into a checklist
• recording team rules in a Wiki
• using shareable links to confirm feedback with clients
• keeping the workflow sustainable

When someone asks, “Accessibility is mandatory now, right?” we do not pretend we can take on everything.

We explain what can be handled in operations, what requires human judgment, and what should be reviewed by specialists.

In our experience, that kind of honesty builds more trust than overpromising.

---

A WebOps enablement platform born from the field: MONJI+

The challenges described here are exactly the kind of challenges that led to MONJI+.

MONJI+ is a WebOps Enablement Platform that brings the people involved in website operations together as one team and supports problem-solving across every phase of WebOps.

We did not set out to build a “finished product” from the beginning.

The challenges truly worth solving live in the field of website operations. That is why we have continued listening to real voices from the ground.

By taking in each voice, resolving small points of friction, and layering updates one by one, new features have grown out of real operational challenges.

Through that steady accumulation, MONJI+ has become a platform supported by users in 77 countries around the world.

▼ Learn more about MONJI+ here
https://monji.tech/plus/

A world where the people working in website operations can say, with pride, “I love this work.”

▼ To make that real, we are waiting to hear your voice
https://monji.tech/plus/co-creation/

---

Summary

Accessibility-related work can easily become overwhelming if it is framed as “everything must be fixed immediately.”

The first step is to understand the difference between reasonable accommodation and improving the environment.

Then, separate what tools can detect automatically from what humans need to review.

MONJI+ can help detect basic defects such as broken links, failed image loads, missing SEO settings, missing measurement tags, and desktop/mobile display issues.

But items such as alt text quality, heading structure, link wording, and color-only communication still need human judgment.

The goal is not to achieve perfection in one step.

It is to widen the range you can notice through operations, record the rules, and keep the work in a form your team can continue.

That is the first step we now recommend when someone asks, “We know accessibility matters, but where should we start?”