Web Accessibility Statement

Effective from September 11, 2026

Applies to: the classe365.com marketing website and the authenticated Classe365 and Hiree365 platforms, for every user — students, learners, candidates, parents and guardians, teaching and administrative staff, and employers participating in an institution’s placement programme — across all customer segments: K-12 schools, universities and colleges, academies and vocational training providers, and corporates using the platform for corporate training.

1. Our commitment

1.1 Why this matters here

Our software is used to enrol students, deliver teaching, record attendance and assessment, communicate with families and place graduates into work. For the people who use it, it is not optional. A student cannot choose a different student information system. A parent cannot look up their child’s attendance somewhere else. A member of staff with a disability cannot do their job through an alternative interface.

That makes accessibility a condition of the product working at all, not a feature of it. We are committed to making Classe365 and Hiree365 usable by as many people as possible, including people who use screen readers, magnification, keyboard-only navigation, speech input, switch devices or other assistive technology, and people with visual, auditory, motor, speech or cognitive disabilities.

1.2 What this statement does

It sets out the standard we work to, how far we have got, what we have done, what we know is not yet right, how we assess our progress, and how to tell us when something does not work for you. It is written to be honest about the gaps, because a statement that claimed more than we have achieved would help nobody — least of all the person who then relied on it.

1.3 Which entity is responsible

Customers located in the United States contract with 365 Software, LLC, a Delaware limited liability company, registered office 131 Continental Dr, Suite 305, Newark, DE 19713, New Castle County, United States.

Customers located anywhere else — including the European Union, the United Kingdom, Australia and the rest of the world — contract with Sprout On Web Pty Ltd, ABN 72 138 602 418, registered office 22 Palm Street, St Ives, NSW 2075, Australia. Its business address is 22 Giffnock Avenue, Macquarie Park, NSW 2113, Australia.

Support and engineering services are provided by Classe365 India Pvt Ltd, 37, Venjay Edifice Complex, 3rd Floor, JLB Road, Chamarajapuram, Mysuru – 570 005, India.

Together we are “Classe365”, “we”, “us” and “our”.

1.4 What this statement replaces

This statement replaces our previous accessibility statement in full. That statement was published in February 2020, was measured against WCAG 2.1, and carried a company address that no longer reflects our contracting entities. This version is measured against WCAG 2.2 Level AA, states our conformance status honestly, and carries the correct entity details set out above.

2. The standard and our conformance status

2.1 The standard we work to

Our target is the Web Content Accessibility Guidelines (WCAG) version 2.2, Level AA.

WCAG is published by the World Wide Web Consortium and is the standard referenced by accessibility law and procurement policy in most of the jurisdictions our customers operate in. Level AA is the level those regimes generally require. WCAG 2.2 supersedes WCAG 2.1 and adds success criteria covering, among other things, focus visibility and appearance, target size for pointer inputs, dragging alternatives, consistent help, redundant entry and accessible authentication — criteria that matter a great deal in a system full of forms, tables and repeated administrative tasks.

2.2 Our current status

Partially conformant with WCAG 2.2 Level AA.

“Partially conformant” means that most of the standard is met, but not all of it. Some parts of our websites and platforms do not yet fully conform. Section 4 sets out where we know that to be the case.

We use the term deliberately. We are not fully conformant, and we do not describe ourselves as fully conformant. Where a conformance claim is limited, we say so plainly.

2.3 What partial conformance means for you

If you use assistive technology, most of the platform will work for you, and some parts may not work as well as they should. If you hit one of those parts, section 6 explains how to tell us and what we will do — including how we will help you complete the task in the meantime. You should not have to wait for a release to get your work done.

2.4 Scope of the claim

This claim covers the classe365.com marketing website and the authenticated Classe365 and Hiree365 platforms as we deliver them. It does not extend to the content an institution creates in its own tenant, or to third-party services an institution chooses to enable — section 4 explains both.

3. Measures we take to support accessibility

3.1 In how we build

Semantic, standards-based markup. We build with standard HTML elements and structure — headings, lists, landmarks, labels, tables with proper headers — so that assistive technology can interpret a page correctly, and we use ARIA to supplement that structure rather than to substitute for it.
Keyboard operability. Interactive elements are built to be reachable and operable by keyboard, with a visible focus indicator, so that a user who does not use a pointing device can complete a task.
Text alternatives. Images, icons and non-text controls are given text alternatives, and decorative images are marked so that screen readers can skip them.
Forms with real labels. Form fields are labelled programmatically, errors are identified in text as well as by colour, and instructions are associated with the field they describe. A student information system is largely made of forms, so this is where accessibility is won or lost.
Colour and contrast. We work to the Level AA contrast requirements, and we do not use colour as the only way of conveying information.
Resizing and reflow. Pages are built to remain usable when text is enlarged and when the viewport is small, so that magnification users are not forced to scroll in two directions.
Predictable structure. Navigation, controls and help are placed consistently across the platform, so that a pattern learned in one screen holds in the next.
Accessible authentication. We avoid requiring a cognitive function test to log in where an alternative is available.

