Our commitment to accessibility 

We are committed to making the Veridian platform accessible and inclusive for all users, including people with disabilities. Accessibility is an integral part of how we design, develop, and improve our software and services.

We align with recognised standards such as the Web Content Accessibility Guidelines (WCAG) and continuously review our technology, content, and processes to support equitable access to information and digital experiences.

Accessibility is an ongoing effort. We are committed to continuous improvement and to working with our clients and users to reduce barriers and ensure our software  remains usable by as many people as possible.

Accessibility Conformance Report (ACR)

This ACR for the Veridian Software platform was prepared in accordance with the Information Technology Industry Council VPAT® WCAG Edition (Version 2.5Rev).

It reflects the accessibility of the standard Veridian platform as of the publication date. Client sites may use versions newer or older than this release.

Accessibility is considered during custom development; however, site-specific customisations are assessed separately and are outside the scope of this report.

Some materials may not fully meet accessibility standards due to limitations in original scanned content and OCR accuracy, and are therefore outside the platform’s control.

DOWNLOAD REPORT

How we track our accessibility progress

We track accessibility progress through a combination of structured reviews and measurable checkpoints aligned with WCAG 2.0, WCAG 2.1, and WCAG 2.2 Level A and AA criteria.

Our approach includes:

  • Periodic internal accessibility reviews aligned to WCAG success criteria.

  • Monitoring issues identified through user feedback and support channels.

  • Tracking remediation of identified accessibility issues through our development workflow.

  • Reviewing updates to WCAG and related standards to ensure continued alignment.

  • Maintaining and updating our Accessibility Conformance Report (VPAT® WCAG edition).

Accessibility is treated as an ongoing program rather than a one-time project. Progress is measured by reduction in known issues, alignment with updated WCAG criteria, and the incorporation of accessibility considerations into new feature development.


How we prioritise accessibility issues

When an accessibility issue is identified — through internal review, user feedback, or usability testing — it is recorded, assessed, and prioritised based on:

  • The impact on a user’s ability to access content or complete essential tasks (i.e. whether the issue prevents access entirely or affects usability but still allows completion).

  • Alignment with WCAG Level A and AA requirements.

  • Legal or regulatory relevance.

  • Frequency of occurrence and overall user impact.

Issues that prevent users from accessing content, navigating the interface, or completing core functions are prioritised at the highest level. Issues that affect usability, efficiency, or clarity — while still allowing access — are addressed as part of ongoing improvement.

Related reading: WCAG Compliance and Accessible Digital Archives

While our primary conformance target is WCAG 2.1 Level AA, we also work toward Level AAA success criteria where feasible and appropriate, particularly in areas that enhance usability and inclusive design without compromising functionality. Accessibility is built into new feature development from the start, helping prevent new issues and reducing the need for fixes later. We embed accessibility review into our release lifecycle to support proactive, continuous improvement.

 

How we stay up to date with accessibility requirements

We monitor accessibility standards and legislation globally, particularly in jurisdictions where our clients operate.

Our process includes:

  • Ongoing review of updates from the W3C regarding WCAG (including WCAG 2.2 and the development of WCAG 3.0 / “Silver”).

  • Monitoring U.S. ADA Title II requirements and the 2024 Final Rule mandating WCAG 2.1 Level AA compliance.

  • Tracking international accessibility standards such as EN 301 549 (EU), Section 508 (U.S.), and government web standards in jurisdictions including New Zealand, the UK, and Australia.

  • Maintaining familiarity with the different VPAT® template editions (WCAG, 508, EU, and INT) to support clients operating in multiple regulatory environments.

We work with libraries, archives and other cultural heritage organisations internationally, so we recognise that accessibility compliance expectations vary by region. Our Accessibility Conformance Report is structured using the VPAT® WCAG edition aligned to WCAG 2.2 Level A and AA, and we review it periodically to ensure continued alignment with evolving standards.

Accessibility is treated as an evolving regulatory and technical landscape, and we proactively monitor changes to reduce compliance risk for our clients.

 

 

Recent accessibility improvements

Outlined below are some of the accessibility improvements we have made over the past 12 months to strengthen alignment of the Veridian Software platform with WCAG 2.2.

Accessibility improvements and related WCAG criteria

Accessible labelling improvements

Improved the use of title attributes and accessible names to ensure interactive elements are clearly and consistently described for assistive technologies.

  • 2.4.6 Headings and Labels (AA)
  • 4.1.2 Name, Role, Value (A)

Date browser accessibility enhancements

Improved the accessibility of date selection components to ensure clearer labelling, keyboard operability, and assistive technology compatibility.

  • 1.3.1 Info and Relationships (A)
  • 2.1.1 Keyboard (A)
  • 4.1.2 Name, Role, Value (A)

User scoreboards updated to structured data tables

