web-accessibility

Digital accessibility enables people with disabilities to perceive, navigate, understand and interact with online collections. For libraries and archives, this requires accessible software, well-structured content and ongoing attention to standards such as the Web Content Accessibility Guidelines (WCAG).

This guide explains WCAG conformance, accessibility legislation, Voluntary Product Accessibility Templates (VPAT®) and Accessibility Conformance Reports (ACR), with practical guidance for evaluating digital collections software.


What is the difference between WCAG, a VPAT and an ACR?

Term

Stands for

What it is What it does
WCAG Web Content Accessibility Guidelines An international technical standard developed by W3C Defines testable requirements for making web content accessible
VPAT® Voluntary Product Accessibility Template A reporting template developed by the Information Technology Industry Council Provides a standard structure for documenting product accessibility
ACR Accessibility Conformance Report A completed accessibility report Records how a specific product supports the accessibility criteria in a VPAT

A VPAT® is the blank template. Once it has been completed for a particular product, the resulting document is called an Accessibility Conformance Report, or ACR.


Why does accessibility matter for digital collections?

Digitised historical archives — spanning newspapers, magazines, books, photographs, letters, and audio recordings — serve a wide range of communities. Ensuring equitable access for everyone, including people with visual, motor, cognitive, and hearing challenges, is essential so that history can be discovered, experienced, and enjoyed by all.

For some, accessibility can mean the difference between connection and exclusion. This includes people with motor disabilities, such as cerebral palsy or hand tremors from Parkinson’s disease, who may rely on keyboard navigation, voice commands, or adaptive devices instead of a mouse. Others with low or blurred vision, perhaps from age-related cataracts, may depend on screen readers or high-contrast displays to engage with content. People with cognitive or learning differences, including dyslexia, dementia, or anxiety disorders, may find complex layouts or inconsistent menus overwhelming. Even something as simple as excessive manual data entry can cause fatigue for those with arthritis or repetitive strain injuries.

Thankfully, accessibility standards such as the Web Content Accessibility Guidelines (WCAG) now provide a framework to guide organisations toward more inclusive digital design. Without them, many communities are unintentionally locked out of history. A page of text hidden inside an image can sound like silence to someone using a screen reader. Colours that look stylish to one person might blur into invisibility for those with low vision. Menus that shift from page to page can leave users with cognitive challenges disoriented, while functions that can’t be accessed without a mouse can make it nearly impossible for someone with limited mobility to explore a site at all.

With new laws like the ADA Title II Final Rule and updates to WCAG 2.2, accessibility is no longer a “nice to have” — it’s a requirement shaping how libraries, museums, and archives serve their communities online.


 

Understanding the Web Content Accessibility Guidelines (WCAG)


What Is WCAG and why does it matter?

The Web Content Accessibility Guidelines are developed by the World Wide Web Consortium (W3C) to make web content more accessible to people with disabilities. Meeting WCAG isn’t just about compliance — it’s about ensuring everyone can access and experience online content, and in our sector, explore history without barriers.

How has WCAG evolved?

Sir Tim John Berners-Lee, inventor of the World Wide Web (as well as HTML, the URL system, and HTTP), first brought accessibility into the spotlight in 1994 during his speech at the second International World Wide Web Conference, where he declared that “access (to the internet) by everyone, regardless of disability, is an essential aspect.”

In 1999, the World Wide Web Consortium (W3C) released the first version of WCAG. Centred on HTML — fitting for its time — WCAG 1.0 offered 14 guidelines to make online content more accessible.

Nearly a decade later, WCAG 2.0 introduced a technology-neutral standard for web content, including information, multimedia, code and web applications. Its principles can also be applied to non-web software and documents through related guidance such as WCAG2ICT. WCAG 2.0 introduced 61 success criteria organised around four principles: content must be perceivable, operable, understandable and robust (interpreted reliably).

WCAG 2.1, released in 2018, built upon this foundation by adding 17 new success criteria designed to reflect advances in technology and to improve accessibility for users with mobile devices, low vision, and cognitive impairments.

The latest version, WCAG 2.2, was released in 2023 and adds a further nine success criteria, reflecting ongoing efforts to refine and expand digital accessibility standards.

 

How is WCAG organized?

