Building digital experiences more people can use successfully.

Accessibility is part of responsible enterprise design.

Elizian is intended to support healthcare organizations, professionals, administrators, providers, partners, patients, families, caregivers, and other users with different abilities, technologies, devices, and interaction needs.

We work to make Elizian experiences

• Perceivable.
• Operable.
• Understandable.
• Robust.
• Keyboard accessible.
• Screen-reader compatible.
• Responsive across supported devices.
• Usable without unnecessary motion.
• Understandable without relying only on color.
• Clear when errors, status changes, or required actions occur.

Accessibility is not treated as a one-time design task. It is considered across content, interfaces, development, testing, documents, integrations, customer configuration, support, and ongoing improvement.

When an accessibility barrier is identified, Elizian evaluates the user impact, affected experience, available workaround, technical dependencies, and appropriate remediation.

WCAG 2.2 Level AA guides our accessibility approach.

Elizian’s current design and development target is alignment with the Web Content Accessibility Guidelines 2.2 at Level AA for digital experiences under our control.

WCAG provides recommendations intended to improve access for people with visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

This statement describes Elizian’s accessibility objective and operating approach. It is not a representation that every page, document, feature, integration, legacy component, or customer-configured experience satisfies every WCAG success criterion at all times.

Where customer contracts, public-sector requirements, implementation agreements, or applicable law establish additional accessibility requirements, those obligations may be addressed through the relevant implementation and governance process.

Perceivable

Information and interface elements should be presented in ways users can perceive.

Operable

Navigation and controls should be usable through supported input methods.

Understandable

Content, instructions, navigation, and errors should be reasonably clear and predictable.

Robust

Content should be structured to work with supported browsers, devices, and assistive technologies.

Accessibility practices incorporated into Elizian.

Core navigation should not require a mouse.

Elizian works to support keyboard navigation across the public website and core platform interface patterns.

Accessibility practices include

• Logical keyboard order.
• Visible keyboard focus.
• Skip-to-content links.
• Keyboard-operable links and buttons.
• Accessible dropdown menus.
• Keyboard-operable tabs.
• Keyboard-operable accordions.
• Keyboard-operable modal dialogs.
• Escape-key support for dismissible overlays where appropriate.
• Focus containment while a modal is open.
• Focus return after a modal closes.
• Avoidance of keyboard traps.
• Alternatives to drag-only interaction.
• Keyboard access to data-table controls.
• Keyboard access to form validation and error messages.

Some complex customer-configured, embedded, or third-party experiences may require additional accessibility review.

Forms should explain what is required and what happened.

Elizian works to make public forms and platform workflows understandable and operable for users of assistive technology.

01

Visible Labels

Every form field should have a visible label or another clear accessible name.

02

Instructions

Required format, purpose, and completion instructions should be provided before they are needed.

03

Required Fields

Required fields should be identified in text and programmatically.

04

Error Identification

Validation errors should identify the affected field and explain how to correct the issue.

05

Error Summary

Longer forms should provide an accessible error summary when multiple issues occur.

06

Focus Management

Focus should move appropriately when errors, confirmation messages, or modal interactions occur.

07

Status Confirmation

Successful submission, processing, saving, or completion should be communicated clearly.

08

Touch Targets

Interactive controls should provide sufficient target size and spacing where practical.

09

Time Limits

Time limits should be avoided or made adjustable where possible. When a security or workflow time limit is necessary, users should receive appropriate notice where practical.

10

Autocomplete

Common personal-information fields should use supported autocomplete attributes where appropriate.

11

No Disability Disclosure Requirement

Users should not be required to provide a medical diagnosis, disability documentation, or proof of disability to report an accessibility barrier.

Clear visual design supports access and understanding.

Customer-provided branding, uploaded content, charts, and custom configurations may affect visual accessibility and should be reviewed during implementation.

01

Typography

Readable typefaces, reasonable font sizes, appropriate line spacing, and controlled line length.

02

Contrast

Text, controls, status indicators, and important interface boundaries should maintain sufficient contrast.

03

Zoom and Text Resizing

Content should remain usable at supported browser zoom and text-resizing levels without unnecessary horizontal scrolling or loss of function.

04

Spacing

Content, controls, headings, fields, and sections should use sufficient spacing to support scanning and comprehension.

05

Visual Hierarchy

Headings, labels, section groupings, and emphasis should communicate clear structure.

06

Color Use

Color may reinforce meaning but should not be the only method used to communicate status or instructions.

07

Responsive Layout

Content should adapt to smaller screens without forcing users to pinch, zoom, or scroll horizontally for ordinary reading.

Users should have control over nonessential movement and time-based content.

01

Reduced Motion

Elizian-supported experiences should respect reduced-motion preferences where implemented.

02

Animation

Nonessential animations should be limited and should not interfere with reading, navigation, or task completion.

03

Flashing Content

Elizian does not intentionally design content to flash in a manner known to create seizure risk.

04

Autoplay

Audio and video should not begin automatically with sound unless clearly justified and controllable.

05

Pause and Stop

Moving or updating content should provide pause, stop, or hide controls when required.

06

Captions

Newly published prerecorded video with meaningful spoken content should include captions where applicable.

07

Transcripts

Audio and video content should include transcripts or another equivalent alternative where appropriate.

08

Audio Description

