Accessibility infromation for software
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We are looking to build out our software catalog and our software request checklist within ServiceNow. We want to add the accessibility information about the software we own into the catalog. This information can include what settings the software is approved for, such as single user, small office, interoffice, classroom, or university wide. Along with any known accessibility issues, accessibility documentation, or accessible alternatives.
For the request checklist, we want to provide the requester with the questions they need to have the vendors answer. Along with what documentation will be needed form vendors. We can also detail what we will need to see in a demo and the access we will need to conduct our own evaluations.
Does anyone have experience doing any of this work, or examples they would like to share?
Thank you, Sean
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
I think this is a great idea. Maybe start with what you need to know to comply with the laws of whatever jurisdiction you're in and then what you need to know to comply with your organisation's policies. I don't think there's really a one-size fits all answer for this. There will be some common things such as links to vendor compliance statements, known defects and internal testing status but you may want to track things like compatibility with specific products authorised for use in your organisation, compliance with specific WCAG versions to meet regulatory requirements in the UK and EU, etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a week ago
Stuart,
Thank you. I do think having something similar to the VPATs for us to be able to take notes on what criteria passed and which did not would be helpful. Then as vendors correct issues, or as things change in versions, we could track those changes. Being able to chart improvements and declines could help us during contract talks. This might even be a useful way to store information about our own app and site developments. Though, we have other means for that history as well.
Due to a particular issue we are facing with a vendor right now, I think having the contract language with the vendor would be beneficial. It would not only help with accessibility, but it could help with security. Especially with the ever-changing AI landscape. We often look at what companies have in their EULAs during initial requests and renewals. Being able to review the final contract with vendors can be quite enlightening. With our current process, we have to request a copy from our contracts team each time an issue needs to be reviewed.
Take care,
Sean
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hi Sean - I'll reach out to our product team to see if there's a playbook out there that could be helpful in this situation and get back to you if we have a good guide to get this started.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a week ago
Thank you. I always love when we can use something already developed and adapt it to meet our needs. Take care, Sean