3.2 In how we work

Accessibility is part of the development lifecycle, considered at design and review rather than added after release. New interface work is expected to meet the standard before it ships.
Automated checks are used to catch common, mechanically detectable failures early.
Manual testing — keyboard-only navigation and screen reader testing — is used for the things automation cannot judge, such as whether a reading order makes sense or an error message is genuinely useful.
User feedback is treated as evidence. A report from someone who cannot complete a task tells us more than any automated score, and reports are logged, prioritised and fixed alongside other defects.
Remediation is prioritised by impact. A barrier that stops a student submitting an assessment or a parent reading a report is treated as more urgent than a cosmetic issue, whatever the severity label a tool assigns it.

3.3 In what we ask of institutions

Some accessibility outcomes are in the institution’s hands, and we set them out in section 4.3 so that institutions can act on them.

4. Known limitations

We would rather list these than let you find them. The following are the areas where we know conformance with WCAG 2.2 Level AA is not yet complete.

4.1 In our own interfaces

Complex data tables and analytics displays. Screens presenting large tables, timetables, gradebooks, charts and dashboards are the hardest part of the platform to make fully accessible. Some of these do not yet provide an equivalent non-visual experience, and navigating a large table with a screen reader can be laborious. This is our largest known area of non-conformance and the one receiving the most attention.
Older screens. The platforms are long-standing products, and some older screens were built before the current standard and do not yet meet it in full. Common issues are inconsistent focus handling, controls that are difficult to operate by keyboard, and headings that do not reflect the structure of the page. These are being brought up to standard as those areas are revised.
Some interactive components. A small number of complex controls — certain date and calendar pickers, drag-and-drop arrangements and rich text editors — are not yet fully operable without a pointing device, or do not yet announce their state reliably to assistive technology. Where a drag interaction exists, we are working to make sure a single-pointer alternative is always available.
Documents generated by the platform. Some generated documents and exports, including certain reports and printable outputs, are not yet fully tagged for accessibility.
Small target sizes. In some dense administrative screens, pointer targets are smaller than the WCAG 2.2 Level AA target size criterion prefers.

4.2 Third-party components

Some parts of the experience are provided by third parties, and their accessibility is determined by those providers rather than by us:

Support messaging is provided through Intercom.
Payment pages are provided by Stripe and PayPal.
Optional proctoring, where an institution enables it, is provided by SMOWL under the institution’s own contract with SMOWL.

We raise accessibility issues with these providers when they are reported to us, and we take accessibility into account when we assess a provider. We cannot commit to a conformance level for software we do not build. If a third-party component is blocking you, tell us anyway — section 6 — and we will help you complete the task by another route.

4.3 Content created by institutions

A large part of what a user sees in the platform is content the institution has put there: course material, uploaded documents, images, videos, announcements, custom form fields and locally written instructions.

We cannot make institutional content conformant, because we do not create it. In particular, an image uploaded without a text alternative, a scanned PDF without a text layer, and a video without captions or a transcript will not be accessible regardless of how accessible the surrounding platform is.

What institutions can do:

give every uploaded image a meaningful text alternative;
upload text-based documents rather than scans, and tag them for accessibility;
caption video and provide transcripts for audio;
use the heading structure in the editor rather than styling text to look like a heading;
write link text that makes sense on its own, rather than “click here”; and
avoid conveying meaning by colour alone.

Institutions with an obligation of their own — under the Americans with Disabilities Act and Section 504, the Disability Discrimination Act 1992 in Australia, the European Accessibility Act and the EU Web Accessibility Directive, the Equality Act 2010 in the United Kingdom, or an equivalent regime — should treat their own content as within their responsibility and the platform as within ours.

4.4 Our approach to the list

This list is a statement of what we know today. It will change as we fix things and as testing and user reports find things we have not yet listed. We will keep it current rather than letting it become a historical record.

5. How we assess accessibility

5.1 Self-evaluation

Our current conformance status is based on our own evaluation, carried out by our team. It combines:

automated testing of pages and components against the WCAG 2.2 Level AA success criteria;
manual keyboard testing, confirming that tasks can be started, completed and recovered from without a pointing device;
screen reader testing of key workflows;
inspection against the WCAG 2.2 success criteria for the areas under review; and
review of feedback from users, which tells us where the standard and the lived experience diverge.

We say it is a self-evaluation because it is one. We have not commissioned a third-party audit of the platform, and we do not present our status as though we had.

5.2 Which workflows we prioritise

Testing focuses first on the tasks people cannot avoid: logging in; navigating the platform; viewing a timetable, attendance record or result; submitting work; completing enrolment and admission forms; making a payment; reading and sending messages; and, in Hiree365, completing a candidate profile and applying for an opportunity. A barrier in one of these blocks a person from participating in their education or their job search, which is a different order of problem from an inconvenience.

