Skip to content

Accessibility Considerations for E-Resources Procurement in Libraries

    Creator: Accessible Libraries

    Date Updated: January 31, 2023

    Accessibility Considerations for E-Resources Procurement in Libraries is a living document that is still changing.

    Table of Contents

    1. Introduction
      1. Stages of Accessible Procurement
      2. Accessibility Standards and the Web Content Accessibility Guidelines
      3. Definitions of Assistive Technology
      4. Evaluation of Resources
    2. Questions to ask Vendors of E-Resources
      1. Priority Ratings
      2. Accessible Controls
      3. Text Readability and Assistive Technology
      4. Accessible Navigation
      5. Visual Customization
      6. Alternatives for Colours
      7. Blinking or Flashing Elements
      8. Plugins, Add-ons, and Accessibility Software
      9. Options for Accessing Multi-Media
      10. Accessibility Metadata
      11. Timed Responses
      12. Prescriptive Design and Barriers
      13. Product Support
      14. Information Architecture and Navigational Links
      15. Interface Orientation
    3. Conclusion
    4. Appendixes
      1. Appendix A: Terms and Definitions
      2. Appendix B: Links and Resources

    Introduction  

    The procurement process is complex, and accessibility should be one of the significant components of this process. Accessibility means that the needs and barriers faced by persons with disabilities are considered when designing and creating digital resources to ensure everyone, regardless of disability, can use them and foster more equitable libraries. As with any other aspect of procurement, all stages must incorporate accessibility.

    The Public Library Accessibility Resource Center (PLARC), a collaborative project between the National Network for Equitable Library Service (NNELS) and the Centre for Equitable Library Access (CELA) in partnership with eBOUND, has developed the procurement guidelines for purchasing and licensing online digital resources and content. These guidelines can inform and/or be added to the evaluation tools you use when deciding to license a given resource.

    The procurement guide will support libraries and library staff in selecting accessible content and electronic resources (e-resources) to improve access for people with print disabilities. Not all content, online services, and reading platforms have accessibility built into them by design.

    Digital resources can refer to e-resources platforms (websites, applications, and reading platforms) and digital content.

    • Accessible e-resources platforms (websites, applications, and reading platforms) are what patrons use to consume digital content. To be accessible, the e-resources must work with assistive technologies. 
    • Accessible digital content comes in different formats (e.g. EPUB, HTML, PDF for books or journal articles, MP3 or DAISY for audiobooks) and includes accessibility features like alternative text, navigable pages, and structure/design of the content.

    This document covers accessibility features that all e-resources platforms (including websites and applications) should have to ensure that they work for all readers, regardless of the assistive technology they use. Questions for the procurement of digital content are forthcoming.

    Use the questions in the document when communicating with vendors. Ask vendors, for example, about their accessibility policy, common accessibility features (like keyboard navigation), and compatibility with assistive technologies, to determine if the vendor’s company and the products they supply are accessible to all patrons. Priority ratings are associated with the questions so that library staff can determine what to prioritize (outlined in the Priority Ratings section). These questions will help library staff make better, more inclusive, and value-added decisions when acquiring new services and evaluating existing products.  

    Digital e-resources need to be evaluated during and after procurement to ensure all their features are accessible and that they are usable for people who utilize assistive technologies. The evaluations should be conducted by people with lived experiences of disabilities using a variety of assistive technologies. Discussed in further detail below, we provide a list of features and considerations for the evaluation.

    Incorporating accessibility questions and evaluations into the e-resource procurement processes will help create awareness among stakeholders involved in the acquisitions of content and electronic resources and urge vendors to promote and create accessible resources.

    The paragraphs below highlight key stages of accessible procurement and suggest ways to ensure that the requirements of digital accessibility for e-resources are captured throughout the process of procurement.

    Stages of Accessible Procurement

    Accessible procurement begins by having the necessary organizational support, accessible procurement does not occur in isolation. Ideally, it is part of a wider approach to accessibility. First, identify existing support mechanisms and policies at your institution, such as a Disability Action Plan or accessibility training. An Accessibility Policy (if one exists) provides the governance framework for procuring and acquiring accessible digital products and enables those involved in procurement to point to the library’s public commitment to being an accessible place.

    Adopt a human right by design approach to the provision of digital services and facilities: from concept, research and design, testing and production through to implementation and use.

    Add Accessibility to the planning process. Accessible procurement should be included within your library’s Disability Action Plan. Embed accessibility requirements as standard for procurement of software, digital resources, and platforms.

    Your library system will almost certainly already have a dedicated procurement policy. You can write accessibility into that procurement policy or consider a dedicated policy on accessible procurement. Even with a dedicated policy on accessible procurement in place, however, it is still advisable to include accessibility requirements explicitly in the main procurement policy so that they are seen as equal considerations alongside other criteria such as security and privacy.

    It should be recognized that the “average user” does not exist except as a statistic, so trying to obtain equipment for the average user will result in products and services that are not usable by everyone, more work, equipment not fit for the purpose, and more expenses.

    Determine the standards you want to work to: e.g., Web Content Accessibility Guidelines (WCAG). You will refer to these in all Requests for Proposals (RFP) and contracts. WCAG are the standards that should be applied to all websites. This includes content as well as online services and applications with browser interfaces.

    Assemble a procurement team, which should include accessibility expertise. Their advice and input will help with the wording of RFPs, contracts etc., and help evaluate the responses from vendors and negotiations for contracts. Make this a standard part of your procurement process.

    Include accessibility requirements throughout the Request for Information (RFI), Request for Quotations (RFQ) or RFP. Don’t leave accessibility out on its own. Including accessibility references throughout the document sends a message that you’re serious about accessibility, that you expect the vendor to be, and that you will be paying close attention to how they respond.

    Make sure you explain which standards you are expecting the vendor to meet; do not expect them to know. Your vendors may not know about accessibility – you may have to make them aware. Highlight your own organization’s commitment to accessibility and to human rights by design so that your platforms are inclusive and accessible to disabled people.

    And of critical importance: walk the talk. Ensure that your own RFI/RFP/RFQ documentation is accessible. If it isn’t, you’re sending a clear message to the vendors that you’re not that serious.

    Ensure accessibility-related criteria are clearly included in the Requirements section of your RFI/RFP/RFQ. Clearly state that the accessibility criteria will be closely examined during the evaluation stage.

    Ask vendors questions about the company’s accessibility and the accessibility of their products. Accessibility should be included in all aspects of the company, from the organization and hiring policy down to their products. Additionally, all users must have access to the same product, not different and “accessible” versions. E.g., text-only versions or separate optimized sites/apps. If the company and/or vendor offer a separate “accessible” version or a magic fix-all tool, this could be an indication that their accessibility design is likely flawed. Here are some examples of questions to ask vendors about their experience with and commitment to accessibility in their company and products:

    1. Does the company/vendor have an accessibility department, team, or lead?
    2. Is the content or e-resources (websites, apps, or reading platforms) that everyone uses accessible?
      1. If the product is not accessible, is the company recommending users with disabilities use a separate product?
    3. Does the vendor know how and what accessibility features are included in their product?
    4. If available, provide a copy of the company’s most recent VPAT.
    5. If available, provide a copy of any completed accessibility audit the company has undergone.
    6. Do they have demonstrations of how the product works with assistive technologies?
      1. If yes, do they have documentation or guidelines about how the product works with assistive technologies?
    7. How does the vendor/company handle accessibility requests/feedback from users?

    Note: VPAT (Voluntary Product Accessibility Template) is a report or document that describes how e-resources meet the revised 508 Standards for Information Technology (IT) accessibility (a USA law). For more information, refer to the Terms and Definitions in this guide.

    Use the suggested questions in this guide to get the responses needed to make an informed assessment of vendors’ approach to accessibility, as well as the functionality of the digital products they offer. It is imperative that the responses made by vendors to questions concerning digital accessibility be appropriately evaluated by the procurement team. To that end, it is best practice to ensure that subject matter personnel are included and that vendors understand that this is the library’s practice.

    Accessibility Standards and the Web Content Accessibility Guidelines

    Having a set of accessibility standards to guide the design of websites and applications is important because standards help to create a common definition of accessible content. These standards help content creators and end users better communicate their needs to one another to create a unified approach to accessibility for all.

    In terms of digital content, one of the most important standards is the WCAG (Web Content Accessibility Guidelines). WCAG was developed by the World Wide Web Consortium W3C process, in cooperation with individuals and organizations around the world, to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.

    The WCAG documents explain how to make web content more accessible to people with disabilities. Web “content” generally refers to the information in a web page or web application, including:

    • Natural information such as text, images, and sounds
    • Code or markup that defines the structure, presentation, etc.

    This guide draws heavily from the requirements established in the WCAG standards but is intended to be a convenient reference for procuring accessible resources in a library setting. Many of the questions come from the lived experience of people with disabilities using and testing websites with assistive technologies. The questions are designed to determine whether a feature of an application or website is useable or not with assistive technologies. Along with the questions, each section will contain links to the most relevant WCAG standards, placing these technical standards in a real-world context that reflects the experiences of people with disabilities.

    Definition of Assistive Technology

    The term assistive technology, also known as access technology, refers to technological tools developed with features specifically helpful for people with disabilities.

    Assistive technology (AT) is any item, piece of equipment, software program, or product system used to increase, maintain, or improve the functional capabilities of persons with disabilities. Examples of high-tech AT include computer hardware (special switches, keyboards, and pointing devices) and software (e.g., screen readers, screen magnification and enhancement software, and voice controls, among others).

    Evaluation of Resources

    Determining if the resources that vendors supply are accessible may be difficult. The vendors may be unable to answer all the questions listed below, and library staff may be unable to test the resources for accessibility.

    The ideal scenario for testing the accessibility of e-resource platforms, as mentioned above, is to hire a team of paid testers with lived experience who use various assistive technologies. The team of testers will test out the products and report back to you.

    If this is not possible, there are alternate solutions:

    • Hire one tester with lived experience to test out the accessibility of the content and e-resources (reading platforms, websites, and apps).
    • Have the vendor respond to the questions in this procurement guide, confirm the vendor’s accessibility policy, and ask them to add an accessibility commitment to your contract.
    • Seek feedback from your library patrons and ask if they find the content and e-resources (websites, apps, or reading platforms) accessible. You could do this through an accessible online survey, ideally providing an honorarium to participants.
    • Research the vendors and their products using outside sources that evaluate accessibility.
    • Apply for grants to fund the employment of persons with disabilities to test your digital content and e-resources.

    Questions to ask Vendors of E-Resources

    To determine if the content is accessible, ask your vendors these questions. Demonstrations of how inaccessible content impacts readers will be added soon.

    Priority Ratings

    This document presents important accessibility features and a few possible questions to help vendors provide information for each feature included in the list. A Priority level is also included in the form of a number:

    • Priority level = 3 (must have)
    • Priority level = 2 (should have)
    • Priority level = 1 (nice to have)

    All these considerations matter for accessibility, and the number aims to provide a method to prioritize features.

    Accessible Controls

    Users must be able to operate the product with a keyboard, head tracking, voice control, or switch device (accessible controls). Someone navigating without a mouse must have access to all controls, be able to move to them logically, and activate any buttons or controls.

    Priority Level = 3

    Questions

    1. When navigating e-resources (websites, apps, or reading platforms) using a keyboard on a computer, does the tab or shift-tab key move your focus to all elements on the screen?
    2. When using a mobile device with the screen reader enabled, do the swipe gestures move your focus to all elements on the screen?
    3. Does how the focus move from one element to the next make sense? E.g., in a catalogue search, the focus should move to the search box before landing on a submit or search button.
    4. Can clickable elements be activated using a keyboard or other assistive technologies? E.g., can you navigate to your library catalogue using only your computer keyboard?

    WCAG Guidelines

    Text Readability and Assistive Technology

    Users must be able to read all text on the screen or interface when using assistive technology, especially screen readers and screen magnification and enhancement software. Any elements of the page or interface that are not text-based, such as images, charts, or graphs, should provide detailed alternative text descriptions and have high resolution to ensure no distortion/fuzziness when magnified.

    Priority level = 3

    Questions

    1. Can screen readers read digital content on the e-resource platform (webpages, apps, and reading platforms)?
    2. Can you read the text on e-resource platforms (webpages, apps, and reading platforms) using hardware and software screen magnification tools?

    WCAG Guidelines

    Accessible Navigation

    Users must be able to identify and interact with all elements in the product (e.g. input field, buttons, checkboxes, links, etc.). All these elements should have text labels, as screen readers rely on them to announce what they are interacting with to the user.

    Priority level = 3

    Questions

    1. When navigating an e-resource (website, app, or reading platform), is the screen reader announcing the control’s purpose so that it is clear to the user? E.g., the screen reader should announce things like ‘link catalogue,’ ‘submit button,’ and ‘book title.’
    2. When using a screen reader on an e-resource (website, app, or reading platform), is there a lot of elements on the screen that says ‘link,’ ‘button,’ ‘edit,’ or ‘checkbox unchecked’ and nothing else? If so, this is a red flag indicating that the website/app is most likely inaccessible.
    3. Can you visually identify the navigation elements on the screen (input fields, buttons, links, checkboxes, etc.) and identify what they are for (submitting a search, navigating to a different webpage, etc.), with and without using software/hardware magnification tools?
    4. Does the screen reader indicate whether checkboxes are checked?

    WCAG Guidelines

    Visual Customization

    Visual appearance, such as font size, spacing, font type, etc., should all be adjustable features of the product. Users with low or impaired vision benefit greatly from being able to increase the font size and contrast, and certain types of fonts are easier to read for people with both low vision and dyslexia.

    Priority level = 3

    Questions

    1. Are there options on the e-resource (website, app, or reading platform) users can adjust for visual appearance?
    2. Can colour schemes and contrast be adjusted by the user?
    3. Can the size and type of the font be changed in the e-resource (website, app, or reading platform)?
    4. Does the website or resource offer a high contrast mode for readers with low vision?
    5. Is the text in eBooks, newspapers, and other electronic content on websites/applications reflowable? E.g., the text will adapt to the screen size so that it is readable on any device.

    WCAG Guidelines

    Alternatives for Colours

    Many people are colour-blind, especially in the areas of blue, green, and red. Colour alone should not be the only means to convey information on a website or electronic resource. There must be an alternative for users, such as those with colour blindness or who are blind.

    Priority level = 3

    Questions

    1. Is all information conveyed with cues other than colour, such as text or distinctively shaped icons? E.g., mandatory fields, like a library barcode login field, are colour coded but also marked with an asterisk and announced as “required” by screen readers.
    2. If the colour is removed, could the user still effectively use this product?

    WCAG Guidelines

    Blinking or Flashing Elements

    If the resource has elements that blink or flash (especially more than three times per second and flashes which are large and bright), they must never be enabled by default because this can trigger seizures. This must be opt-in only (turning them off is not an option because, by the time the user tries to turn it off, a seizure may already have occurred).

    Priority level = 3

    Question

    1. Are there animations or videos with blinking or large flashes that occur more than three times per second by default?

    WCAG Guidelines

    Plugins, Add-ons, and Accessibility Software

    The product must work with plugins, addons, screen magnification and enhancement software etc., on the user’s computer to allow visual adjustment. The product should be designed and structured to allow assistive technology to interpret and parse the content.

    Note: The product should not use accessibility overlays, which are inaccessible and cause more accessibility barriers than they fix.

    Priority level = 3

    Questions

    1. Does the product override any visual adjustments when changing the different appearances with software/hardware magnification tools?
    2. Can the software or webpage be used while running assistive technology or user-enabled accessibility options?
    3. Does the website/app use an accessibility overlay?

    WCAG Guidelines

    Options for Accessing Multimedia

    Users must be able to access multimedia in various ways (e.g., transcripts, captions, audio descriptions). Alternatives for time-based media that are text-based make information accessible because text can be rendered through any sensory modality (for example, visual, auditory, or tactile) to match the user’s needs.

    Priority level = 3

    Questions

    1. Can audio descriptions and close captions be turned on for all videos?
    2. Are video transcripts available for all videos?

    WCAG Guidelines

    Accessibility Metadata

    Accessibility metadata indicates the accessible feature a product has. This includes noting accessible items like a table of contents navigation, logical reading order, heading navigation, image descriptions, page navigation, etc. Accessibility metadata helps people with disabilities choose the content they want based on if it is readable for them or not. If the content has built-in accessibility features, it should include accessibility metadata.

    Priority Level = 3

    Questions

    1. Does the e-resource (website, app, or reading platform) display the accessibility metadata of the content?
      1. If yes, where?
      1. If no, ask the vendor why not?

    Timed Responses

    If any responses are timed (when filling out a form with your information, for example), the user should be alerted and allowed to indicate that more time is needed. People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read content or to perform functions such as filling out online forms.

    Priority level = 2

    Question

    1. When filling out an online form, is there a way to disable the time limit, adjust it (up to ten times the length of the default setting), or add more time (up to 10 times) 20 seconds before the time is up?

    WCAG Guidelines

    Prescriptive Design and Barriers

    The product should not prescribe how users use their product (e.g., some products disallow pasting in password fields which is a large barrier for people with cognitive or mobility disabilities).

    Priority level = 2

    Questions

    1. Does the product disallow pasting in password fields?
    2. Can the same content or the same feature be accessed in multiple ways?

    WCAG Guidelines

    Product Support

    Users and staff should have easy access to ongoing support for the product.

    Priority level = 2.

    Questions

    1. Does the company have a well-written accessibility statement that is easy to find?
    2. Do customer service personnel have training on working with people with disabilities or an accessibility team that can offer support?
    3. Is there a well-defined process to ensure that accessibility feedback reaches the right people and is quickly acted upon?

    Information Architecture and Navigational Links

    Whether accessed through a web browser or within an app, all websites should have skip navigation and jump-to links and logical and consistent page organization. There should be a way for users to skip repetitive navigation links (all web pages should have a link which allows a user to skip directly to the main content, bypassing any site navigation information).

    Priority level = 1

    Questions

    1. Is there a visible link(s) at the top of the page that lets users skip to the main content?
    2. When you use the tab key on a keyboard, does the skip link visually appear at the top of the page?

    WCAG Guidelines

    Interface Orientation

    All users, whether using assistive technology or not, must be able to distinguish where they are on the interface. A visual way this can be achieved is by highlighting the area of the screen that is being accessed by the user, such as actionable controls or text that a screen reader is currently reading. Some users of assistive technology have low or impaired vision, so synchronized visual and audio cues can help all assistive technology users to better orient themselves in a document or piece of software.

    Priority level = 1

    Question

    1. Is it reasonably easy to tell which section of the website, app, or resource the user is in?
    2. When navigating an app or webpage, can the user easily determine where they are on the screen with a visual cue such as highlighted text or buttons?
    3. Are there visual cues, such as a line of dots from an element on the left side of the screen, to alert those using screen magnification that there is a related button, menu, or field at the far-right side of the screen?

    WCAG Guidelines

    Conclusion

    The technical language and nuances in standards such as the WCAG can be a barrier to understanding the accessibility of electronic resources. The hope is that this document can serve as an easy starting point for somebody looking to procure accessible materials for their library or organization. As one of the largest consumers of digital resources, databases, and other software, libraries are uniquely positioned to utilize their purchasing power to best advocate for the entirety of their user base, including people with disabilities.

    If vendors begin to hear these same accessibility questions from all the libraries and organizations they are dealing with, eventually, they will be left with no choice but to address the issues being brought forward. Libraries and librarians should be committed to accessibility in every way possible, from the physical buildings to the programs and software. Investing in accessible materials and resources at the procurement stage will ensure that your electronic resources are easier to migrate, more portable, maintainable, and upgradable, and more likely to be compatible with other tools such as assistive technology. This will help to create a landscape with fewer barriers to accessibility for both librarians and their patrons.

    Appendixes

    Appendix A: Terms and Definitions

    Accessibility

    Accessibility means that the needs and barriers faced by persons with disabilities are considered, and the resources are created so that everyone will have the same experience when using or reading them.

    Accessibility Overlay

    Accessibility Overlays try to “fix” the website code, generally using JavaScript, to modify the original website with accessibility features (e.g., enlarging the text or making it screen reader “friendly”). The overlay does not address the foundational inaccessibility of a website. It just masks the issues and creates more barriers.

    Alternative Text

    Alternative text (alt text) describes images for persons using assistive technologies. When reading a book with images, screen readers will announce that it’s an image and then read the alt text, ensuring they have the same reading experience.

    Assistive Technology

    Assistive technology (AT), also known as access technology, is any item, piece of equipment, software program, or product system used to increase, maintain, or improve the functional capabilities of persons with disabilities. Examples include screen readers (e.g., VoiceOver, JAWS, etc.), screen magnification and enhancement software (e.g., Zoom, Magnifier, etc.), and refreshable braille displays (e.g., BrailleNote Touch). In-depth definitions for the examples are available in the glossary.

    Bypass Blocks/Skip Links

    Bypass Blocks (also known as skip links) are hidden links that allow keyboard users to skip to different website sections. Generally, the skip link will take users to the main content (past the website’s main navigation bar).

    Colour Contrast

    Colour contrast refers to the tonal and saturation colour of different (two or more) colours situated closely together in a website, book, app, etc. Colours can have a low contrast because they sit closely together on the colour spectrum and/or have a low saturation rate. A high colour contrast (which is accessible) occurs if the colours are far apart on the colour spectrum and/or have a high saturation rate. For example, black text on a white background has the highest colour contrast because black and white are on the opposite ends of the colour spectrum. Note: a low saturation rate doesn’t necessarily mean that the colour will have a poor colour-contrast ratio; it depends on the colour(s) it’s paired with. WCAG advises a colour contrast ratio of 7:1 for smaller text and 4.5:1 for larger, so the more the colours contrast, the higher the ratio.

    Information Architecture

    Information architecture (IA) refers to the structural elements of digital resources (websites, apps, reading platforms, etc.) that help users find the information they are looking for. It includes items such as the labelling of the site (e.g., the main menu terms like “About Us”), the links and menus in the site, the organization of the site, and the general structure of the site (e.g., the header, footer, and any sidebars).

    Long Descriptions

    Long descriptions are like alt text for more complex images (diagrams, charts, graphs, etc.). Often the long descriptions need to be provided elsewhere, either in the content or using a link to a separate page with the longer description. The complex image should still be generally described, noting that a longer description is available.

    Plugin/Add-on

    A plugin (or add-on) is an extension, often attached to a browser, that lets users adjust or modify a website or app to give it additional features (e.g., changing the colour scheme from light to dark).

    Prescriptive Design

    A prescriptive design is when a website or app controls how users interact with the site according to their specifications. For example, when filling out a required form, autosuggest is not available, so users need to enter their details manually – there are not two ways of completing the task.

    Reflowable Text

    A reflowable layout means that text will adapt to the screen size you are reading on, making it readable on any device. The layout adjusts (lines of text, page numbers, etc.), and the text will not overflow off the screen size. The alternate is “fixed layout,” where the text does not scale to the screen size and will flow off the screen. 

    Refreshable Braille Display

    A refreshable braille device connects to a website, app, or ebook and transmits the content onto the refreshable braille display by raising braille dots on the device.

    Screen Readers

    An assistive technology that allows persons who have visual impairments or who are fully blind to navigate electronic resources.

    Screen Magnification and Enhancement Software

    An assistive technology that enables persons with visual impairments to enlarge text and images for easier viewing. This software also includes changing the colour contrast of the product, increasing the word spacing, and enlarging the navigation tools (e.g., the cursor) to make it more accessible for the user.

    Speech Recognition Software

    An assistive technology that enables people to navigate a document and input text with verbal commands.

    Peripheral Devices

    Devices such as headsets, speakers, microphones, touchpads, keyboards, a computer mouse, etc., allow people to interact with computers and software.

    Visual Customization

    Visual customizations let you make changes to the e-resource (website, app, or reading platform). Examples include changing the font type, size, colour, background, etc. Unlike accessibility overlays, these customizations are for everyone and generally change the actual code of the digital resources (rather than adding a patch).

    Voluntary Product Accessibility Template (VPAT)

    Voluntary Product Accessibility Template (VPAT) is a report or document that describes how e-resources meet the revised 508 Standards for IT accessibility. The document should include descriptions and accessibility documentation for the product’s software, hardware, and digital content. Part of the USA Rehabilitation Act of 1973 (amended in 1998), the 508 Standards for IT accessibility declares that all persons should have the same access to information.

    Web Content Accessibility Guidelines (WCAG)

    WCAG was developed by the World Wide Web Consortium W3C process, in cooperation with individuals and organizations around the world, to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.

    Links

    Tatomir Accessibility Checklist

    Jennifer Tatomir put together a checklist which combines “federal web accessibility legislation, international web accessibility standards and the researcher’s personal experiences engaging with online and digital environments to distill the ten features that are key to accessibility for users of adaptive technologies.”

    The Tatomir Accessibility Checklist contains the following accessibility best practices:

    • Accessible versions of PDF web pages and documents
    • Skip navigation and jump-to links
    • Clearly labelled page elements
    • Text captions for tables, images, graphics, graphs, and charts
    • Limited use of incompatible programming languages and scripts
    • The absence of identically named page elements
    • Text transcripts of videos, animations, and podcasts
    • Logical and consistent page organization
    • Absence of timed responses
    • Digital forms and functionalities accessible and usable with adaptive technologies