Accessibility Statement

This statement explains Addienator’s approach to digital accessibility, the measures included in our website and application, known limitations, and how to report a barrier.

Effective date: September 13, 2026

Last reviewed: September 13, 2026

1. Purpose and Scope

This Accessibility Statement describes the approach taken by ATELIER ADDIE INC., operating as Addienator (“Addienator,” “we,” “us,” or “our”), to improve accessibility across:

  • the Addienator public website;
  • account registration and sign-in;
  • membership and subscription functions;
  • Contact and Support forms;
  • language-selection functions;
  • the protected Addienator application;
  • project setup and dashboard screens;
  • instructional-design workflows;
  • help and Knowledge Base content; and
  • downloadable documents provided through the service.

This Statement also explains how to report an accessibility barrier and request an alternative way to access information or complete a task.

Accessibility is an ongoing responsibility. Digital content, browsers, devices, assistive technologies, third-party services, and the Addienator application may change over time. Addienator will continue to review and improve accessibility as barriers are identified.

2. Service Operator and Accessibility Contact

Addienator is operated by:

ATELIER ADDIE INC.

Postal address:

Suite 313, 43 Boul. Samson, Laval, Quebec, Canada H7X 3R8

Accessibility contact:

President

Email:

support@addienator.com

Questions, requests for alternative access, and reports of accessibility barriers may be directed to the accessibility contact above or submitted through the Contact and Support form.

3. Accessibility Commitment

Addienator is committed to providing a website and browser application that can be used by as many people as reasonably possible, including people who use assistive technologies or alternative methods of interaction.

Accessibility work is considered:

  • when shared components are designed or revised;
  • when public pages and legal pages are created;
  • when application controls and dialogues are implemented;
  • when complete user journeys are reviewed;
  • when documents and help content are prepared; and
  • when users report barriers.

Addienator seeks to identify and reduce barriers without requiring a user to disclose a disability, diagnosis, or medical information.

4. Reference Standard and Current Status

4.1 Reference Standard

Addienator uses the Web Content Accessibility Guidelines, WCAG 2.2 Level AA, as a reference target for ongoing accessibility work.

WCAG addresses accessibility through four broad principles. Digital content should be:

  • perceivable;
  • operable;
  • understandable; and
  • robust.

4.2 Current Status

Addienator does not currently claim:

  • formal accessibility certification;
  • complete WCAG 2.2 Level AA conformance;
  • conformance across every browser, device, and assistive technology;
  • that every third-party service is fully accessible; or
  • that every downloadable or user-generated document automatically meets an accessibility standard.

This Statement is not an independent accessibility audit or certification.

The absence of a documented limitation does not mean that no barrier exists.

5. Accessibility Measures

5.1 Keyboard Access and Focus

Addienator reviews navigation, links, controls, forms, dialogues, menus, and application actions for:

  • keyboard operation;
  • logical focus order;
  • visible focus indication;
  • avoidance of keyboard traps;
  • predictable dialogue opening and closing;
  • keyboard access to confirmation and cancellation controls; and
  • the ability to complete important actions without relying only on a pointing device.

5.2 Page Structure

Public pages and application screens are reviewed for:

  • one clear main heading;
  • meaningful heading order;
  • programmatically identifiable regions where appropriate;
  • descriptive page titles;
  • meaningful link text;
  • clearly associated labels and instructions; and
  • a reading order that follows the intended visual order.

5.3 Visual Presentation

Addienator reviews visual presentation for:

  • readable text contrast;
  • distinguishable controls and links;
  • visible keyboard focus;
  • information that does not rely only on colour;
  • responsive reflow;
  • readable layouts at increased browser zoom;
  • avoidance of unnecessary horizontal page scrolling; and
  • adequate spacing around controls where reasonably possible.

5.4 Images and Icons

Meaningful images should include useful text alternatives.

Decorative images should be ignored by assistive technologies where appropriate.

Icons used as controls should have an accessible name that communicates their purpose.

5.5 Forms and Validation