5.3 When we assess

Accessibility is reviewed as part of interface work before release, and we review this statement and the limitations in section 4 at least annually.

5.4 Conformance report available on request

A conformance report is available to institutions on request. It sets out our assessment against the WCAG 2.2 Level AA success criteria in the form procurement and compliance teams generally expect, and covers the areas under section 4 in more detail than a public statement sensibly can.

Request it from clientservice@classe365.com. Tell us which parts of the platform you are assessing and what your own obligation is, and we will make sure the report addresses them. If you need something the report does not cover, ask, and we will tell you plainly whether we can provide it.

6. Feedback

6.1 Tell us

If any part of the classe365.com website, Classe365 or Hiree365 is difficult or impossible for you to use, we want to hear from you. You do not need to know the standard, identify a success criterion, or describe the problem in technical terms. Telling us what you were trying to do and what happened is enough.

Feedback of this kind is the most useful information we get. An automated tool can tell us a label is missing; only a person can tell us that the missing label made it impossible to enrol.

6.2 How to contact us

Email: clientservice@classe365.comAccessibility phone: +61 2 9472 5000

Use whichever suits you. If email is not accessible to you, call. If you would prefer a member of staff at your institution to contact us on your behalf, that is fine, and so is contacting us directly.

6.3 What to tell us, if you can

what you were trying to do;
where you were — the page, screen or feature;
what happened, and what you expected;
the assistive technology you use, if any, and the browser and device — this helps us reproduce the problem; and
how to reach you.

If you can only give us some of this, send it anyway. A partial report is far better than none.

6.4 Our response commitment

We aim to respond to accessibility feedback within 1 business day.

That first response is a real reply from a person, not an automated acknowledgement. It will confirm we have your report, tell you what we have understood, ask anything we need to know to reproduce the problem, and — where we can — tell you a way to complete the task in the meantime.

6.5 What happens next

We investigate the report and log it as a defect. We prioritise it by the impact it has on people’s ability to complete essential tasks. We keep you informed of what we intend to do and, where a fix will take time, we tell you that plainly rather than leaving you waiting.

6.6 Help in the meantime

Where a barrier cannot be fixed quickly, we will work with you and your institution to find another way for you to complete the task. Nobody should be prevented from enrolling, submitting work, viewing a result or applying for a placement while a defect sits in a queue.

6.7 If you are not satisfied

If you are not satisfied with how we have handled your accessibility feedback, say so — write to clientservice@classe365.com or call +61 2 9472 5000 and tell us. Your institution can also raise the matter with us through its account contact. We would rather hear that we have got it wrong than have you give up on the report.

7. Compatibility

The platforms are designed to work with current versions of widely used browsers on desktop and mobile devices, and with the assistive technologies commonly used with them, including screen readers, screen magnification, speech recognition and keyboard-only navigation.

Accessibility depends on the combination of the platform, the browser, the operating system and the assistive technology, and the same page can behave differently in different combinations. Older browsers and older versions of assistive technology may not support everything the platform relies on. If you are using a supported combination and something does not work, that is a report we want — please tell us which combination it was.

8. Accessibility and the rest of our documents

Our Security Statement describes the controls protecting the systems described here.
Our AI Use and Transparency Statement explains where AI features appear in the platform, how they are labelled, and how an institution can disable them.
Our Privacy Policy explains how personal information is handled, including any information you give us when you contact us with accessibility feedback.
Our Service Level Agreement covers availability, which for some users is itself an accessibility question.

Any of these documents can be provided in another format on request. Ask at clientservice@classe365.com or call +61 2 9472 5000.

9. Changes to this statement

We review this statement at least annually, and whenever our conformance status changes, a known limitation is resolved, a new limitation is identified, or the standard we work to changes.

Each version carries a “Last updated” date and an “Effective” date at the top. The current version is dated 15 September 2026 and takes effect on 15 October 2026, and it replaces our previous statement in full.

10. Contact us

Accessibility feedback, and requests for a conformance report: clientservice@classe365.com Accessibility phone: +61 2 9472 5000 Support:clientservice@classe365.com

By post — United States customers: 365 Software, LLC 131 Continental Dr, Suite 305 Newark, DE 19713 United States

By post — all other customers: Sprout On Web Pty Ltd 22 Palm Street St Ives, NSW 2075 Australia

Business address — Sprout On Web Pty Ltd: 22 Giffnock Avenue Macquarie Park, NSW 2113 Australia

If something in our software is stopping you from doing something you need to do, please tell us. We will take it seriously, and we will help you get it done while we fix it.

Classe365 and Hiree365 are operated by 365 Software, LLC (United States customers) and Sprout On Web Pty Ltd (all other customers), with support and engineering services provided by Classe365 India Pvt Ltd.