Accessibility Statement

Our direction

ASCA aims to make public, account, organization, and operational experiences usable by people with disabilities across common devices and assistive technologies.

The current product specification targets WCAG 2.2 Level AA for public and administrative surfaces. This is a design and testing target, not a certification claim.

Practices

ASCA’s interface standards include:

• Logical headings and reading order.
• Keyboard access and visible focus.
• Accessible names, labels, instructions, errors, and status messages.
• Readable text size, spacing, contrast, and zoom behavior.
• Reduced-motion support and alternatives to motion-dependent meaning.
• Responsive layouts without clipped text or controls.
• Meaningful links, table headers, and document structure.
• Captions, transcripts, or alternatives where applicable.
• Touch targets suitable for mobile and field use.

Operational accessibility

Organizations remain responsible for the accessibility of their own content, events, venues, services, communications, and configured workflows.

ASCA features can help record accommodations and eligibility decisions, but ASCA does not diagnose a disability, determine legal eligibility, guarantee a venue accommodation, or replace an organization’s required interactive process.

Third-party content

Connected services, payment flows, embedded content, documents, and organization-created pages may have separate accessibility limitations. ASCA works to reduce avoidable barriers but cannot control independent services.

Compatibility and testing

ASCA evaluates common combinations of current browsers, operating systems, screen sizes, keyboard navigation, zoom, reduced-motion preferences, and assistive technologies in proportion to the feature and risk. A particular combination may behave differently because browsers, devices, extensions, connected services, and assistive technologies change independently.

Testing may include automated checks, semantic and keyboard review, contrast and reflow evaluation, screen-reader spot checks, content review, production monitoring, and feedback from people encountering barriers. Passing an automated check does not establish complete accessibility.

Known limitations and alternatives

ASCA will document a material known barrier when doing so helps affected users and does not expose a security weakness. The notice may identify the affected feature, impact, available alternative, remediation status, and update route.

When a feature cannot be used accessibly, ASCA will seek a practical alternative that provides substantially equivalent access where available. An alternative does not replace remediation when the original barrier remains within ASCA's responsibility and can reasonably be corrected.

Feedback

If you encounter a barrier, contact [email protected] and include:

• The page or feature.
• What you were trying to do.
• The device, browser, and assistive technology if you are comfortable sharing.
• A preferred contact method.

Do not include medical records or unrelated sensitive information. ASCA will review the issue, identify a practical alternative when available, and route product defects for remediation.

Accessibility requests receive a case record and are routed according to the affected service and urgency. ASCA may ask focused follow-up questions needed to reproduce the barrier or identify an alternative, but a person is not required to disclose a diagnosis or unrelated medical information.

Retaliation for raising a good-faith accessibility concern or requesting an available accommodation is prohibited. Abuse of the channel, threats, spam, or attempts to obtain unauthorized records remain subject to the Acceptable Use Policy.

Ongoing review

Accessibility is evaluated during design, implementation, automated checks, manual review, production monitoring, and user feedback. ASCA responds under this statement and applicable law. Jurisdiction-specific notices and procedures apply where required.