Accessibility Statement

Current verification state Accessibility verification is not complete yet. IT Modality must not claim site-wide conformance while the public route set, forms, system states, content, and manual assistive-technology checks remain untested or incomplete. The barrier contact must still be available through an accessible tested route before public forms open.

Current issues, not a blank assurance

Name the impact and the usable alternative.

Verification-pending limitation
The public route set is reviewed through keyboard, screen-reader semantics, reduced-motion, contrast, zoom, responsive, and automated accessibility checks. Issues can be reported through the contact path and are tracked to resolution.

Third-party pages, submitted external links, and tools may have their own accessibility limitations. IT Modality must provide an accessible way to complete its own required action or keep that action unavailable; linking to a third party does not transfer responsibility or prove support.

Tell us what stopped you

You do not need to disclose a diagnosis.

Use the accessibility topic in the contact form. Helpful details include the page or task, what you expected, what happened, and—only if you choose—the browser, device, or assistive technology involved. Do not send health records, diagnosis documents, patient information, passwords, identity documents, financial/tax records, confidential artifacts, or another person's private information.

Report an accessibility barrier

Email hello@itmodality.com. This is the public non-form accessibility and recovery route. No response time is promised.

What happens next
After a durable server receipt, the request is restricted to the responsible accessibility/support role. The record identifies the affected route/task, the current workaround or investigation state, and the communication path. IT Modality confirms only actions the system and owner have actually completed.

Receipt boundary
Receipt is not a promise of response time, repair date, requested adjustment, admission, assessment outcome, client consideration, work, or other result. If the form cannot confirm receipt, it retains safe values in memory only where possible and offers the tested alternate route.

Accessible paths without decision advantage

Access support and evaluation remain distinct.

Professional application and The Rigors

An applicant may request an accessible application or assessment path without providing a diagnosis through the public form. The accessibility owner receives the request; a reviewer receives only the approved adjustment needed for the assigned stage. The implemented process must preserve the same published construct, evidence standard, scoring meaning, integrity, and no-guarantee boundary while changing an access method where appropriate.

An accommodation request, grant, denial, or support interaction is not a positive or negative work-selection signal. It does not promise an assessment invitation, pass, network consideration, client review, engagement, timing, employment, placement, or income.

Review The Rigors
Open the professional application

Academy application and learning

An Academy applicant may request an accessible application or learning-support path without submitting a diagnosis through the public form. The course page must state the real format, materials, media, tools, schedule, participation, assessment, feedback, and support so a learner can evaluate fit before admission or payment.

An Academy access request remains inside the Academy/support purpose and is denied to Rigors scoring and client-selection roles. It does not create admission, scholarship priority, completion, assessment preference, work access, placement, income, or another outcome.

Open the bootcamp application

Privacy link
Review form privacy

Test after meaningful change

The statement changes with the site.

A new or materially changed route, navigation pattern, form field/state, component, modal, diagram, table, media item, download, third-party tool, font, color token, motion pattern, authentication state, or content structure triggers proportionate accessibility testing before release. A reported barrier, failed test, or changed assistive-technology behavior triggers triage, repair/suppression, retest, and a statement update where material.

The accessibility owner records scope, methods/environments, results, limitations, issue owners, alternatives, test/review dates, and the next review trigger. Automated checks support this process; they do not replace manual keyboard, screen-reader, zoom/reflow, content, and task review.

Visit the Trust Center
Return to legal and policies