Important visual information in media should be described through narration, text, or another suitable alternative when required for understanding.

09

Time Limits

Time-based interactions should provide adjustment, extension, warning, or an alternative when practical and appropriate.

Accessibility extends beyond web pages.

01

PDF and Downloadable Documents

Elizian works to provide logical headings, meaningful titles, selectable text, appropriate reading order, accessible links, and image descriptions in newly published documents where practical.Some legacy or third-party documents may not yet include complete accessibility structure.

02

Spreadsheets and Tables

Tabular information should use clear headings, meaningful labels, logical reading order, and accompanying explanation where necessary.

03

Charts and Diagrams

Important meaning should be provided through labels, summaries, accessible data, or accompanying text rather than visual presentation alone.

04

Resource Downloads

A user who cannot access a published resource may request a plain-text, accessible PDF, large-print, transcript, or other reasonable alternative.

Core enterprise workflows should remain usable across different interaction needs.

Elizian’s authenticated platform may include dashboards, queues, tables, case records, forms, tabs, filters, notifications, messaging, provider workflows, readiness workflows, analytics, and administrative tools.

Elizian works to support accessibility across core platform patterns through:

• Semantic navigation.
• Accessible page titles.
• Structured headings.
• Keyboard-operable controls.
• Accessible filters.
• Accessible tabs.
• Accessible accordions.
• Labeled inputs.
• Error handling.
• Focus management.
• Status messaging.
• Responsive layouts.
• Accessible data-table structures.
• Non-color status indicators.
• Reduced-motion support.
• Accessible confirmation and escalation states.

The accessibility of a specific enterprise deployment may also depend on customer configuration, customer-provided content, integration behavior, uploaded documents, terminology, external systems, and the use of custom components.

Customer configuration can affect accessibility.

Enterprise customers may configure workflows, labels, forms, dashboards, communications, documents, integrations, reports, and user roles within Elizian.

Customer-controlled elements may include

• Uploaded documents.
• Custom instructions.
• Custom labels.
• Form questions.
• Email content.
• Reports.
• External links.
• Embedded systems.
• Data tables.
• User-generated content.
• Customer branding.
• External portal content.

Accessibility may vary across external services.

Elizian may link to, embed, or integrate with services operated by third parties. These services may have their own accessibility capabilities, limitations, documentation, and support processes.

Third-party examples may include only active or relevant services such as

• Identity providers.
• Scheduling tools.
• Video services.
• Document viewers.
• Maps.
• Webinar platforms.
• Customer-support tools.
• Payment services.
• External healthcare systems.
• Customer-selected integrations.

When a reported barrier involves a third party, Elizian may

• Help identify the affected provider.
• Offer an available alternative.
• Review configuration options.
• Escalate the concern to the provider.
• Coordinate with the customer.
• Consider accessibility in future vendor evaluation.
• Address the Elizian-controlled portion of the integration.

This section does not remove Elizian’s responsibility for the portions of the experience it controls.

Accessibility work continues as technology and user needs evolve.

Elizian continues to evaluate its website, content, documents, forms, platform experiences, and integrations. Accessibility barriers may be identified through testing, customer implementation, technology changes, third-party services, or user feedback.

Potential areas requiring continued attention may include

• Legacy documents.
• Complex data visualizations.
• Third-party embedded tools.
• Customer-provided documents.
• Customer-configured workflows.
• Newly released features.
• External integrations.
• Large data tables.
• Dynamic status updates.
• Specialized healthcare workflows.

The absence of a listed issue does not mean that no accessibility barrier exists. Users are encouraged to report any difficulty they encounter.

Request another way to access information or complete a task.

A user who cannot access information or complete a task through the available digital experience may request an alternative method or format.

Available requests may include

• Plain-text content.
• Accessible PDF.
• Large-print document.
• Transcript.
• Captions.
• Information by email.
• Assistance navigating a page.
• Help completing a public form.
• A telephone-based alternative where available.
• Another reasonable format appropriate to the information.

Elizian will consider the information requested, urgency, available formats, security and privacy requirements, technical feasibility, and the user’s stated access need.

What happens after an accessibility report.

1. Step 1

   Receive

   The report is recorded and routed to the appropriate Elizian team.

2. Step 2

   Acknowledge

   Elizian confirms receipt when contact information and a response request are provided.

3. Step 3

   Assess

   The affected experience, user impact, severity, reproducibility, customer environment, and available alternatives are evaluated.

4. Step 4

   Respond

   Elizian may provide guidance, request additional information, offer an interim alternative, or identify a third-party dependency.

5. Step 5

   Remediate

   Where Elizian controls the affected experience, corrective action is prioritized according to impact, feasibility, dependencies, risk, and available resources.

6. Step 6

   Verify

   Changes are reviewed to determine whether the identified barrier has been addressed.

7. Step 7

   Follow Up

   The reporter may be informed of the status, resolution, or available alternative when appropriate.

Resolution timing varies according to the issue, affected service, security or privacy requirements, customer environment, third-party dependencies, and technical complexity.

Updates to this Accessibility Statement.

Elizian may update this Statement as its website, platform, accessibility practices, standards, support processes, and technology evolve.

When a new version is published

• The last-reviewed date will change.
• The version number will change.
• Material changes may be summarized.
• The current Statement will replace the previous public version.
• Archived versions may be maintained where appropriate.