Accessibility Statement

The Web Content Accessibility Guidelines (WCAG) define requirements for making web content more accessible to people with disabilities, at three levels: A, AA, and AAA. Our target for Cadets is WCAG 2.1 Level AA.

Cadets is currently partially conformant with WCAG 2.1 Level AA.

“Partially conformant” is a defined term, and we use it in its exact sense: some parts of the service do not fully meet the Level AA success criteria. It is not a way of saying “mostly fine”. Claiming full conformance would require us to have verified every success criterion against every page and interactive component of the platform, and we have not done that yet. We would rather publish an accurate partial claim than an unverified full one, particularly to schools that must evaluate this product against their own accessibility obligations.

We have also not yet completed a formal third-party accessibility audit. The assessment behind this statement is self-evaluation carried out by our own team, described in section 7. Anyone relying on this statement for a procurement decision should weigh it accordingly.

This statement applies to the Cadets web application at allcadets.com, including the marketing pages, the sign-in and registration flows, the Cadet dashboard, unit and structure views, task management, and the administrative screens used by instructors and platform staff.

It does not cover third-party interfaces embedded in or linked from the service, whose accessibility is determined by their providers. In particular, payment is handled by Stripe’s hosted interface, and authentication is provided through Google Firebase. Where a third-party component blocks a user from completing a task, we still want to hear about it — we will work with the provider or find another route for you.

It also does not cover documents, spreadsheets, or other files that a school or instructor uploads or distributes. Those are authored by the school, and their accessibility is the school’s responsibility.

Accessibility is addressed during development rather than retrofitted afterwards. Concretely:

• Design review. Interface designs are reviewed for accessibility before implementation begins — checking that interactive elements have adequate target sizes, that information is not carried by colour alone, that focus order will follow a sensible reading order, and that error states are described in text rather than signalled only by a red outline.
• Semantic markup. Pages are built with native HTML elements that carry their meaning: real headings in a logical order, real lists, real tables with header cells for tabular data such as unit rosters and task lists, real buttons and links, and form controls with associated labels. Native elements are preferred over custom widgets because they bring keyboard and assistive-technology behaviour with them.
• Keyboard navigation. Interactive functionality is expected to be operable without a mouse. We check that focus is visible, that focus order matches the visual order, that dialogs trap and then restore focus correctly, and that no component creates a keyboard trap.
• Colour-contrast checks. Text and meaningful non-text elements are checked against the Level AA contrast ratios — 4.5:1 for body text, 3:1 for large text and for user-interface components and graphical objects. Contrast is checked as part of design review and again against the built interface, since implementation can shift a colour off its intended value.
• Text alternatives and structure. Images that convey information carry text alternatives; decorative images are marked so assistive technology skips them. Page titles, landmark regions, and the document language are set so screen-reader users can orient themselves.
• Responsive and zoomable layouts. Layouts are built to reflow rather than break at 200% zoom and at narrow viewport widths, so magnification does not force two-dimensional scrolling.
• Accessibility in our definition of done. A new feature is not considered complete until it has been operated by keyboard and its contrast checked. Accessibility defects are logged in the same tracker as other defects, not in a separate backlog that never gets scheduled.

Accessibility of Cadets relies on the following technologies working with the combination of your web browser and any assistive technology or plugins you have installed:

• HTML — for document structure, semantics, and native interactive controls.
• CSS — for presentation, layout, reflow, and visible focus indication.
• JavaScript — for interactive behaviour, client-side validation, and dynamic updates.
• WAI-ARIA — for roles, states, and properties on components where native HTML semantics are insufficient, and for announcing dynamic changes through live regions.

These technologies are relied upon for conformance. JavaScript in particular is required: Cadets is a JavaScript application and core functionality is not available with scripting disabled.

Cadets is designed to work with current versions of major browsers on desktop and mobile, and with the screen readers commonly paired with them. Because we have not yet completed a formal audit, we do not publish a list of specific assistive-technology and browser combinations as tested and supported — naming a combination implies a level of verification we cannot yet stand behind. That list will be added once the audit in section 7 is complete.

The service is not known to be compatible with browsers more than two major versions old, or with operating systems no longer receiving security updates. This is a common constraint on school-managed devices; if it affects your program, contact us and we will look at what we can do.

Despite our best efforts, some content or functionality may fall short of Level AA. Known limitations are listed here, with the reason, the effect on users, the workaround if one exists, and when we expect to fix it.

Until this section is populated, treat the absence of a listed limitation as an absence of published information, not as evidence that a barrier does not exist. If you have hit one, please tell us — a reported barrier is the fastest route into this list and into the fix queue.

{{LEGAL_ENTITY}} assessed the accessibility of Cadets by self-evaluation. This was carried out internally by the team that builds the product, and comprised:

• Review of pages and components against the WCAG 2.1 Level AA success criteria.
• Automated checks using browser-based accessibility tooling, which reliably catch missing labels, contrast failures, and structural errors but cannot judge whether content makes sense in context.
• Manual keyboard-only operation of the main user journeys: registering, signing in, viewing a dashboard, working through assigned tasks, and navigating unit and structure views.
• Manual inspection of headings, landmarks, form labelling, and error messaging.

Self-evaluation has real limits. It is performed by people who already know how the interface is meant to work, which makes discoverability problems easy to miss, and it does not substitute for testing with disabled users and their own assistive technology configured the way they actually use it. A formal third-party accessibility audit has not yet been completed. Commissioning one, and publishing an Accessibility Conformance Report based on it, is on our roadmap; we are not giving a date here that we cannot yet commit to. When it is done, this statement will be updated to describe the audit, its scope, and who performed it.

We welcome feedback on the accessibility of Cadets. If you meet a barrier, please tell us — reports from users are the single most useful input we get.

• Email: support@allcadets.com
• Postal: {{LEGAL_ENTITY}}, {{POSTAL_ADDRESS}}

Please put “Accessibility” in the subject line, and if you can, include the page or feature involved, what you were trying to do, what happened instead, and the browser, operating system, and assistive technology you were using. Do not include a Cadet’s personal details beyond what is necessary to identify the problem.

We aim to respond within 5 business days. Our first response will either resolve the issue, offer a workaround, or tell you what we are doing and when to expect an update. If a barrier is preventing a Cadet from completing required work, say so — we will prioritise it and, where we cannot fix the software quickly enough, we will find another way for that Cadet to complete the task rather than leaving them stuck.

You may also request information from the service in an alternative accessible format. There is no charge for this.

If you are not satisfied with our reply, or if we do not respond within 5 business days, escalate as follows:

1. Reply to your original email with “Accessibility escalation” in the subject line. Escalated reports are reviewed by someone other than the person who handled the original, and we aim to give a written outcome within 10 business days.
2. If the outcome is still unsatisfactory, write to {{LEGAL_ENTITY}} at {{POSTAL_ADDRESS}}, marked for the attention of the person responsible for accessibility.
3. If you are a Cadet, parent, or guardian, you may also raise the matter with your school or district, which has its own obligations regarding accessible instructional materials and its own complaints procedure. Raising it with the school does not stop us working on it.
4. You retain any right you have to complain to a regulator or to pursue a remedy under federal or state law. Nothing in this statement limits those rights, which are governed by the law of United States and by any law applicable where you live.

Privacy questions belong at privacy@allcadets.com, safeguarding concerns at safeguarding@allcadets.com, and security vulnerability reports at security@allcadets.com.

Cadets is an independent product and is not affiliated with, endorsed by, or sponsored by the U.S. Department of Defense or any branch of the U.S. Armed Forces.