Updated user scoreboards to use proper <table> markup to ensure data relationships are programmatically conveyed to assistive technologies.

  • 1.3.1 Info and Relationships (A)
  • 4.1.2 Name, Role, Value (A)

Table header associations

Added scope attributes to <th> elements to clearly associate headers with related rows and columns for assistive technologies.

  • 1.3.1 Info and Relationships (A)
  • 4.1.2 Name, Role, Value (A)

Table captions added

Added <caption> elements to tables to describe their purpose and context to screen reader users.

  • 1.3.1 Info and Relationships (A)

ARIA usage refined

Removed unnecessary or redundant ARIA attributes and ensured native HTML elements convey meaning wherever possible, using ARIA only where it adds required accessibility information.

  • 3.3.2 Labels or Instructions (A)
  • 4.1.2 Name, Role, Value (A)

Icons integrated into links

Moved lock icons inside link elements so they form part of the accessible name and purpose of the link.

  • 1.1.1 Non-text Content (A)
  • 2.4.4 Link Purpose (In Context) (A)
  • 4.1.2 Name, Role, Value (A)

Listbox role corrections

Removed incorrect use of role="listbox" where native HTML controls were more appropriate.

  • 4.1.2 Name, Role, Value (A)

State attribute clean-up

Removed unnecessary aria-selected and aria-disabled attributes where they were not required.

  • 4.1.2 Name, Role, Value (A)

Screen reader support text

Added visually hidden text to provide additional context and clarity for screen reader users where needed.

  • 1.3.1 Info and Relationships (A)
  • 3.3.2 Labels or Instructions (A)
  • 4.1.2 Name, Role, Value (A)

Decorative graph hidden from assistive tech

Hid the year results graph from screen readers where it duplicated information already available in accessible formats.

  • 1.1.1 Non-text Content (A)
  • 1.3.1 Info and Relationships (A)

ARIA support added where needed

Added ARIA attributes where required to improve accessibility information for assistive technologies.

  • 3.3.2 Labels or Instructions (A)
  • 4.1.2 Name, Role, Value (A)

Tooltip clarity improvements

Improved tooltip wording to provide clearer guidance and context for users.

  • 3.3.2 Labels or Instructions (A)

Empty anchors removed

Removed empty anchor elements that created confusion for screen reader and keyboard users.

  • 2.4.4 Link Purpose (In Context) (A)
  • 4.1.2 Name, Role, Value (A)

Tab navigation improvements

Removed tab dropdown patterns and corrected tab behaviour to better support accessibility and navigation.

  • 2.1.1 Keyboard (A)
  • 2.4.3 Focus Order (A)
  • 3.2.3 Consistent Navigation (AA)
  • 4.1.2 Name, Role, Value (A)

Reduced reliance on temporary messages

Reduced the use of short-lived system messages to ensure users have sufficient time to perceive and understand content.

  • 2.2.1 Timing Adjustable (A)

Extended text correction lock duration

Increased time limits for text correction workflows to support users who need more time to complete tasks.

  • 2.2.1 Timing Adjustable (A)

Keyboard interaction fixes

Resolved issues with keyboard event handling to ensure all interactive features are operable via keyboard.

  • 2.1.1 Keyboard (A)

Improved colour contrast

Enhanced contrast of key interface elements to improve readability and visibility.

  • 1.4.3 Contrast (Minimum) (AA)

Navigation and action improvements

Added a “previous” button and repositioned primary actions to improve navigation and usability.

  • 2.4.3 Focus Order (A)
  • 3.2.3 Consistent Navigation (AA)
  • 3.2.4 Consistent Identification (AA)

Removed keyboard traps in forms

Removed form behaviours that prevented users from navigating away using a keyboard.

  • 2.1.2 No Keyboard Trap (A)

Home page layout improvements

Rearranged home page columns to improve reading order and navigation.

  • 1.3.2 Meaningful Sequence (A)
  • 2.4.3 Focus Order (A)

Autofocus removed

Removed use of autofocus to prevent unexpected focus changes for keyboard and assistive technology users.

  • 2.4.3 Focus Order (A)
  • 3.2.1 On Focus (A)

Navigation structured as lists

Updated header, footer, and menu links to use semantic <ul>/<li> markup.

  • 1.3.1 Info and Relationships (A)
  • 4.1.2 Name, Role, Value (A)

Tabindex usage removed

Removed unnecessary tabindex attributes to support natural keyboard navigation.

  • 2.4.3 Focus Order (A)

Layout tables marked as presentational

Added role="presentation" to layout-only table structures used in forms.

  • 1.3.1 Info and Relationships (A)

Non-functional alerts removed

Removed role="alert" attributes where they did not provide meaningful user notifications.

  • 4.1.2 Name, Role, Value (A)

 

Need more accessibility information
or have questions?