Forms are reviewed for:

  • visible labels;
  • required-field identification;
  • understandable instructions;
  • clear error identification;
  • correction guidance where available;
  • keyboard-accessible controls;
  • consent controls with meaningful labels; and
  • an order that remains understandable when read by assistive technology.

5.6 Dialogues, Overlays, and Status Messages

Application dialogues and overlays are reviewed for:

  • appropriate focus movement;
  • focus containment where required;
  • keyboard-accessible dismissal;
  • return of focus to a logical location;
  • understandable status information; and
  • progress and error messages that do not depend only on visual presentation.

5.7 Language and Content

Addienator supports English and Canadian French content.

Pages and generated interfaces should identify the active language appropriately.

Instructions, validation messages, and control labels should use clear and consistent language.

6. Complete User Journeys

Accessibility review is not limited to isolated controls.

Addienator considers complete user journeys that may include:

  • selecting a language;
  • registering for an account;
  • signing in;
  • choosing a plan;
  • completing membership checkout;
  • opening the protected application;
  • starting or restoring a project;
  • connecting to an AI provider;
  • uploading source material;
  • moving through Discovery and course-design stages;
  • editing and approving generated content;
  • saving and reopening a project;
  • exporting a Microsoft Word document;
  • importing a supported Word document;
  • using the Knowledge Base; and
  • submitting a Contact and Support request.

A component that is accessible by itself may still create a barrier when used as part of a longer workflow. Addienator will consider the complete task when reviewing reported barriers.

7. Compatibility and Technical Environment

Accessibility may vary based on:

  • browser type and version;
  • operating system;
  • device;
  • screen size;
  • browser zoom level;
  • browser extensions;
  • assistive technology;
  • input method;
  • language;
  • third-party service behaviour; and
  • organization-controlled Enterprise configurations.

Addienator is designed for current browsers that support modern web standards.

Older browsers, unsupported browser configurations, private-browsing restrictions, disabled browser features, or third-party extensions may affect application operation and accessibility.

When reporting a barrier, you may include your browser, device, operating system, and assistive technology if you are comfortable doing so. This information is optional.

8. Known Limitations

Addienator does not claim that the website or application is free from all accessibility barriers.

Current review status:

No specific unresolved accessibility limitation has been formally documented as of September 13, 2026. Reviews so far have covered selected pages and workflows and do not establish complete WCAG 2.2 Level AA conformance. Barriers may remain. If you encounter difficulty, contact the President at support@addienator.com or use our Contact and Support form.

9. Third-Party Content and Services

Some Addienator functions depend on third-party services, which may include services used for:

  • account access;
  • membership checkout;
  • payment processing;
  • consent preferences;
  • optional analytics;
  • transactional email;
  • Google Gemini;
  • organization-controlled Enterprise AI connections; and
  • external websites linked from Addienator.

Addienator does not control every accessibility feature or limitation of a third-party service.

Where a third-party barrier affects an Addienator user journey, Addienator will use reasonable efforts to:

  • identify the affected service;
  • provide available troubleshooting information;
  • offer an alternative route where reasonably possible; or
  • communicate the issue to the relevant provider.

A third-party limitation does not prevent users from reporting the barrier to Addienator.

10. Uploaded and Generated Documents

10.1 Uploaded Source Material

Users may upload PDFs and other supported source material.

Addienator does not control the accessibility of documents created by the user, the user’s organization, a subject matter expert, or another third party.

An inaccessible source document may affect the user’s ability to review or work with that material.

10.2 Microsoft Word Exports

Addienator generates Microsoft Word documents for instructional-design review and delivery.

Addienator does not claim that every exported Word document automatically conforms to WCAG, PDF accessibility requirements, or another document-accessibility standard.

Document accessibility may be affected by:

  • generated content;
  • tables;
  • heading structure;
  • images;
  • figure descriptions;
  • user edits;
  • imported stakeholder edits;
  • conversion to PDF; and
  • changes made in another application.

The person or organization publishing or distributing a final document is responsible for reviewing its accessibility for the intended audience and use.

10.3 Portable Project Files

Portable Addienator project files are application project archives. They are not intended to function as accessible end-user documents.

Users who need access to project information in another format may contact Addienator for assistance.

