Q&A: I’ve been told to make sure the things I procure are accessible. How do I do this?
This article was developed as part of
The Accessibility Switchboard Project
National Federation of the Blind Jernigan Institute
January 2017, Version 1.0.
Creative Commons License: CC BY-SA 4.0
I’ve been told to make sure the things I procure are accessible. How do I do this?
Include in your solicitations reference to the publicly available test process that your accessibility team and contracted developers agree upon.
In-Depth Answer: I’ve been told to make sure the things I procure are accessible. How do I do this?
Applicable ICT categories
This article applies to procurements of Information & Communication Technology (ICT) hardware and software products under the following categories:
- Commercial Off-The-Shelf (COTS);
- Customizable COTS (i.e., platforms that can be used by your in-house developers to build custom databases and other software systems); and
- One-off developments by contracted developers (‘contracted developers’ are distinguished from ‘employee developers’. With contracted developers, procurement departments can be involved, specifying in contract language that accessibility needs to be included in product development. With employee developers, accessibility requirements may be governed by internal development policies, rather than with procurement language).
Note: In general, publications relating to procurement and accessibility have focused on the US Federal government, because of the purchasing requirements contained in the legislation known as ‘Section 508’. Procurement of accessible ICT as a practice within mainstream industry has received comparatively scant coverage. Therefore, in this article many of the examples are drawn from Federal practice, but the issues and advice are intended to be applicable in mainstream industry, state and local government, and beyond.
One of the most important factors in buying any product or service is having a shared understanding between the vendor and the customer. Imagine, as with the illustration above, that you’re an American who is presented with a menu of desserts at a British pub: ‘Eaton Mess’, ‘Gooseberry Fool’, ‘Syrup Sponge’… “What are these things? And why does the menu say ‘Puddings’ at the top? I don’t want custard!” You can share the same language, but when the concepts and terminology are foreign you open yourself up to guesswork, and to half-truths or outright scams in marketing. (Bill Gates once infamously said that the way you make software ‘user-friendly’ was to buy a stamp saying ‘user-friendly’, and stamp all of the boxes.) If you have little or no direct experience with disability, with the relevant terminology and available options for accessible technology, you are at risk of buying the unappetizing product that comes with only half-baked accessibility.
For the most part, the products and services that you buy are assumed to work well for nondisabled users. But, whether ICT works well for individuals with disabilities might be a new question for someone involved in procurement. To tackle the question successfully, the first thing is to establish a shared understanding between the relevant stakeholder teams:
The only way to get this shared understanding is to proactively ensure that all of the people involved understand what is meant by ‘accessible’. Let’s consider some of the typical elements involved in procurement, and how they relate to a shared understanding.
- The rules followed by the procurement team. In the US federal government, there are specific rules such as the Federal Acquisition Regulation (FAR) and Section 508 of the Rehabilitation Act. In US state government agencies, there will be similar rules. In the case of federal and state agencies, those rules will be public. In the private sector, rules governing procurement teams may be governed by internal policies. In all of the above cases, the set of rules and requirements should be generally available to the relevant teams. Unfortunately, because any given procurement is subject to multiple rules, and accessibility is just one of those many rules, the accessibility requirements often get boiled down to just one line in a solicitation, something like: “The product will be Section 508 compliant”.
- Marketing materials and VPATS. The vendor can make any claim they want on their website: “This is the greatest and most accessible product in the world ever”, but then again, Bill Gates said that his products were ‘user-friendly’. A mechanism to provide more detail for the federal government purchasers was sought out early after Section 508 was enacted in 2001. The result was the Voluntary Product Accessibility Template (VPAT). The VPAT is a document template that has the Section 508 technical requirements in one column, and the corresponding claims of the vendor in the next column. Over time, the VPAT has become the de facto means for vendors to share their accessibility claims to anyone making a purchasing decision, not just US federal customers.
- Publicly available accessibility test methods. One of the common criticisms of the VPAT is that there is no requirement for vendors to include information on how they tested the product to substantiate their claims. Did they simply buy a rubber stamp? Did they have users with disabilities try the product? Did they follow a specific set of test steps, either proprietary or public? Procurement personnel often complain that VPATs are incomprehensible to them: there is no inherent shared language because each vendor is free to use their own terminology and their own descriptions. VPATs often include vague unsubstantiated claims. If the vendor did use a proprietary test method, then they have no obligation to publish that method. The only time there can be a shared understanding between all parties is when the testing method is published. For example that single line in the solicitation might be expanded to something like: “The product will be Section 508 compliant, and this will be assured by testing for Section 508 conformance by the customer using the <name of test process> available at www…”.
Following the above, we can see how certain assertions made by vendors can be either vague…
- Vendor: Our products are Section 508 compliant. It says so in our VPAT.
- Customer: Thanks, but we either have to go on trust, or you are putting the burden on us to test whether it meets our accessibility requirements.
- Vendor: Trust us! We know what we’re doing. Lots of other people have bought our product.
- Customer: Just because other people purchased it doesn’t mean that it is up to our standard.
or assertions and dialog can be specific…
- Customer: We are looking for a customizable COTS product that will be able to pass this particular published test process.
- Vendor: We’ve looked at that test process and we have verified that our platform passes, and here are the test results. However, it will be up to your development team to verify that their customization adjustments also passed the published accessibility tests.
- Customer: We can work with that…
In short, it is only when you can reference a specific published test process that all of the players have a shared language, and a common understanding of what is expected. VPATs alone can never provide that common understanding, because the assertions are usually not verifiable against a published test process.
The other main reason to go with a published test process is that it facilitates quality control in the development process. If the original procurement solicitation was only “The product will be Section 508 compliant” then at the end of development you open yourself up to arguments about what that really means. You may get accessibility teams saying that it isn’t compliant, and the vendor saying it is, and the COTS customization team trying to stay out of the argument (but they really want their system to go live on Thursday). Having reference to the shared test process makes things a lot easier to diagnose and fix, and provide quality control for accessibility in the development process. If the procurement team, accessibility team and the customization development team are all on the same page with the agreement of a given test process, then they can easily include the vendor in productive discussions: “The testing found a failure in step 11.C of the process, which you’ll find on page 24. Using the standard inspection tool, you’ll note that the result should be X and your product does Y…”.
Procurement as a Vehicle for Meeting Organizational IT Accessibility Objectives is a webinar by Chris Law, hosted by AccessGA. In the webinar the relative merits and pros and cons of different kinds of test process are discussed.
The title of this article specifically includes the two key words ‘make sure’. (“I’ve been told to make sure the things I procure are accessible. How do I do this?”) So how do we have a high degree of confidence that the ICT we procure will be accessible? We have focused on the need for a shared understanding via shared test processes, because that is the only way you can actually make sure that you are doing what everyone involved agrees to be considered ‘accessible’. Beyond documentation, you might ask the vendor how they tested. Did they use a specific process? Did they test with assistive technologies, code inspection methods, or both? How mature is their testing program? You could plan for testing yourself, or ask vendor demonstrations using the platform and assistive technologies used by your end users.
Accessible Technology: It Starts with Procurement is an article by Jeff Kline, hosted by the Partnership on Employment & Accessible Technology (PEAT). For those who are new to the concepts of procurement of accessible ICT, the article describes step by step elements such as market research, and reviewing solicitation responses.
About this article
This article is published as part of The Accessibility Switchboard Project, an initiative of the National Federation of the Blind Jernigan Institute with support from the members of the Accessibility Switchboard Project Community Of Practice, and from the Maryland Department of Disabilities.
The Accessibility Switchboard Project. Q&A: I’ve been told to make sure the things I procure are accessible. How do I do this?. January 2017, Version 1.0. National Federation of the Blind Jernigan Institute. Available: http://switchboard.nfb.org/
Feedback, additions and updates
The authors welcome feedback on this and other articles in the Accessibility Switchboard. Use the feedback form to provide updates, new case studies, and links to new and emerging resources in this area. The feedback form can also be used to join the mailing list for notification of new content and updates from the Accessibility Switchboard.
Copyright, use and reproduction
Accessibility Switchboard articles are published under the Creative Commons License Attribution-ShareAlike 4.0 International. You are free to share (copy and redistribute the material in any medium or format), and to adapt (remix, transform, and build upon the material) for any purpose, even commercially. This is under the following terms: (1) Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use; (2) ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. For more detail on the license, see CC BY-SA 4.0 on the Creative Commons website.
‘Proof is in the pudding’ by Chris M. Law & The Accessibility Switchboard Project. CC BY-SA 4.0.