Web Accessibility Operations Beyond Launch｜Testing, Improvement, and Team Building in the WCAG 2.2 Era

Web accessibility is not something that ends with pre-launch checks. In fact, the real difference appears after publication.

Websites are continuously updated. New announcements are added, images are replaced, forms increase, campaign pages are launched, and CMS templates are revised. In these daily changes, accessibility can easily break.

In Part 7, we will organize how to avoid “launch and forget” accessibility by looking at how to conduct testing, move improvements forward, and build a sustainable operational structure.

What You Will Learn

• Why web accessibility becomes an operational issue
• The difference between formal testing and daily checks
• How to combine tools, visual checks, and assistive technology
• How to prioritize improvements
• How to build a sustainable internal structure
• How to divide roles with the UUU Web Accessibility Service

The first important point is not to think of accessibility as a “one-time task.” A website is not a static deliverable; it is an operational asset that keeps changing.

Even if the homepage is improved, a new issue can appear when an editor posts an announcement as an image only. Even if a form is improved, required-field labels or error-message rules can break when another department adds a new application page.

Accessibility should be seen not as quality at the moment of release, but as a quality standard that must be preserved with every update. In that sense, testing and operations cannot be separated.

It is also important to distinguish between “testing” and “daily checks.” Testing means defining the target scope and success criteria, then checking conformance according to a certain method. Daily checks, on the other hand, are practical checks performed whenever content is updated or modified, in order to catch common issues early and avoid introducing new problems.

For example, in formal testing, representative pages may be selected and judged against each success criterion. In daily checks, it is more realistic to include items such as “Does the image have alternative text?”, “Is the heading structure intact?”, and “Can key actions be performed by keyboard?” in the pre-publication workflow.

Both are necessary. Continuous quality maintenance is difficult with only one of them.

Useful references for understanding testing include W3C’s evaluation guidance and WAIC’s testing guidelines for JIS X 8341-3:2016. W3C organizes accessibility evaluation from multiple perspectives, including initial checks, tools, conformance evaluation, and people, and makes clear that tools alone are not enough.

WAIC’s testing guidelines also explain how to select target pages when testing a set of web pages, as well as how to think about success-criterion checklists. In other words, testing is not just “looking around somehow.” It requires defining the scope, procedure, and recording method.

In day-to-day operations, it is important not to think, “We must run a full test every time.” If the ideal is set too high, the process will not become sustainable.

In practice, it is effective to prioritize important pages and frequently updated templates, such as the homepage, key user journeys, contact forms, job application pages, product detail pages, FAQs, and article detail pages. If there is a problem in a template or shared component, it can spread across the entire site.

By contrast, if you only check each page individually, you may end up fixing the same issue repeatedly. To make improvements more effective, it is important to think in terms of “patterns” rather than only individual pages.

For testing and checking, the basic approach is to combine tools, visual review, keyboard operation checks, and assistive technology checks. W3C presents evaluation tools as useful aids, while also noting that they cannot determine conformance on their own.

The Digital Agency’s introduction guide also explains that testing requires human visual checks, keyboard-only operation checks, and checks using assistive technologies such as screen readers.

In other words, automated checks are useful as an entry point, but issues such as clarity of text, visibility of focus, flow of operation, and how error messages are communicated must be checked by people actually using the content.

For example, automated tools are useful for detecting missing alt attributes, insufficient contrast, unlabeled form controls, and abnormal heading structures. However, they cannot easily judge whether existing alt text is appropriate, whether link text is understandable without context, whether error messages are helpful, or whether video captions are sufficient for understanding.

That is where human review matters. Reduce the issues that tools can detect first, then spend human review time on the points that require judgment. This division of roles helps reduce the operational burden.

Keyboard checking is one of the basic checks that can be easily incorporated into daily operations. Before publication, try following the main user flow using only the Tab key, without a mouse.

Check whether focus is visible, whether it is hidden behind a fixed header, whether users get lost inside a modal, and whether they can proceed all the way to form submission. This alone can help detect serious operation issues early.

For journeys directly tied to outcomes, such as inquiries or applications, it is especially valuable to make keyboard checking routine. Even without advanced expert testing every time, having a culture of checking basic operation can significantly change how quality deteriorates.

Assistive technology checks do not need to be performed on a large scale for every project, but they should be included for important user flows. The Digital Agency’s 2025 test results specify testing environments that include NVDA and VoiceOver, showing that verification considers combinations of OS, browser, and assistive technology.

What we can learn from this is that “visual checking by someone” is not enough. It is important to check with actual usage environments in mind.

Even if it is difficult to cover everything internally, you should at least develop the habit of checking how headings, links, and form notifications are conveyed through screen readers on key pages and important flows.

Prioritizing improvements is also very important in operations. If every issue is treated with the same weight, the team will quickly become exhausted.

