Conduct an Inventory of Third-Party Digital Workforce Tools Get link to section Conduct an Inventory of Third-Party Digital Workforce Tools
Does your organization have a central resource listing all third-party technologies in use by employees and applicants? Compiling an accurate list is a crucial step for incorporating accessibility into your procurement process and making sure that employees and applicants can use the tools they need to thrive in your workforce.
Suggestions for the types of information to collect are in the following section. Depending on the data you already have available and the size of your organization, you may want to begin by creating categories and priorities, and conducting detailed inventory based on those groupings. For others, a full inventory may be a more useful first step.
The early investment of time and resources in conducting an inventory will pay off. Not all of your organization’s existing technology with accessibility and usability barriers can be remediated at once. If the task seems too big, it may not be undertaken at all. Categorizing and prioritizing, and recognizing the scope of the project, helps manage expectations and serves as the foundation for a realistic roadmap. And of course, parallel to an inventory of existing technology and vendors, processes and procedures can begin to ensure that accessibility is baked in to new technologies and vendor relationships.
Collect Data Get link to section Collect Data
The following information should be collected during an inventory of tools used by employees and applicants:
- Name of product / technology / service.
- Product type: web, software, peripheral, etc.
- Name of vendor organization (or identify as developed in-house).
- Name of contact/s within vendor organization or in-house product owner.
- Location (or absence) of vendor’s accessibility statement.
- Location (or absence) of any Voluntary Product Accessibility Template (VPAT) associated with this product.
- Location (or absence) of product release notes featuring accessibility features and fixes.
Note: Including accessibility information in product release notes is a best practice and should be encouraged. Here are two examples:
Release notes for ServiceNow(External link) and Release notes for Ally for LMS(External link).
- Does the product roadmap include dates for planned accessibility
- Date the license / contract for the technology is set for renewal or expires.
- Commitment (if any) given by vendor at time of purchase about accessibility (include specifics, including any exceptions to an accessibility commitment).
- Person / group within your organization responsible for the contract with the vendor (who owns the technology / the contract; who has the relationship).
- Has the technology been reviewed for accessibility and if so, when and what were the results. If needed, schedule an accessibility audit and usability testing if one has never been done or if the previous audit was cursory or more than 12 months old.
Categorize and Prioritize Digital Tools for Accessibility Remediation / Attention Get link to section Categorize and Prioritize Digital Tools for Accessibility Remediation / Attention
The tool inventory provides information your organization needs to categorize and prioritize technology for accessibility focus/remediation. Consider your organization’s priority factors and categorize / group products in ways relevant to your organization. (For example, categories could be based on use of the product by number of employees, roles, or divisions; by how essential the digital tool is for job duties; or by when the product is set to expire/divest.)
Factors to consider in the process of categorizing and prioritizing tools for accessibility focus might include the following:
- Compliance status with applicable legal / policy standards (How broken is it?).
- Frequency of use by employees/applicants (traffic).
- Importance of use (e.g. once a month but can’t get paid without it; rare but critical usage (e.g. reporting emergencies; receiving emergency information).
- Number and severity of accessibility bugs.
- Place in the applicant / employee life cycle (e.g. is technology used to apply for the job? To file a claim for benefits?).
- Does the tool itself create content that other employees and applicants need? Such “authoring tools” may be seen as having an enhanced accessibility factor because employees/applicants with disabilities need to be able to use them to create content, and the created content must be available to everyone.
- ICT product type.
- Date the product will be phased out.
Information collected and organized by category and priority provides a necessary resource to determine how and when to best approach third-party vendors about the accessibility of existing tools.