Procurement Guide: Selecting a Partner for an Accessible Website

Building and maintaining an accessible website is a legal and civil-rights requirement for public libraries. While full WCAG 2.1 Level AA compliance may be phased in over upcoming years in some jurisdictions, the accessibility obligations under ADA Title II and Section 504 are already in effect. Failing to follow recognized standards, or relying solely on automated “accessibility buttons”, puts libraries at risk of exclusion, legal liability, and failure to serve their full community.

As accessibility requirements expand, libraries are increasingly faced with choosing among vendors and partners claiming accessibility expertise. This guide is designed to support informed decision-making during procurement, helping libraries identify qualified partners, reduce risk, and establish clear expectations.

1. Start by confirming WCAG knowledge

A qualified accessibility partner should be able to clearly explain WCAG in plain language, including:

• What Perceivable, Operable, Understandable, and Robust mean in practical application
• How they address headings, labels, contrast, structure, and keyboard interaction
• How they prevent known barriers such as inaccessible sliders, pop ups, event calendars, or navigation menus

If these concepts cannot be clearly explained, it may indicate a gap in readiness for an ADA regulated environment.

2. Review past work for accessibility indicators

Before selecting a partner, review samples of their work with the following accessibility considerations in mind.

a. Built in accessibility vs add on tools

Some websites rely on accessibility buttons that adjust font size, contrast, or reading modes. While tools can support individual preferences, they do not replace accessible design and development.

Accessible websites are built with inclusive structure and semantic code from the beginning, without requiring visitors to activate an additional feature.

b. Moving content and controls

Any content that moves, rotates, slides, or auto plays such as sliders, carousels, news tickers, or animated banners must include a clearly visible Pause, Stop, or Hide control under WCAG 2.1AA 2.2.2.

A site that lacks these basic controls is not meeting even the earliest accessibility standards.

c. Keyboard navigation

Using only the Tab key, verify that:

• Users can see where focus is located
• Menus and links can be opened by keyboard
• Slideshows and buttons are operable
• Forms and pop ups can be completed and closed

Keyboard accessibility is foundational and should be consistently supported.

d. Initial scanning tools

Free browser tools such as WAVE or axe DevTools can help identify common issues such as missing labels, structural problems, or contrast failures. These findings can guide deeper evaluation and questions during procurement.

3. Request evidence of accessibility experience

Rather than relying on marketing language, request concrete proof of accessibility work, such as:

• Human generated accessibility audits or reports
• Examples containing issue descriptions, WCAG references, screenshots, and remediation actions
• Descriptions or demonstrations of testing with NVDA, JAWS, VoiceOver, or TalkBack

This type of detail helps confirm real world experience.

4. Include staff training in the scope

Website accessibility does not end at launch. A well structured agreement should also prepare library staff to maintain accessibility on an ongoing basis. This includes training in areas such as:

• How to structure headings correctly
• How to meet color and font requirements
• How to write meaningful alternative text
• How to create accessible documents and PDFs
• How to avoid introducing new barriers inside the CMS

This type of training ensures the site remains accessible and compliant long after the project is completed.

5. Specify accessibility protection in the contract

Procurement language can significantly reduce risk when it clearly defines expectations. Consider including:

• A written commitment to meet WCAG 2.1 Level AA
• Language that does not shift accessibility responsibility entirely to the library
• A requirement for remediation of identified issues
• Documentation of testing methods and results
• Optional indemnification related to accessibility failures

Partners with genuine accessibility experience will understand and accept these standards.

6. Require an accessibility review before approval

Prior to contract award or final acceptance, request:

• An accessibility review of a comparable project
• A walkthrough of findings and recommendations

Additionally, test high impact areas, including:

• Calendar and event systems
• Forms and applications
• Menus and navigation
• Search and catalog tools
• Third party integrations

This provides insight into how accessibility is addressed in real situations.

7. Plan for post launch accountability

Accessibility is ongoing. Confirm whether the partner provides:

• Regular monitoring or checkups
• Support for new templates and content areas
• Oversight of plugins and third party systems
• Remediation when updates introduce issues

A long term plan strengthens compliance and reduces future risk.

Final responsibility and recommended next steps

Regardless of who builds or maintains the website, the library remains responsible for accessibility. Clear ownership, defined roles, and proactive procurement practices help make this responsibility manageable.

Recommended next steps:

• Review current and upcoming contracts
• Confirm alignment with WCAG 2.1 Level AA
• Add or strengthen accessibility provisions
• Assign internal ownership for accessibility oversight

By approaching procurement with clarity and intention, libraries strengthen both legal compliance and inclusive access for their communities.