In practice, the basic approach is to prioritize high-severity issues such as “users cannot complete a task,” “users cannot submit an application,” or “users cannot reach necessary information.”

Examples include not being able to reach the submit button by keyboard, required-field errors not being conveyed by screen reader, important announcements being available only as text inside images, or authentication not working for certain users. These issues should be treated as high priority.

After that, organize problems that affect understanding or efficiency, and finally address more detailed improvements related to appearance or consistency. This makes action easier.

At this stage, it is helpful to group “issues” by cause rather than only by page. For example:

• The article template tends to break heading levels
• The shared button component has weak focus indication
• The CMS input field lacks guidance for alternative text
• Error message rules for form components are inconsistent

When issues are understood by cause, it becomes easier to prevent recurrence by changing the system, rather than repeatedly fixing the same defect. In accessibility improvement, building reusable patterns that prevent recurrence is more efficient in the long term than accumulating individual fixes.

The most important point in building an operational structure is not to make the system dependent on a dedicated specialist. Ideally, experts should be involved, but in many organizations this is not realistic.

A more sustainable approach is to naturally incorporate accessibility into existing roles: public relations staff check the relationship between images and body text; editors adjust headings and link text; designers consider focus indication and contrast; engineers ensure HTML structure and form implementation; and directors manage pre-publication check items.

If accessibility becomes “one special person’s task,” it will stop as soon as that person is unavailable.

In practice, creating a short update guideline is also effective. For example:

• Add alternative text appropriate to the purpose of the image
• Use headings in order
• Use link text that explains the destination or action
• Do not place important information only in PDFs
• Check key flows by keyboard before publication

WAIC also provides example success-criterion checklists and explains how to narrow them down according to the required level. Rather than asking everyone to read the full standard, it is easier to make accessibility stick by translating the rules into role-specific check items.

It is also essential to record test results and response status. If there is no record of what was tested, from which perspective, what issues were found, and when they were fixed, improvement becomes dependent on individual memory.

The Digital Agency publishes annual verification results and clearly states the target scope, technologies used, testing environment, and conformance notation. Not every organization needs to aim for the same level of public disclosure, but at minimum, internal records of “what has been checked” and “what remains unresolved” are necessary for future improvement.

Visible records are also very helpful when responsibilities are handed over.

Here, let us also clarify the compatibility with the UUU Web Accessibility Service. Services like UUU, which provide text-size adjustment, contrast adjustment, line-spacing adjustment, reading support, translation, and ruby/furigana display, are compatible with accessibility operations in the sense that they support user-side viewing adjustments.

Introducing such a service can also raise awareness of accessibility internally and make user consideration more visible. Especially for organizations that cannot immediately carry out a full redesign, it can serve as a starting point for moving accessibility efforts forward.

However, such services do not replace testing, improvement, or operational structure itself. Even if a tool is introduced, fundamental issues remain if heading structures break during updates, form labels are missing, or important information exists only in PDFs.

In other words, services like UUU are highly compatible as support that helps users receive information more easily, but they do not perform the role of running pre- and post-publication testing, maintaining quality, or embedding accessibility into the organization. That still needs to be built as an operational system.

Understanding tool introduction and operational design as separate things is the first step toward continuity.

This chapter is especially useful for web managers, public relations staff, production company directors, and project owners who understand accessibility as something that must be addressed but have not yet been able to incorporate it into daily operations.

In real-world practice, sustainability matters before perfection. That is why testing needs to become a system, improvement needs prioritization, and team building needs role allocation.

Rather than aiming for perfection and stopping, it is better to start by checking key user flows, fixing shared components, creating short update rules, and keeping records. This accumulation leads to stronger accessibility operations over time.

Here is the summary of Part 7.

Web accessibility is not a one-time pre-launch task. It is a quality standard that must be maintained through ongoing updates.

To do this, it is important to separate formal testing from daily checks and combine tools, visual inspection, keyboard operation checks, and assistive technology checks. In improvement work, it is effective to prioritize high-severity issues and connect them to recurrence prevention by identifying root causes.

For team building, the key to continuity is not leaving everything to specialists, but naturally embedding accessibility into existing roles.

Support services such as the UUU Web Accessibility Service are compatible as user-support measures, but the core of testing, improvement, and operations must still be built as part of the organization’s own practice.

In the final chapter, we will once again organize the relationship with the UUU Web Accessibility Service and summarize how to balance support tools with essential improvements.

Reference Links

• W3C WAI: Evaluating Web Accessibility Overview
• W3C WAI: Easy Checks – A First Review of Web Accessibility
• W3C WAI: Web Accessibility Evaluation Tools List
• W3C WAI: WCAG-EM Overview
• WAIC: JIS X 8341-3:2016 Testing Guidelines
• WAIC: Example Success Criteria Checklist
• Digital Agency: Web Accessibility Introduction Guidebook
• Digital Agency: Web Accessibility Test Results 2025