Accessibility at AraSync

Our Commitment

AraSync Health Systems is committed to making its web application and mobile apps usable by people with disabilities, including the clinicians, schedulers, billers, direct support staff and administrators who use AraSync every working day.

We treat the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA and Section 508 as our design target. Accessibility work is done inside our normal release cycle rather than as a separate project, and roughly twenty releases in the last six months included accessibility changes.

Conformance Status: Partially Conformant, Self-Assessed

We want to be precise here, because procurement teams rely on this page.

• AraSync has not completed a third-party accessibility audit. No independent firm has assessed the platform against WCAG 2.1 AA or Section 508.
• AraSync does not currently publish a VPAT^® or Accessibility Conformance Report. We will not claim one until an assessment has actually been performed.
• We do not claim a formal WCAG 2.1 AA conformance level. Our status is best described as partially conformant, self-assessed: substantial accessibility work has been implemented and reviewed internally by our engineering team, but it has not been externally validated, and coverage is not uniform across every screen.

If you are evaluating AraSync for a county, state or federal solicitation that requires a completed VPAT or an independent audit, please contact us. We will tell you honestly where we stand and what we can commit to on what timeline, rather than sending you a conformance claim we cannot support.

What Has Been Implemented

The following are shipped in the AraSync web application today. Each is described at the level of what a user of assistive technology would actually encounter.

Screen Reader Support

• Accessible names on controls. Interactive controls throughout the application carry aria-label or an associated visible label, so a screen reader announces the control's purpose rather than reading its icon.
• Decorative graphics are hidden. Icons and ornamental SVGs are marked aria-hidden so they are not announced as noise between meaningful content.
• Status badges carry text. Our shared status badge component includes visually hidden (sr-only) text, so a status conveyed by color to sighted users is also conveyed in words to a screen reader. This component is used across the administration pages.
• Live regions for asynchronous updates. Content that changes without a page reload (alert and notification counts, save and submission status, in-flight loading states) is announced through aria-live regions and role="status" / role="alert", rather than changing silently.
• Loading states are exposed. Regions that are fetching data are marked aria-busy so assistive technology knows content is in flux.

Keyboard Navigation

• The application is operable by keyboard. Explicit key handling is implemented across the interface, not left to browser defaults alone.
• Patient search supports arrow-key navigation. The clinical patient search is built as an ARIA combobox with a listbox popup: results are reachable with the arrow keys, the active option is exposed with aria-selected, Enter selects, and Escape dismisses.
• Dialogs trap and restore focus. Modal dialogs are marked role="dialog" with aria-modal and are labelled by their heading, so focus stays inside the dialog while it is open and the dialog's purpose is announced on open.
• Focus indicators are preserved. Visible focus rings are retained rather than suppressed for visual polish, including inside tabbed interfaces.
• A command palette provides keyboard-first navigation. Staff can reach patients, pages and actions without using a pointing device, including recently viewed patients and saved favorites. A keyboard shortcuts help panel documents the available bindings.

Structure and Orientation

• Landmark regions. Navigation, main content and complementary regions are marked with semantic landmarks so screen reader users can jump between them instead of reading linearly.
• Current location is exposed. The active navigation item and the current breadcrumb are marked with aria-current.
• Expandable regions report their state. Collapsible form sections, menus and disclosure controls expose aria-expanded, and toggle controls expose aria-pressed.

Forms and Data Entry

• Labels are programmatically associated. Form fields are tied to their labels rather than relying on visual proximity, so clicking a label moves focus to its field and a screen reader announces the two together.
• Accessible date and time inputs. Date and time entry uses native, labelled inputs that work with the operating system's own accessibility features and with keyboard entry.
• Required fields and descriptions are announced. Fields use aria-required and aria-describedby so requirements and helper text reach assistive technology, not only sighted users.
• Grouped controls are grouped semantically. Related choices use role="radiogroup", role="group" and role="switch" so their relationship is conveyed rather than implied by layout.

Data Tables

• The shared data table exposes sort state through aria-sort, supports keyboard-operable column resizing, and lets users hide columns they do not need, which reduces the amount of content a screen reader user has to move through on dense billing and roster screens.

Color and Contrast

• AraSync ships a light and a dark theme, and status information is not conveyed by color alone: status badges carry both a color and a text label.
• We have run dedicated contrast and dark-mode passes over the administration, leave management, reporting and clinical form areas.

Mobile Apps

• The AraSync iOS and Android apps use platform accessibility APIs: controls carry accessibilityLabel and accessibilityRole so VoiceOver and TalkBack announce them meaningfully.
• Modal layouts are adjusted to stay clear of the on-screen keyboard, so fields do not become unreachable during entry.
• Biometric sign-in (Face ID, fingerprint) is supported, which removes password entry as a barrier for some users.

Known Limitations

Stating these is part of an honest accessibility statement.

• Coverage is not uniform. Accessibility work has been applied screen by screen. Newer and less-trafficked screens have had less attention than the core clinical, scheduling and administration areas.
• No automated accessibility testing in CI. We do not currently run an automated accessibility linter or test suite on every build, so regressions are caught by review rather than by tooling.
• No formal assistive-technology test matrix. We have not published results of testing against a defined set of screen reader and browser combinations.
• Generated PDFs. Clinical and billing documents produced by AraSync are laid out to match required paper forms. These PDFs are not yet fully tagged for accessibility.
• Third-party content. Some embedded third-party components, such as the map on our contact page, are outside our direct control.

Report an Accessibility Barrier

If you encounter a barrier in AraSync (in the web application, the mobile apps, or on this website), please tell us. Reports from people using the product are the most reliable input we get.

Where you can, include the page or screen, the assistive technology and browser or device you were using, and what you expected to happen. We will acknowledge your report and tell you what we intend to do about it and when.

AraSync Health Systems
130 Division Street, Suite D
Waite Park, MN 56387
Email: info@arasynchealth.com
Phone: (669) 278-5128

We aim to acknowledge accessibility reports within 2 business days. If a barrier blocks you from completing required work in the product, say so in your message and we will treat it as urgent.

Procurement and RFP Requests

If your solicitation requires accessibility documentation, contact info@arasynchealth.com and tell us which artefact you need: a completed VPAT, an independent audit report, a remediation plan, or a written accessibility commitment. We will respond with what exists today and what we can commit to producing, in writing, with dates.

Review of This Statement

This statement describes AraSync as built at the time of writing. It is reviewed as accessibility work ships, and is revised rather than left to drift. It is a statement of ongoing commitment and current implementation, not a certification.