Accessibility in Ready Student, previously known as JR Plus
This Voluntary Product Accessibility Template (VPAT) describes how the Ready Student Management System currently conforms to WCAG 2.1 accessibility standards. It will be updated periodically as standards and system capability develops.
Principle 1: Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
Criteria/Level |
Conformance Level |
Explanation |
1.1.1 Non-text Content |
Supports |
Ready Student provides text alternatives to default non-text content for elements within the system. Externally uploaded files will be dependent on external applications for this support. |
Not Applicable |
Ready Student does not contain any pre-recorded video- only or audio-only content. |
|
1.2.2 Captions (Prerecorded) |
Not Applicable |
Ready Student does not contain any video or audio content by default. Support for this in uploaded files is the responsibility of the end user. |
1.2.3 Audio Description or Media Alternative (Prerecorded) |
Not Applicable |
Ready Student does not contain any video or audio content by default. Support for this in uploaded files is the responsibility of the end user. |
1.2.4 Captions (Live) |
Not Applicable |
Ready Student does not provide Live video or audio functionality. |
1.2.5 Audio Description (Prerecorded) |
Not Applicable |
Ready Student does not contain any video or audio content by default. Support for this in uploaded files is the responsibility of the end user. |
1.3.1 Info and Relationships |
Partially supported |
Most information, structure, and relationships can be programmatically determined or are available in text. Ready Student currently has exceptions related to consistently conveying field validation and some legacy pages. |
1.3.2 Meaningful Sequence |
Supported |
Ready Student page sequences are designed to be able to be programatically determined to allow a correct reading sequence. |
1.3.3 Sensory Characteristics |
Supported |
User interfaces within Ready Student do not rely on solely sensory characteristics for conveying information. |
1.3.4 Orientation |
Partially supported |
The Ready Student administration interface is adaptive and will display correctly in both portrait and landscape orientations. There are a limited number of pages where tables with a large number of user enabled columns enabled will flow off the page but are accessible via scrolling. |
1.3.5 Identify Input Purpose |
Partially supported |
Ready Student supports autocomplete and uses icons on input fields such as currency, dates etc to indicate meaning. Autocomplete support has not yet been extended to the full application. |
1.4.1 Use of Color |
Supported |
User interfaces within Ready Student do not rely on solely sensory characteristics for conveying information. |
1.4.2 Audio Control |
Not Applicable |
Ready Student does not contain any video or audio content by default. |
1.4.3 Contrast (Minimum) |
Partially supported |
Most pages support minimum contrast of 4.5:1. The Main Dashboard is currently an exception to this and a redesign is planned to address this. |
1.4.4 Resize text |
Supported |
Text resizing is supported via the browser. Resizing up to 150% will not affect the usability of Ready Student. |
1.4.5 Images of Text |
Supported |
Ready Student does not use images of text within the UI. |
1.4.10 Reflow |
Partially supported |
The Ready Student administration interface is not intended to be used on mobile devices outside of laptops and tablets so we don’t use reflow techniques to support smaller screens (i.e. phones). On these screens some data will flow off the page but is accessible via scrolling. Ready Student Portals (Student Portal, Employer Portal etc) support reflow techniques for displaying content on small screens. |
1.4.11 Non-text Contrast |
Supported |
Icons support the 3:1 contrast ratio. |
1.4.12 Text Spacing |
Partially supported |
Supported in many but not all parts of the system at this point. |
1.4.13 Content on Hover or Focus |
Partially supported |
This is supported with the exception of some tool tips which cannot be dismissed without moving the pointer. |
Principle 2: Operable
User interface components and navigation must be operable.
Criteria/Level |
Conformance Level |
Explanation |
---|---|---|
2.1.1 Keyboard |
Supported |
Ready Student is keyboard-operable, including providing alternative keyboard-optimised interfaces for some features such as the rich content editor. |
2.1.2 No Keyboard Trap |
Supported |
Ready Student does not capture the focus when navigating via keyboard. |
2.1.4 Character Key Shortcuts |
Supported |
Shortcut keys are only used in limited functionality across the system and those shortcut keys are only active while that functionality has focus. |
2.2.1 Timing Adjustable |
Partially supported |
Most elements do not time out and are dismissible within the UI. There are a small number of alerts which do time out and this timing is not adjustable. |
2.2.2 Pause, Stop, Hide |
Supported |
Ready Student does not contain moving, blinking, or scrolling content. Auto-updating content is present in the batch logs and this content can be paused and resumed by the user. |
2.3.1 Three Flashes or Below Threshold |
Supported |
Ready Student does not contain blinking content. |
2.4.1 Bypass Blocks |
Supported |
Ready Student provides both “Skip to Navigation” and “Skip to Content” links. |
2.4.2 Page Titled |
Supported |
Pages in Ready Student are named appropriately. |
2.4.3 Focus Order |
Supported |
Pages in Ready Student are keyboard navigable in an appropriate, consistent and logical tab order. This order is generally left to right and top to bottom. |
2.4.4 Link Purpose (In Context) |
Supported |
The purpose of each link in Ready Student is clearly identified by its text, supplemented with labels when necessary. |
2.4.5 Multiple Ways |
Supported |
Ready Student pages can be navigated to in multiple ways using a consistent layout in the global navigation header and contextual left hand navigation panes. |
2.4.6 Headings and Labels |
Supported |
All Ready Student pages contain a H1 header describing the main purpose of the page. |
2.4.7 Focus Visible |
Supported |
Ready Student implements a visible high contrast blue highlight around elements when navigating via keyboard. |
2.5.1 Pointer Gestures |
Supported |
Ready Student does not require navigation by multipoint or path-based gestures. |
2.5.2 Pointer Cancellation |
Supported |
Actions are not activated on Mouse down and can be cancelled by moving the mouse off the item and releasing. |
2.5.3 Label in Name |
Partially supported |
This is supported in many parts of the system but is not yet consistent throughout. |
2.5.4 Motion Actuation |
Supported |
Ready Student does not use motion to actuate any events or functions. |
Principle 3: Understandable
Information and the operation of user interface must be understandable.
Criteria/Level |
Conformance level |
Explanation |
---|---|---|
3.1.1 Language of Page |
Supported |
Ready Student specifies English (EN) as the language of all our pages. |
3.1.2 Language of Parts |
N/A |
Ready Student is not currently a multi-lingual system. |
3.2.1 On Focus |
Supported |
Changing the focus on the page does not perform any actions or change of context within Ready Student. |
3.2.2 On Input |
Supported |
Modifying the input fields on the page does not perform any actions or change of context within Ready Student. |
3.2.3 Consistent Navigation |
Supported |
In general the navigation paradigm within Ready Student is consistent within a given set of pages. |
3.2.4 Consistent Identification |
Partially supported |
In general Ready Student uses are consistently labelled and behave the same across the system. There are some legacy pages where known issues exists (“update” used rather than “save” for example, or having slightly different types of search behaviours). |
3.2.5 Change on Request |
Supported |
The context of the page does not change without a user action in any page within Ready Student. |
3.3.1 Error Identification |
Supported |
Validation Errors within Ready Student are clearly described in text and in most cases highlighted with a red highlight. |
3.3.2 Labels or Instructions |
Supported |
All data fields that require entry within Ready Student are labelled appropriately, and in many cases include additional help text where required. |
3.3.3 Error Suggestion |
Supported |
As a compliance-focused system we provide an appropriate level of error suggestions without mandating how to fix the data where that requires judgement or the application of internal policies by our customers. |
Supported |
If a user can change or delete legal, financial, or test data, the changes or deletions can be reversed, verified, or confirmed. |
Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Criteria/Level |
Conformance Level |
Explanation |
---|---|---|
4.1.1 Parsing |
Supported |
Ready Student web pages consist of well formed HTML with complete start and end tags in all cases. The Rich content editor, which supports user generated content, ensures proper HTML is generated and validated as an output. |
4.1.2 Name, Role, Value |
Partially supported |
More dated Ready Student UI components are gradually being updated to ensure conformity to HTML and ARIA best practices. |
4.1.3 Status Messages |
Partially supported |
More dated Ready Student UI components are gradually being updated to ensure status messages are correctly labelled. |