11. Reporting an Accessibility Barrier

You can report an accessibility barrier through the Contact and Support form.

Select:

Accessibility

You may also email:

support@addienator.com

A barrier report may concern:

  • the public website;
  • account registration;
  • sign-in;
  • membership checkout;
  • a form;
  • the language interface;
  • the protected application;
  • a project workflow;
  • a dialogue or control;
  • a Word export or import;
  • the Knowledge Base; or
  • another Addienator page or function.

You do not need to disclose a disability or medical condition to report a barrier.

12. Information That May Help Us Investigate

Please describe, where possible:

  • the page, screen, or application step you were using;
  • the task you were trying to complete;
  • what you expected to happen;
  • what happened instead;
  • the control, message, or content that created the barrier; and
  • any workaround you discovered.

If you are comfortable doing so, you may also include:

  • your browser and version;
  • your operating system;
  • your device type;
  • your screen size or zoom level;
  • your input method; and
  • the assistive technology you were using.

Technical information is optional.

Do not include:

  • passwords;
  • API keys;
  • other credentials or secrets;
  • full payment-card information;
  • confidential source materials;
  • protected health information; or
  • unnecessary personal or medical information.

13. Alternative Access and Accommodation

If an accessibility barrier prevents you from accessing information or completing a task, tell us what you were trying to do and the type of assistance that would be useful.

Where reasonably possible, Addienator will work with you to identify an alternative, which may include:

  • providing information in a different electronic format;
  • explaining a process through support;
  • helping identify an alternative workflow;
  • providing an accessible copy of public information;
  • assisting with an account or support task; or
  • documenting the barrier for remediation.

The available alternative will depend on:

  • the nature of the request;
  • the affected feature;
  • technical feasibility;
  • security requirements;
  • privacy requirements;
  • third-party limitations; and
  • the user’s preferred method of access.

Addienator will not ask a user to send credentials or confidential project content through a public form as a condition of receiving accessibility assistance.

14. How We Review Accessibility Feedback

When Addienator receives an accessibility report, we will use reasonable efforts to:

  1. acknowledge the request;
  2. identify the affected page, feature, or workflow;
  3. review the reported barrier;
  4. request additional optional context where needed;
  5. determine whether an immediate workaround is available;
  6. assess whether a product, content, or third-party correction is required;
  7. communicate material findings or next steps where appropriate; and
  8. record the issue for follow-up when it cannot be resolved immediately.

The time needed to investigate or correct a barrier depends on its nature, technical complexity, security implications, third-party involvement, and effect on other users.

Addienator does not guarantee a specific correction or resolution time unless a separate written agreement or applicable law requires one.

Reports concerning urgent access to an account, subscription, or essential information should clearly identify the urgency.

15. Privacy and Security of Accessibility Requests

The Contact and Support form requires consent before submission.

Accessibility requests are used to:

  • understand the reported barrier;
  • respond to the person making the request;
  • provide available assistance;
  • investigate the affected feature; and
  • improve accessibility where appropriate.

The form uses automated spam-prevention controls.

The submitter’s IP address is not stored as part of the Contact and Support form entry.

Do not send credentials, payment information, or confidential source material through the form.

Personal information submitted with an accessibility request is handled according to the Addienator Privacy Policy.

16. Changes to This Statement

Addienator may update this Accessibility Statement to reflect changes to:

  • the website;
  • the protected application;
  • supported user journeys;
  • accessibility standards or guidance;
  • third-party services;
  • known limitations;
  • contact methods; or
  • accessibility-review practices.

The revised Statement will be posted on this page with an updated effective date and last-reviewed date.

A change to this Statement does not reduce or limit a right that cannot lawfully be excluded.

17. Contact Us

Accessibility reports, requests for alternative access, and questions about this Statement may be directed to:

President

ATELIER ADDIE INC.

Suite 313, 43 Boul. Samson, Laval, Quebec, Canada H7X 3R8

Email:

support@addienator.com

You may also use the Contact and Support form and select:

Accessibility

Do not include passwords, API keys, other credentials, full payment-card information, or confidential source materials in your request.