acelyBack to Acely
ACCESSIBILITY

Studying should work for everyone.

Last updated August 11, 2026

Acely is being built with accessibility as a product requirement, not as an overlay. Our target is strong conformance with widely used WCAG Level A and AA practices, followed by manual testing with keyboard and assistive-technology workflows.

Current accessibility work

  • Visible keyboard focus indicators for interactive controls.
  • Keyboard-operable buttons, links, forms, navigation, and study interactions.
  • Semantic headings and form labels where applicable.
  • Reduced-motion support for people who request less animation at the operating-system level.
  • Support for browser zoom and responsive layouts.
  • Text and status cues that do not rely only on color.
  • High-contrast and forced-color compatibility improvements.
  • Descriptive labels for icon-only controls where needed.

Ongoing testing

Automated accessibility checks can catch useful issues, but they cannot prove that a product is accessible. Before broad public launch, Acely should also be manually checked using keyboard-only navigation, browser zoom, screen-reader workflows, focus order, form errors, modals, generated study content, and mobile layouts.

Uploaded and generated content

Acely will work to present generated study content in accessible text-first interfaces. User-uploaded files may themselves contain inaccessible formatting. When possible, Acely extracts and presents readable text rather than requiring users to interact only with the original file.

Reporting a barrier

If a disability-related barrier prevents you from using Acely, we want to correct it. A dedicated public support contact should be displayed before commercial launch. Account holders can also use available account controls while we finish that support channel.

Terms of UsePrivacy PolicyHome