Web Accessibility Statement
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 are provided 24/7 by Classe365 group staff in Australia, India, the Philippines, Spain and the United States.
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 measured against an earlier version of WCAG and did not reflect our current 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 some parts of the content do not fully conform to the standard. 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, some parts of the platform 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 try to help you complete the task in the meantime.
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
The following are the practices we build to. Section 4 lists where the platform does not yet meet them.
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 designed 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 addressed 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 a single-pointer alternative 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 try to 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 update it as we fix things and as testing and user reports find things we have not yet listed.
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 Further detail on request
Institutions may request further detail about our conformance. Institutions assessing the platform for procurement or compliance can ask at clientservice@classe365.com. Tell us which parts of the platform you are assessing and what your own obligation is, and we will tell you plainly what detail we can provide.
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.com Accessibility 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 will come from a person and confirm that we have your report. Where we can, it will also suggest 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 identify a reasonable alternative way to complete the task where one is available.
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 the optional AI features, how users can recognise AI-generated output, and how an institution can ask us to switch features off.
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 an alternative format on reasonable 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 was published on 22 September 2026 and takes effect on 22 October 2026, and it replaces our previous statement in full.
10. Contact us
Accessibility feedback, and requests for further detail about our conformance: 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, where we can, help you find a way to get it done while we work on a fix.
Classe365 and Hiree365 are operated by 365 Software, LLC (United States customers) and Sprout On Web Pty Ltd (all other customers), with 24/7 support and engineering provided by our group team in Australia, India, the Philippines, Spain and the United States.
