Are you embedding accessibility into your procurement process?
What is the procurement process?
- Identifying the need: This involves an organisation identifying what goods or services are required and the quantity needed.
- Budgeting: The organisation sets a budget for the procurement process, including any associated costs such as shipping or handling fees.
- Sourcing: The organisation looks for potential suppliers or vendors that can provide the required goods or services.
- Evaluating vendors: The organisation evaluates potential suppliers based on criteria such as quality, price, and delivery time.
- Negotiating contracts: The organisation negotiates a contract with the chosen supplier that outlines the terms and conditions of the purchase.
- Purchasing: The organisation places an order with the supplier and pays for the goods or services.
- Receiving and inspecting the goods or services: The organisation receives the goods or services and checks them to ensure they meet the required specifications.
- Approving invoices: The organisation approves the supplier’s invoice and processes payment.
- Managing supplier relationships: The organisation maintains their relationships with suppliers to ensure they continue to meet their needs.
The items above easily explain the procurement process, but did we miss anything? Yes, accessibility!
What often happens is that an organisation fails to identify accessibility as a core requirement of the goods or services they need. It is most likely identified during or after the initial processes, which can make it difficult to “bolt on” accessibility, in comparison to incorporating it into the initial design. IA Labs encourages everyone to “move accessibility to the left”: digital accessibility should be part of the initial identifying stages of your project.
Let us look at these processes again, but now consider accessibility.
Identifying the need
You have identified the needs of your project and all its functional requirements. This is the very stage where digital accessibility should be introduced: what is my product’s demographic, and don’t I want everyone to use and avail of it?
If yes, the WCAG 2.1 Guidelines, the POUR Principles, and UI/UX design for people with disabilities should be incorporated into your project.
Budgeting
“Bolting on” accessibility or adding it to a product after the fact can be considerably more costly than identifying the need at the design phase and developing the product with accessibility in mind.
Consider architects who had to add ramps and railings to their buildings after construction, often at great expense and to the detriment of the design. When architects included accessibility into their project from the start, all benefited from a universal design that saved money. This is the same principle that should be applied to technology projects: when stakeholders, designers, and developers are all in sync with accessibility, there will be no surprise costs down the line.
Sourcing
During the sourcing stage, we should endeavour to research vendors and their approach to accessibility. Do they have an accessibility statement on their own website? Have they delivered previous projects that gained attention in the accessibility community? Have they worked with or partnered with an accessibility team?
Evaluating vendors
Speaking to vendors is key to gathering information and discerning if they can deliver your project in full, on time, and completely inclusive of all demographics. This can increase the outreach of your product by as much as 30%.
Negotiating contracts
At the contract stage, your digital accessibility needs should be clearly identified in your tender (RFT) or quotes (RFQ). For example, you might be building a website that must comply with the WCAG 2.1 AA standard. This should be clearly stated as a required deliverable. You should also state that your project should be manually tested against all 78 success criteria of the WCAG 2.1 guidelines. If your vendor can’t deliver this niche set of skills or complete the accessibility QA process by themselves, then it should be stipulated that an outside party like IA Labs would have to ensure these requirements are met.
Purchasing
After the tendering and RFQ stage, it should be ensured that any contracts with outside organisations use a fully manual accessibility auditing process over an automation that won’t check against all 78 success criteria in the WCAG. This can be arranged by the supplier or product owner.
Receiving and inspecting the goods or services
The product must meet WCAG 2.1 AA guidelines as agreed in the contract stages. This can be done through a quality assurance (QA) process of manually checking the product, including the delivery of an accessibility issue log. The responsibility to fix these issues would fall on the vendor because they agreed to meet these guidelines. As stated in the contract, no further costs would fall on the client since complying with the WCAG was an agreed deliverable.
Approving invoices
Payments would be made as agreed in the contract. The use of external accessibility auditing services would either carry its own invoice or be included in the original agreement with the vendor.
Managing supplier relationships
Having an ongoing relationship with vendors is key to keeping your product accessible. In some cases, an ongoing contract for maintenance is often used on websites. This ongoing contract should also follow these processes so that digital accessibility remains a priority.
Any feature changes and updates would use the manual QA process. This will ensure these new features are accessible and changes have not broken a website’s accessibility. External vendors such as IA Labs might be required to complete this QA process or train new content management staff to create accessibility content and match the intent of your accessibility statement.
How can IA Labs help?
If you have any questions or need additional advice on making sure your procurement processes are accessible and meet the WCAG 2.1 guidelines, please feel free to contact IA Labs.
