Accessibility

Scope

• Application UI accessibility: navigation, controls, dialogs/modals, and editor/preview workspace.
• Authored content accessibility: checks and guided improvements for the HTML you create.
• Out of scope: third-party AI provider tools, external websites opened from Zyntria, and LMS/platform behavior after paste/export.

Standards and Approach

• Zyntria’s goal is to support accessible authoring and to reduce common WCAG-related issues in generated HTML.
• Zyntria provides checks/audits and “safe fixes” intended to improve semantic structure and labeling patterns.
• Because target environments vary (browsers, LMS sanitizers, host CSPs), accessibility outcomes must be validated in the final destination.

Application UI (Zyntria) – Expected Accessibility Behaviors

• Keyboard use: core workflows should be operable without a mouse (project switching, opening tools, applying actions).
• Focus management: dialogs (e.g., checks, accessibility audit, “Paste AI output”) should trap focus while open and return focus on close.
• Visible focus: focus should be clearly visible on interactive elements.
• Readable layout: zoom controls support preview inspection at multiple scales; UI density/theme options support readability.
• Clear labeling: key actions (Run Checks, Re-check, Fix My Page, Accessibility Audit, Fix All, LMS Optimizer, Export/Copy/Download) should be labeled.

Authoring Support – What Zyntria Checks and Improves

Zyntria includes a checks system and a dedicated accessibility audit experience intended to surface issues and apply safe improvements. Based on product capabilities, Zyntria’s accessibility support generally targets:

• Semantic structure: encouraging correct heading patterns and meaningful structure.
• Landmarks and regions: promoting use of appropriate structural containers when applicable.
• Text alternatives: identifying missing/weak image alternative text patterns.
• Labeling: improving descriptive labels and instructions for interactive elements in authored HTML.
• Keyboard/focus considerations: flagging common patterns that can harm keyboard use in delivered pages.

Accessibility Audit and “Fix All”

• Accessibility Audit: opens an accessibility-focused review UI to list detected issues in the current document.
• Fix All: applies a set of safe accessibility improvements to the HTML to address common findings.
• Re-check: rerun checks after changes to confirm what improved and what still needs attention.

Fix My Page (Guided Resolution Workflow)

• Captures detected issues from checks into an issue list.
• Allows selecting issues (select all/none supported) before applying fixes.
• Applies updates to the HTML and supports iterative “re-check → fix → validate” workflows.

Preview Modes and Accessibility Testing Constraints

Zyntria provides both a guarded “Safe Preview Mode” and a more permissive “Full Preview Mode.” These modes affect runtime behavior during testing and can influence accessibility tooling results inside the preview.

• Safe Preview Mode: intended for static HTML/CSS review; scripting is restricted and some runtime behaviors may not execute.
• Full Preview Mode: intended for interactive content; scripting may run more realistically, but sandbox/CORS constraints may still apply.
• Network/hosting constraints: external resources and relative paths may not resolve in preview unless assets are hosted and permitted.

LMS Optimizer (Canvas/LMS) and Accessibility

• LMS Optimizer generates LMS-friendly output and supports “body-only” output for paste-in editors.
• Some LMS platforms sanitize HTML and may remove attributes/elements that are important for accessibility. Always validate after paste.
• If using “strip inline styles,” ensure readability/contrast and spacing remain acceptable in the LMS environment.

AI-Assisted Workflows – Accessibility Notes

• Zyntria’s AI workflow is “bring your own AI.” Outputs come from third-party providers (e.g., ChatGPT, Gemini, Copilot).
• Zyntria can generate prompts instructing the provider to return only final HTML and may include issues/goals such as “improve accessibility.”
• All AI-produced HTML must be reviewed, tested, and validated by the user before use.

Recommended Validation Steps (Practical)

• In Zyntria: Run checks → open Accessibility Audit → apply Fix All (if appropriate) → Re-check.
• In destination: test the exported/pasted HTML in the final LMS/site environment (sanitization and CSS can change outcomes).
• Keyboard pass: Tab/Shift+Tab through interactive elements; confirm visible focus and logical order.
• Headings/structure pass: confirm headings describe sections and are not used for purely visual styling.
• Text alternatives: confirm images convey appropriate alt text; decorative images should not add noise.
• Contrast and scaling: check at browser zoom levels used by your audience and ensure content remains readable.

Known Limitations and Boundaries

• No guarantee that “Fix All” resolves all accessibility issues for every design and content type.
• No certification of WCAG/ADA compliance; guidance is best-effort and depends on target environment and content complexity.
• Preview sandboxing and browser security constraints can affect interactive behaviors and audit signals.
• Local-first storage: exported backups remain the user’s responsibility; accessibility fixes do not imply recoverability guarantees.

Always validate accessibility in the final destination environment.

End of Accessibility Page