How it works

Bialty is easiest to understand when you separate three layers:

1. stored WordPress content;
2. editor and Media Library state;
3. rendered frontend HTML.

Bialty acts on the third layer.

The rendering model

The product hooks into WordPress and WooCommerce rendering so it can inspect the HTML that is about to be served on the frontend.

At that stage, Bialty can:

• find images inside the rendered content flow;
• decide whether an image alt attribute is empty or already populated;
• apply the configured rule;
• output the changed HTML back to the frontend.

That is why the plugin feels immediate. You change the rule, and the rendered output changes without a massive migration step.

Why the Media Library stays untouched

Bialty does not need to update the Media Library in bulk to do its job.

This design has practical consequences:

• there is no destructive rewrite to roll back later;
• there is no need to regenerate a full metadata history;
• the product stays reversible;
• you can validate output before you decide to keep a rule.

The logic layer

At a high level, Bialty answers two questions:

1. What should happen when alt text is missing?

You pick a rule such as:

• focus keyword
• title
• image name
• combined variants

2. What should happen when alt text already exists?

You choose whether to leave the current value alone or replace it according to the selected rule.

That split is important because many sites do not have a single clean historical state. Some images are blank, some have weak values, and some have values worth preserving.

Signal sources

Depending on the site and plan, the plugin can use:

• post title
• image file name
• focus keyword from Yoast SEO
• focus keyword from Rank Math
• keyphrase data from All in One SEO

That makes Bialty a contextual rule engine rather than a caption generator.

Manual override path

Bialty also supports manual overrides through a post-level workflow.

This is where you keep control over:

• premium landing pages;
• important product pages;
• templates where a global rule is not enough.

Commercial expansion

The commercial scope extends the same logic to:

• custom post types
• WooCommerce product flows
• extra configuration controls such as blacklist and Add Site Title

In other words, the product architecture stays the same. The scope expands.

Why debug mode exists

In normal operation, Bialty uses a wrapper strategy that helps the DOM processing step.

Debug mode exists for edge cases where a wrapper may create rendering or styling issues. It is a troubleshooting tool, not the normal path.

The right mental model

If you remember only one sentence, make it this one:

Bialty changes rendered output, not stored Media Library metadata.

That single sentence explains most of the product behavior, most of the troubleshooting, and most of the trust advantage.