Accessibility across Omega Web Pro and the websites it generates.

1. Our accessibility commitment

We aim to design Omega Web Pro so users can understand navigation, operate controls by keyboard where practical, perceive focus, use zoom and responsive layouts, and access meaningful structure through modern assistive technologies. We also aim for the Builder’s generated output to begin from semantically structured, keyboard-aware and contrast-conscious foundations.

2. Reference standard

Our engineering direction is informed by the Web Content Accessibility Guidelines (WCAG) 2.2. New Zealand’s current Government Web Accessibility Standard uses WCAG 2.2 Level AA for covered government agencies. Omega Web Pro is a private commercial service and does not claim that the New Zealand Government Web Accessibility Standard automatically applies to every Omega customer or generated site; customers must determine the legal standards that apply to them.

3. Accessibility of OmegaWebPro.com

Omega’s public website, Builder, checkout acceptance page and customer-account surfaces are designed with accessibility considerations including semantic landmarks, visible headings, labels, responsive layouts, skip navigation, keyboard operability, focus treatments, legible contrast and reduced-motion awareness where supported by the interface.

Because the platform evolves, temporary defects can occur. We welcome reports identifying a specific page, control, browser, assistive technology and the problem encountered.

4. Accessibility foundations in generated websites

Omega’s generation pipeline can create accessibility-supporting structure such as:

• semantic HTML5 landmarks and logical document regions;
• hierarchical headings and descriptive page titles;
• form labels and target-specific form structure;
• keyboard-aware navigation patterns and visible focus design;
• responsive layouts that support reflow across common viewport sizes;
• contrast-aware design roles;
• reduced-motion considerations for users who prefer less animation;
• image alternative-text fields and generation rules;
• link and button structures intended to remain understandable outside visual styling;
• validation designed to catch certain structural accessibility problems before export.

5. What the Accessibility Engine and validation checks do

The Accessibility Engine and Final Validation process inspect structural conditions that can be checked deterministically during generation. These checks can identify or reduce common issues, but they cannot determine whether every sentence, image description, colour choice, embedded service, business process or user journey is accessible in practice.

6. Known limitations and areas outside Omega’s control

Accessibility can change after export. Hosting templates, WordPress Core, themes/plugins, third-party scripts, analytics, consent tools, embedded maps/video, payment widgets, custom code, customer edits, uploaded documents, images containing text, CAPTCHA services and external content may introduce barriers that Omega cannot evaluate from the original generation alone.

Generated content can also be technically valid while still being difficult to understand. Plain language, reading level, meaningful link text, accurate alternative text and understandable error messages require editorial judgement.

7. Customer responsibility before publishing

The customer controls the final website and is responsible for reviewing the deployed site against the laws, standards and audience needs that apply to their organisation. Customers should:

• test all primary tasks with keyboard only;
• check focus order and focus visibility;
• verify text and non-text contrast;
• review all image alternative text;
• test zoom/reflow and orientation changes;
• check forms, errors, confirmations and required fields;
• provide captions/transcripts/audio description where required;
• review PDFs and downloadable documents separately;
• test with representative screen readers or other assistive technology;
• retest after significant content, plugin or design changes.

8. WordPress output

Omega’s WordPress renderer creates website-specific WordPress resources for installation into a compatible WordPress environment; WordPress Core and third-party plugins remain independently maintained. Accessibility can be affected by the hosting environment, WordPress version, plugin/theme changes, block edits and external integrations added after Omega generates the package.

9. Pure HTML output

Pure HTML output is designed to remain portable and editable using ordinary HTML, CSS and vanilla JavaScript. The absence of a platform lock-in does not remove the need to test the deployed site on its real hosting environment, especially after code or content has been modified.

10. Recommended testing approach

No single automated scanner can establish full accessibility. A commercially responsible process combines automated testing, manual keyboard testing, responsive/zoom testing, semantic review, content review and—where risk or legal obligations justify it—testing by people who use assistive technologies or an independent accessibility specialist.

11. Accessibility feedback

If you have difficulty using OmegaWebPro.com, tell us what page or feature you were using, what you expected to happen, what happened instead, and—if you are comfortable doing so—the browser, operating system and assistive technology involved.

12. Remediation process

We will assess reproducible accessibility reports, prioritising issues that block essential tasks such as building, reviewing purchase information, accepting checkout terms, logging in or obtaining a licensed download. Where a defect is within Omega’s control, we aim to correct it in an appropriate product update. Where an issue comes from a third-party service, browser, hosting environment or generated customer content, we may provide guidance but cannot guarantee the third party’s remediation.

13. Alternate access and urgent purchase/account issues

If an accessibility barrier prevents you from understanding purchase information or accessing a paid account/licence function, contact support before completing or repeating a transaction. We can help identify the relevant information or next step without requiring you to bypass checkout or security controls.

14. Changes to this statement

We may update this Accessibility Statement as Omega Web Pro, WCAG guidance, browsers and applicable legal requirements change. The revised date at the top identifies the current published version.