Since WCAG 2.0, each new version has expanded on the last, so meeting WCAG 2.2 also meets the requirements of WCAG 2.1 and WCAG 2.0.

The guidelines and success criteria across all versions are grouped into three levels of conformance — A, AA, and AAA — each representing the degree of impact on accessibility.

What do WCAG Levels A, AA and AAA mean?

  • Level A: These are the foundational accessibility requirements that must be met. If they are not, some people may find parts of a website or digital content difficult or impossible to access or use.

  • Level AA: Includes all Level A and Level AA success criteria. This is the level most commonly referenced by governments and accessibility policies. Meeting these requirements removes many common barriers and makes online content more accessible to a wider range of people with disabilities.

  • Level AAA: Includes all Level A, AA and AAA success criteria. This level encourages organisations to take additional steps, where possible, to improve accessibility. Some AAA criteria cannot be satisfied for all types of content, so WCAG does not recommend requiring entire websites to conform at this level.

 

What comes after WCAG 2.2?

WCAG 3.0 (code-named “Silver”) — the internal nickname used by the W3C Accessibility Guidelines Working Group — is still several years away, but development is already underway to broaden its scope beyond traditional web content.

The new guidelines will cover applications, tools, and emerging technologies such as virtual and augmented reality, voice-controlled interfaces, and other multimodal experiences that blend visual, audio, and interactive inputs.

Because of this expanded focus, the W3C has indicated that WCAG 3.0 will introduce a new structure and conformance model, offering greater flexibility and a stronger emphasis on real-world user experience.

Back to top^

Which accessibility requirements apply to libraries and archives?

Accessibility isn’t just ethical — it’s strategic. Inclusive design expands audience reach, strengthens community trust, and reduces legal risk. For libraries, archives and cultural heritage organisations, compliance with WCAG 2.1 or 2.2 ensures public funding eligibility, aligns with open-access principles, and futureproofs digital collections for all users.

OCR converts text within scanned images into machine-readable content that can support search and assistive technologies. However, OCR alone does not make a collection accessible. Accuracy, reading order, semantic structure, interface accessibility and appropriate descriptions or transcripts can all affect whether users can successfully access the content. OCR is not always accurate, particularly with older newspapers and printed publications, but reducing these barriers helps make more of our shared history accessible to everyone.


Legislation and accessibility standards (US)

In the United States, most libraries, museums, historical societies, and university archives are state or local government entities or receive state and federal funding, which makes them subject to Title II of the Americans with Disabilities Act (ADA). This legislation requires that the programs, services, and activities provided by these organisations — whether offered in person or online — to be accessible to people with disabilities.

Until 2024, the Title II regulations did not specify a technical accessibility standard for websites and other digital applications. This meant that many of the online improvements that disability communities expected never materialised.


ADA Title II Final Rule 2024

To close this gap the Department of Justice issued a Final Rule in April 2024, updating Title II so that all state and local government websites and mobile apps must meet WCAG 2.1 Level AA accessibility standards. Deadlines were also set to give organisations time to meet the new standards:

  • By 24 April 2026 for larger state and local government agencies that serve 50,000 or more people.This was extended to 26 April 2027 via an Interim Final Rule.

  • By 26 April 2027 for smaller agencies serving fewer than 50,000 people. This was extended to 26 April 2028 via an Interim Final Rule.

Although no specific penalties have been published, not meeting the new standards could still lead to accessibility complaints, legal action, or investigations by the Department of Justice. Taking proactive steps toward compliance helps reduce risk — and, more importantly, ensures everyone can access public information equally.


Global accessibility standards: How other countries are responding

In other parts of the world, public sector organisations are moving quickly to adopt WCAG 2.2 Level AA. For example:

  • In New Zealand, The Government Chief Digital Officer introduced a Web Accessibility Standard 1.2 in 2025 requiring public service departments and specified central government agencies to meet WCAG 2.2 Level AA. Every public-facing and internal webpage within these entities must be designed so that everyone — including people with disabilities — can use them with ease.

  • The European Union follows the EN 301 549 accessibility standards, which draws heavily on WCAG 2.1 Level AA. Under the Web Accessibility Directive, public-sector websites were required to meet these standards from 2020, and mobile applications from 2021. The European Accessibility Act extended these requirements to parts of the private sector from 2025, covering certain products and services such as banking, e-commerce, and ticketing platforms.

  • In the UK, accessibility regulations for public-sector websites and mobile apps are expected to meet WCAG 2.2 Level AA. Government monitoring of compliance began in late 2024 to help ensure digital services are inclusive and easy to navigate for all users.

  • In Australia, the Disability Discrimination Act (1992) prohibits discrimination in access to information and services. The Australian Human Rights Commission recommends conforming to WCAG 2.2 at a minimum of Level AA. For broader ICT products and services, AS EN 301 549:2024 provides accessibility requirements covering websites, software, non-web documents, hardware, documentation and support services. Because the standard incorporates WCAG 2.1, the Commission recommends applying WCAG 2.2 where appropriate.

