Accessible Procurement: Building capacity for acquiring e-resources
October 19, 2023
Library e-resources need to be accessible!
- Context for PLSB
- How to incorporate accessibility principles into procurement
- Accessibility requirements: Deep dive
- Lessons learned
- What if my library does not do procurement?
Introduction: The experience in Alberta
Public Library Services Branch
- Accessibility as policy priority
- Library Resource for People with Print Disabilities operational policy
- Best Practices for Public Libraries in Alberta
- Staffing dedicated to accessibility
- Support for accessible platforms
- Subject to various government policies, legislation, and
intergovernmental trade agreements
- NWPTA, CFTA, CETA, WTO GPA, FOIP, Financial
Administration Act, Procurement and Sole-sourcing Directive, Canadian
competitive bid law
- Transparency and openness
Request for Proposal (RFP)
- Open tender
- Mandatory vs. Desirable requirements
- Canadian competitive bid law
- Duty to disclose
- Duty to conduct a fair procurement process
- Duty to reject non-compliant responses
- Duty to award to winning vendor
- Duty to award contract as tendered
How to incorporate accessibility principles into procurement
Ask for the vendor to include their organization’s
- Include a statement in your RFP that describes your
organization’s commitment to accessibility.
- Example: “Accessibility is a priority for PLSB. As such,
PLSB strives to acquire a Solution that has sufficient accessibility
features to enable Patrons with Disabilities to access the available
content. Please see X and Appendix X for further information.”
- Describe specific and measurable accessibility requirements
- Electronic resources: can be based on WCAG
- Have vendors assess the accessibility of these requirements
- Need to verify the vendor’s response with accessibility testing
- Engage people with lived experience and who are well-versed with specific assistive technology to perform accessibility
- Make sure you ask for access to the resource for testing purposes. Specify how long you will need access for testing
Request an automated accessibility test
Full transparency: we have not included this step yet
- Ask vendor to prescreen their product
- Have vendor run an automated accessibility checker on
their product and provide the results
- Automated testing will not catch everything, but it will
catch some things
- Gives the vendor an opportunity to address some
accessibility concerns before responding
Debrief and feedback session
- Record the testing results (both the score and the justification for the score)
- If vendor is interested, a feedback session is an
excellent opportunity to describe the results of the testing
- If possible, include the testers in the feedback session
Build accessibility into the contract
- Use the vendor’s responses to the accessibility requirements as part of the contract
- If the vendor says that building an accessible feature is
on their roadmap, build that into the contract
- If the vendor says that all images have alt-text, include
that as part of the contract
What if something breaks? It happens!
- Sometimes updates can break the accessibility of an electronic resource
- Sometimes a vendor will add something new and will forget
to incorporate accessibility
- Develop a process for feedback about inaccessible features
of the product (who can we contact and what actions can be taken?)
Accessibility requirements: Deep dive
Finally, test and validate the vendor’s response
Visit accessible procurement resources for full list
- List individual, specific requirements
- Requirements should be measurable
- Allow the vendor the opportunity to respond to the accessibility of the requirements
- This gives the vendor an opportunity to reflect on the
accessibility of their product
Requirement: Access to all controls
- Enable Users to operate the Solution with a keyboard,
headtracking, voice control, or switch device (e.g., have access to all
controls and be able to move to them in a logical manner).
Access to all controls demonstration
Requirement: Interact with all elements
- Enable Users to identify and interact with all elements in
the Solution (e.g., input field, buttons, checkboxes, links etc.). All
these elements should have text labels.
Requirement: Adjustable features
- Visual appearance such as font size, spacing, font type,
etc., should be adjustable as features of the Solution.
Adjustable features demonstration
- The Solution should enable all Users to determine where
they are on the interface in the Solution. Structure (headings, landmarks,
and changing of the title on page load) is important to help users
distinguish where they are on the interface. This should also include
highlighted elements to show the focus visually.
- Enable Users to access information that images convey.
(Images should have alt-text, for example)
Requirement: No separate version
- Enable all Users to have access to the same Solution, not
a different and "accessible" version.
Requirement: Accessibility of pre-loaded content
- The Solution will have considered accessibility for the
pre-loaded content available in the platform. Please describe what
accessibility features the content has prioritized.
Evolution of evaluation process
Over time we modified the process to include:
- Initially we asked proponents for:
- WCAG compliance, optional submission of VPAT and/or
accessibility statement, accessibility road map
- Specific and measurable accessibility requirements
- Accessibility testers – validation of accessibility claims
What we will do differently next time
- Review and modify the requirements (iterative process)
- Reframe: What will render a resource irredeemably unusable
for a print-disabled user?
- Kickoff meeting before testing to discuss requirements and
how they will be tested
- Make sure the RFP posting and associated documents are
accessible (walk the talk)
- Ask the vendor to prescreen with automated accessibility test
- More integration with other functional requirements?
- General UX vs. WCAG requirements
- WCAG is a starting point
- How do we measure user experience?
Establish accessibility as a priority when evaluating
current or new resources
- Ask users with lived experience
- Include people with lived experience from the beginning
and right through until the end of the RFP process
- Pay them
What if my library does not do procurement?
Why should I learn about accessible procurement?
Because ALL libraries do procurement
- Even if you are part of a library system or a consortium
that procures electronic resources on your behalf, you are still
- Get involved: ask questions about how they evaluate the accessibility of resources.
- Offer assistance if they have not thought about it.
- We are all learning together!
Because it makes you a better librarian
- Understanding accessible requirements will help you to understand accessibility
- You can recommend accessible e-resources and know what accessibility features they have
- You will be better equipped to understand accessibility-related concerns
- Visit the NNELS reading app reports to learn about the accessibility of library resources
Because you will be able to provide better patron experience
- Being able to talk about the accessibility (or lack
thereof) of your e-content provides the patron with a better library
- For example, one platform might have excellent adjustable
features, so you might recommend that to someone who prefers to modify the
font size or colour.
Because it demonstrates a commitment to accessibility
- Thinking about the accessibility of your e-resources,
whether you are purchasing them directly or not, demonstrates a library’s
commitment to accessibility
- Visit the accessible procurement resources page on the
PLARC website for resources about accessible procurement and accessible
Library e-resources need to be accessible!