Integrevise is committed to ensuring that its platform is accessible to the widest possible audience, including individuals who use assistive technology or who have specific access needs. This statement applies to the Integrevise web platform. It describes the standards we work to, the features we have built into the product, the areas we are continuing to improve, and how to contact us if you encounter a barrier.
Conformance Status
The platform is designed and developed to conform to the Web Content Accessibility Guidelines (WCAG) version 2.1, Levels A and AA. We consider the platform to be substantially conformant with these guidelines. A small number of areas of partial conformance are described under "Known Limitations" below, and form part of our ongoing accessibility work.
Compatibility
The platform is designed and tested to work with current versions of the following:
- Browsers: Google Chrome, Microsoft Edge, Mozilla Firefox, and Apple Safari, on both desktop and mobile devices.
- Screen readers: NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.
- Operating systems: Windows 10 and Windows 11, macOS, iOS, and Android.
Technical Specifications
The platform is delivered using HTML, CSS, JavaScript, and WAI-ARIA, the international standard for accessible rich internet applications. Its interactive components are based on widely used open source primitives that follow recognised accessibility patterns, including focus management, keyboard interaction, and screen reader semantics for menus, dialogs, popovers, tabs, and similar controls.
Measures to Support Accessibility
Text and Readability
- Body text is presented at a comfortable default size and may be enlarged or reduced using standard browser or device settings.
- Text sizes are defined in relative units, allowing the interface to scale proportionally when the system font size or browser zoom is adjusted, without disruption to layout.
- Line height and letter spacing are configured to support sustained reading, including longer passages such as transcripts and feedback.
- Headings follow a consistent visual hierarchy across the product, supporting navigation by structure for both sighted users and screen reader users.
Zoom and Responsive Layout
- The platform does not restrict pinch to zoom or browser zoom. Content and functionality remain available at zoom levels up to and including 200%.
- Layouts adapt to a range of viewport sizes, from large desktop monitors to mobile devices.
Colour and Contrast
- The colour palette is governed by a centralised design system, ensuring that text and interactive elements remain visually distinct from their backgrounds across all screens.
- Where status information is conveyed visually, for example in result summaries or charts, colour is paired with text labels and icons so that meaning is never communicated through colour alone.
- Form fields, focus indicators, and error states use distinct visual treatments to remain identifiable within their surrounding context.
Assistive Technology Support
The interface is built using accessible component primitives that are designed to operate correctly with screen readers and keyboard input. For users of screen readers, the platform provides:
- Accessible names for icon only buttons, allowing the screen reader to announce the function of the control.
- Alternative text for meaningful images, including logos, sign in provider icons, and reference photographs.
- Audible confirmations following key actions, such as the submission of feedback.
- Form fields that announce their label, required state, and validation status, with error messages associated with the field they describe.
Page Structure
- Pages are constructed using semantic landmark regions, including main content and navigation, enabling screen reader and keyboard users to move through the page by structure.
- Tabular data is presented using semantic table markup so that screen readers can describe rows, columns, and headings.
- The page declares its language so that browsers and assistive technologies render content with appropriate pronunciation and behaviour.
Keyboard Navigation
- All interactive elements are reachable and operable via the keyboard.
- A visible focus indicator is rendered around the element that currently holds keyboard focus.
- When a dialog or modal is opened, keyboard focus is moved into the dialog and constrained to it until it is dismissed, after which focus is returned to the originating element.
- The conversational viva provides keyboard shortcuts for frequent actions, including toggling the camera, toggling the microphone, toggling transcription, and leaving the session. A built in dialog lists the complete set of shortcuts and may be consulted at any time.
Forms and Input
- Form fields are paired with visible labels.
- Required fields are clearly indicated.
- Inline validation provides clear, plain language error messages adjacent to the field requiring attention.
- Text input is supported throughout the platform, including a typed message mode within the conversational viva for users who prefer to type rather than speak.
Errors, Loading, and Notifications
- A descriptive page is presented in response to a request for a URL that does not exist, including alternative text for the accompanying illustration.
- Background loading is communicated through skeleton placeholders, indicating that content is being retrieved.
- An application level error boundary prevents an unhandled error from disrupting the entire interface.
- The in app notification control announces the count of unread notifications to assistive technology.
Known Limitations
Accessibility is an ongoing programme of work. The following areas are not yet fully conformant, and are scheduled for improvement as part of our regular release cycle:
- The platform does not yet adapt to the operating system "reduce motion" preference. We plan to honour this setting so that animated transitions can be reduced for users who prefer a quieter interface.
- Some embedded third party components, including the customer support chat widget include supplied controls whose accessibility we do not fully control. We monitor improvements from these providers and supplement them where we can.
Assessment Approach
The most recent accessibility assessment was a self assessment carried out in May 2026. The assessment combined a review of the live interface against WCAG 2.1 Level AA criteria with a structured examination of the underlying code for common accessibility patterns and gaps.
Reporting an Accessibility Issue
If you encounter content or functionality on the platform that you are unable to access, or if you require information in an alternative format, please contact us at info@integrevise.com or contact your institution's student support team. We aim to acknowledge accessibility enquiries within five working days. Reports from users are an essential input to the continued improvement of the platform.
Preparation and Review
This statement was prepared on 4 May 2026. It is reviewed at least annually, and following any significant change to the platform.