Together, these updates reflect a global shift toward stronger accessibility expectations and a shared commitment to making digital spaces inclusive for all.

Back to top^


Choosing Software Partners Who Meet Accessibility Standards

For many institutions, accessibility compliance depends not only on internal practices but also on the accessibility of the software they use.

Introducing new software platforms often means partnering with third-party vendors to bring new services and applications to life. However, it’s still the organisation’s responsibility to make sure the platforms meet WCAG accessibility standards. That’s why careful consideration and due diligence are essential when selecting a software partner.


What is an Accessibility Conformance Report?

Before partnering with a software vendor, it’s important to ask for an Accessibility Conformance Report (ACR).

Most ACRs are created using the Voluntary Product Accessibility Template (VPAT®) developed by the Information Technology Industry Council. This should be followed up by requesting a demo that shows the accessibility features outlined in the ACR in action.


What is a VPAT®?

A Voluntary Product Accessibility Template (VPAT®) is a self-assessment completed by the software provider to describe how its product meets accessibility standards. While not an independent audit, it is a well-established and globally recognised framework that promotes transparency and accountability in accessibility reporting.

There are four VPAT® editions, each aligned with different accessibility standards around the world:

  • VPAT® WCAG – As the name suggests, this template covers the Web Content Accessibility Guidelines (WCAG), including the latest WCAG 2.2 criteria.

  • VPAT® EU – Aligns with the European EN 301 549 accessibility requirements, mapping them to WCAG criteria.

  • VPAT® 508 – Used mainly in the US, this version follows the Revised Section 508 Standards, which are based on WCAG 2.0, and apply to federal agencies and their suppliers.

  • VPAT® INT (International) – Combines all three frameworks (WCAG, Section 508, and EN 301 549) into one template for organisations operating globally.

Each VPAT edition follows the same structure, making it easy to see:

  • Which WCAG version (and related framework) the product was evaluated against — and because WCAG versions are backwards compatible, a product that meets WCAG 2.2 also meets 2.1 and 2.0.

  • Which conformance levels (A, AA, AAA) each feature supports.

This consistent format helps organisations quickly understand a vendor’s accessibility readiness, compare products side by side — even those developed in different countries or following different accessibility frameworks — and identify any gaps before implementation.

 

What should you ask a software vendor?

  • Which WCAG version and conformance levels was the product assessed against?
  • Is a current Accessibility Conformance Report available?
  • Which VPAT® edition was used?
  • Who performed the evaluation?
  • Were automated and manual testing both used?
  • Which browsers and assistive technologies were tested?
  • Are any criteria recorded as partially supported or not supported?
  • How are accessibility issues prioritised and remediated?
  • How frequently is the product reassessed?
  • Does the product have an accessibility roadmap? 
  • Which accessibility responsibilities remain with the institution?

Is accessibility a shared responsibility?

Yes. The software platform determines the accessibility of navigation, search, viewing tools, forms and other interface components. The organisation managing the collection also influences accessibility through its content, metadata, OCR quality, image descriptions, captions, transcripts, documents and third-party integrations.

An accessible platform provides the foundation, but maintaining accessible collection content requires ongoing attention from both the software provider and the institution.



How does Veridian support 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 products 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.  Our Accessibility Conformance Report uses the VPAT® WCAG Edition (Version 2.5Rev) and assesses Veridian against WCAG 2.0, 2.1, and 2.2 Level A and AA criteria.

This report provides transparency around how Veridian supports key accessibility requirements and helps libraries, archives, and cultural organisations deliver inclusive access to their digital collections.

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 platforms remain usable by as many people as possible.