New templates, forms and content components should not be approved on appearance and function alone. Clear test evidence makes accessibility a dependable part of the release decision.

A WordPress change can work technically while still excluding readers. Unclear focus, a faulty heading sequence or a confusing error message may only become visible after launch. A manageable quality check then turns into an unplanned correction under pressure.

Which page types need clear evidence before release?

Start with the journeys that matter most to your readers and your organisation. These often include home pages, service pages, contact forms, checkout steps and reusable content components. Record which template or component is involved and who is responsible for approving it.

The selection does not need to cover the entire website immediately. A small, justified sample creates clarity faster than a vague full review. What matters is that new or changed elements appear in that sample.

How do readers experience the keyboard, focus and page structure?

Complete each selected journey using only the keyboard. Visible focus should follow an understandable order, reach every important control and never disappear. Also check that dialogs, menus and forms remain fully usable without a mouse.

Readers also need content with a structure they can understand. Headings should describe the page content and form a sensible hierarchy. Images need suitable alternative text, while purely decorative images should not create unnecessary information.

What makes forms and error messages genuinely understandable?

A form is reliable only when inputs, required fields and errors are understandable without guesswork. Test empty, incorrect and valid submissions, then check whether each message clearly identifies the affected field and the next step. Colour should never be the only explanation.

Repeat important tasks with a screen reader and listen for the names, roles and states of controls. This reveals whether a visually clear interface also remains semantically understandable. WordPress identifies WCAG 2.2 at levels A and AA as the expected standard for official websites and plugins.

Which findings determine approval, rework or a stop?

Assign every finding to an owner and document the page, component, expected behaviour and observed result. Add the browser, device and input method so the problem remains reproducible. A screenshot can help, but it cannot replace a clear description.

Define before testing what will stop a release and what can be accepted as planned rework. An unreachable checkout or an incomprehensible contact form needs a different priority from a minor issue in a rarely read area. Accessibility then becomes an explainable go or no-go decision rather than an open-ended audit report.

DKSIGN can assess WordPress templates, forms, plugins, editorial workflows and hosting deployments together. The result is a prioritised technical worklist with ownership and dependable release evidence. This keeps the decision clear for leadership, marketing and website teams.

Checklist

• Inventory important page types and reusable components.
• Check keyboard use, visible focus and a logical heading structure.
• Assess alternative text, form errors and semantic controls.
• Give every finding an owner and an explainable priority.
• Document approval criteria before production release.

Do you need dependable approval evidence for your next WordPress change? DKSIGN reviews templates, forms, plugins and deployments as one release process and turns findings into prioritised technical work.

AI is already present on many websites, often without anyone treating it as a separate operational topic. A chatbot answers questions. Images are edited with AI. Copy is drafted with model assistance. Support, video and audio tools add more moving parts.

Each tool can look manageable on its own. The gaps appear between them: who knows which uses customers actually see? Who reviews them? Who decides whether a notice or label is needed?

Those questions need a clear owner.

What changes on 2 August 2026

The European Commission has announced that further EU AI rules will be enforced from 2 August 2026. For certain AI systems, it identifies additional transparency duties.

The communication covers, among other things, three different situations:

• In certain AI interactions, people may need to be told that they are speaking with an AI system.
• Deepfakes must be labelled.
• Certain AI-generated or altered content may need a machine-readable marking.

This does not mean that every AI-assisted item on every website needs the same label. The answer depends on the actual use, the organisation’s role, the system and the type of content. It needs to be assessed case by case.

The enforcement date also does not mean that every obligation in the wider AI framework starts at once. A dependable decision needs the current legal text, official guidance and the details of the implementation.

Three questions that need separate answers

1. Is a person speaking with a system?

When a visitor interacts with a chatbot or another AI system, a clear notice may be needed. That is about the interaction itself. It is different from labelling an image or video.

2. Has realistic content been generated or altered?

For deepfakes, the focus is on labelling artificially generated or manipulated content. That is not the same assessment as using text assistance inside an internal editorial workflow.

3. Does the origin need to be technically detectable?

Certain AI-generated or altered content may require a machine-readable marking. A visible notice and a technical mark are not automatically the same thing.

Keeping these cases separate removes a lot of noise. Each customer-facing use can be checked against the question that actually applies to it.

Where to start

The work does not begin with another website banner. It begins with an honest overview.

1. Record the use cases

List where AI appears in customer communication or content production: chatbots, generated or edited images, video and audio, automated replies, editorial workflows and embedded provider services. A small tool belongs on the list when customers can see its output.

2. Give each use case an owner

Every use case needs a named person or role. That person does not have to resolve every legal question alone. They should know what is in use, which information is available and when a new review is needed.

3. Define what triggers another review

Review is not a one-off task. A new provider, feature, content type or official guidance can trigger another review. Put those triggers into editorial review, release management or procurement.

4. Record the decision

For each use case, record the purpose, system or provider, affected content, responsible role, transparency option considered, open questions and next review date. This record is not legal advice. It makes the required review easier to trace.

What happens without clear ownership

Gaps appear. The chatbot is disclosed, but an edited image is not. A technical marking disappears during export and no one notices. Later, the team has to start from scratch: which tools were active, who decided, and which assets are affected?

That costs time and creates uncertainty. More importantly, no one is clearly responsible for starting the next review.

Why the website is often where this comes together

AI features rarely sit in one place. They can be part of the website, CMS, support stack, campaigns or an external provider. Technical delivery, editorial decisions and accountability are then spread across several people.

At DKSIGN, we look beyond one website feature. We review how the connected workflows fit together: where content is created, where it changes, who reviews it, what customers see, and what happens when the workflow changes later.

That is technical responsibility and maintainability, not legal certification. The legal interpretation of a specific case belongs in an appropriate legal review.

A practical next step

If your team lacks a clear view of the AI features connected to your website, we can review the functions in use, clarify ownership and agree the next steps.

*Note: This article is editorial information, not legal advice or a compliance determination. Requirements may differ by system, role, content and use case.*

For a business, an inaccessible website is more than a technical shortcoming. People may abandon enquiries or purchases, marketing content fails to reach part of the audience, and nobody internally owns preventing the same issue from returning.

An audit shows the state on one particular day. It does not ensure that the next landing page, product, form or PDF remains usable. WordPress and WooCommerce sites change continuously.

Start with scope, then make the practical question clear

Whether and how accessibility requirements apply to a particular organisation, offer or digital product depends on the individual case. DKSIGN provides technical assessment, not legal advice or a legal guarantee.

Whatever the legal position, the practical business question remains: can people find, understand and use the information that matters to them, and complete an important process?

An audit is a measurement point

An audit makes technical and content issues visible. It cannot stop the next campaign page from introducing an unclear link, a poorly described image or an unusable form. That is why ownership matters: who checks new content, reviews new components and payment paths, receives feedback, and decides what needs another look before release or after an update?

Make the process fit everyday work

A useful process connects a few repeatable decisions: accessible components and templates, clear editorial rules, proportionate approval, checks for critical flows, and a traceable response to user feedback.

In a shop this becomes particularly concrete. Product, basket, checkout and payment need to remain understandable and operable. Automated checks are useful signals, but they cannot decide on their own whether someone understands an error message or can complete a purchase.

Technology supports; responsibility remains visible

A small business does not need a corporate bureaucracy. It needs a clear role, understandable decisions and a next action that actually happens.

Next step: DKSIGN can assess the website, backend and critical shop flows technically, then turn that into a practical maintenance and review process. Legal assessment remains with the business and its advisers.