Accessibility

WCAG 2.1 Level AA is our adopted working standard. Component-level behavior follows the WAI-ARIA Authoring Practices, and our design system requires WCAG AA contrast minimums (4.5:1 for normal text, 3:1 for large text) in both light and dark themes, with visual hierarchy carried by weight and size rather than color alone.

Our self-assessed VPAT® 2.5 Accessibility Conformance Report (WCAG 2.1 Levels A and AA, dated August 2026) is available to evaluating institutions on request via the accessibility contact below. No criterion is rated "Does Not Support"; items rated "Partially Supports" make up the known limitations listed on this page. The report is a self-assessment — a third-party audit is planned as institutional adoption grows, and we do not claim independently verified conformance.

Accessibility characteristics are properties of the standard interface — there is no separate "accessibility mode," lite version, or overlay, and none is planned.

• All interactive components (dialogs, menus, selects, tabs, forms) are built on primitives that implement the WAI-ARIA design patterns: keyboard interaction, focus management, roles, states, and screen-reader semantics.
• Form fields expose validation state to assistive technology, with error text programmatically associated to its field.
• Loading and status indicators use ARIA live-region semantics with screen-reader-only text, and animation respects prefers-reduced-motion.
• Static accessibility lint rules run automatically on every code change, and manual QA exercises the application through the browser accessibility tree — the same representation assistive technologies consume.

Standard keyboard patterns apply throughout the interface:

• Tab / Shift+Tab moves focus between interactive elements.
• Enter or Space activates buttons and links.
• Escape closes dialogs and menus.
• Arrow keys move within menus, tab lists, and select options.

Every card on the recruiting board is a button — Enter or Space opens the recruit's details. Each card also has a drag handle: Tab to it, pick the card up with Space, move it with the arrow keys, drop it with Space, or cancel the move with Escape. Moves are announced to screen readers with the athlete's name and the destination column.

We would rather document real limitations than claim conformance we have not verified. Known issues, tracked as defects in our engineering tracker — each carries a target timeline in our Accessibility Conformance Report, reviewed at every ACR revision and shared with institutions on request:

• Schools filter sliders lack accessible names — they are operable with arrow keys, but a screen reader does not announce what each slider controls. Workaround: the applied filter values are visible as text beside each slider.
• Schools "show more" loads additional results without a screen-reader announcement. Workaround: newly loaded results append to the end of the list and are reachable by continuing to Tab through it.
• Profile section navigation does not announce which section is currently active. Workaround: the section heading inside the panel identifies it.
• Schools sort control has a reduced focus indicator compared to the rest of the interface.
• Formal verification pending for 200% zoom/reflow, text-spacing overrides, end-to-end screen-reader task runs, and a systematic autocomplete-attribute audit for identity fields — these are rated "Partially Supports" in the ACR until verified, and undiscovered nonconformances may exist at the edges of the interface.

Accessibility barriers are triaged as defects, not feature requests — a barrier that blocks task completion is prioritized like a functional defect and fixed under our standard defect workflow.

To report an issue, contact our accessibility contact directly. It helps to include the page you were on, what you were trying to do, and the assistive technology or input method you were using.

Accessibility contact: Adam Paslawski, Chief Technology Officer
Email: adam@joinrosterly.com

Institutions evaluating Rosterly are welcome to share the findings of their own accessibility evaluations — we treat them as direct input to our remediation queue.

We review this statement at least annually and update it as conformance work progresses — keeping the ACR's revision current, revising the known limitations above as fixes ship, and updating both after the planned third-party assessment.