As you commission a website, mobile app, experiential multimedia piece, or other digital interactive, it is critical to incorporate accessibility and inclusive design considerations throughout the process. Weaving inclusion-based goals into the process is an easy step an organization can take to engage in the meaningful and important work of creating materials and experiences that are born accessible for as many people as possible. This article explains how to procure digital services in a way that promotes accessibility and inclusion and helps to avoid the significant costs associated with remediation projects. Thinking about these things at the design phase of a project saves large sums of money, time, and frustration.

It is important to keep in mind that this article is a high-level overview. There are many best practices and operational considerations that arise on a case-by-case basis when procuring digital services. It is also important to acknowledge how I am situated in this conversation. I run a company, Prime Access Consulting (PAC), which does significant work in this space. In addition to pure digital accessibility projects, my work with Corey Timpson across dozens of cultural organizations in North America, Europe, and Asia addresses inclusive design across museum practice. Throughout this article, I have attempted to be conscious of any such biases. It is my sincere intention that the advice here help colleagues in making informed decisions for projects across the sector.

RFP Process

As you develop a request for proposal (RFP) or similar document, include accessibility as a requirement. If it is positioned as a nice-to-have rather than a need-to-have feature at the onset of a project, then it will continue being “nice to have” years after the project is over. Good intentions are not worth anything when a Deaf user cannot access a video with no captions, or a blind visitor is unable to interact with a kiosk. There are thousands of examples of this wish-for-the-best approach falling short, so let us make a conscious decision moving forward to do better.

Include specific accessibility requirements as deliverables within your RFP. This is your best opportunity to set expectations with potential vendors. For example, cite relevant standards like the Web Content Accessibility Guidelines (WCAG), which are at V2.1 at the time of writing, and make sure to explicitly mention you desire conformance at levels A and AA. To be blunt, if you receive pushback on this requirement (we once had a project where the vendor offered level A conformance instead of AA for a client), then that is cause for significant concern.

Skip over related stories to continue reading article

Early in the process, invite the vendor to discuss strategies around content accessibility, not just the programming and engineering aspects. It is essential to begin the conversation on workflows for content accessibility internally within your organization, such as: how are we developing captions for time-based media, authoring image descriptions, etc.? From there, you can determine how a potential vendor can support or be involved in the process.

Evaluating Proposals

In reviewing proposals, you will have the opportunity to prioritize various considerations as you make your selection. It is critical that this be a deliberate decision where you and all stakeholders reviewing agree on how to best balance and reflect the organizational values and needs in your choice. It is essential that you consider in the evaluation how a prospective vendor does or does not explicitly address accessibility and inclusive design. The following considerations are useful to keep in mind. No one criterion is a make or break, but when considered together, they begin to illustrate the accessibility and inclusivity awareness of potential vendors.

Proposal Considerations

• Is the proposal itself accessible? This does not have to be an exhaustive review, but does it use document semantics like headings, lists, and tables coded correctly? Can all the text be read programmatically? (This matters if a screen reader is interacting with the document.) How are the color contrast and font choices?
• Is accessibility mentioned in any substantial way? Has thought and consideration gone into discussing how the proposed work will be inclusively designed?
• Does the vendor have experience working on projects where accessibility was a real and actionable requirement? (No, having done work for the government and simply mentioning Section 508 does not satisfy this.)
• Is the vendor’s website accessible? A detailed analysis is not necessary—check with a browser extension like WAVE for a general overview. Can you navigate it using the keyboard? If you have access to accessibility experts, whether internal staff or external partners, ask them to perform a more nuanced check.
• Is the vendor willing to learn and do better, even if they do not have prior experience with accessibility and inclusive design? This ability to grow and learn with you is not only valuable for accessibility but across all aspects of the relationship.
• Does the vendor think about accessibility as just another requirement, or as an underlying philosophy incorporated into their methodology?
• Does the vendor offer a Voluntary Product Accessibility Template (VPAT) for their product? This VPAT should ideally be written by a neutral third party.

Contracting

When finalizing a contract, it is important to clearly delineate the responsibilities of the vendor and client when collaborating on accessibility-related matters. In addition to outlining responsibilities, it is critical to align interests between the parties so that everyone is traveling in the same direction towards a shared objective.

Based on the complexity of the project, your organization may find it valuable to partner with a third-party accessibility consultant or firm to review and ensure your accessibility goals are being achieved. It is important at this stage to consider how they are incorporated into the project workflow. More on this is detailed below.

The following list of considerations are useful to keep in mind when devising contract language.

Contract Considerations

• Make sure that accessibility requirements are clearly defined with measurable and evidence-based criteria, e.g. the work must conform with WCAG V2.1 at levels A and AA for website projects, or reference other institutional standards and best practices, such as internal inclusive design guidelines or specific accessibility requirements.
• Ensure that project milestones incorporate accessibility requirements at every stage, not just during implementation or testing post-production. For example, for website projects, the sequencing is design evaluation, markup/code collaboration, spot checks, formal WCAG evaluation, and re-check of evaluation results. Other models exist for exhibitions, digital interactives, physical programming, and more.
• Tie the aforementioned accessibility considerations in project milestones to payment outcomes. This way, accessibility is not relegated to the end of the project and then subsequently dropped due to other “pressing concerns.” When this happens, it often needlessly forces the museum to choose between doing the right thing and completing the project on time. This is as unnecessary as it is deeply harmful.
• When considering the timing of milestones, especially around launch, be sure to include sufficient time for evaluations and accessibility testing. For example, website audits can take four to six weeks depending on number of pages, complexity, and scheduling concerns, which means that if an audit is started a month before launch, the developers will have no time to fix any findings. This sequencing concern is another reason why the iterative model expressed above is important to follow (hopefully there is not much left to fix by the end of the project).
• Make sure that statements of work lay out both the need and time for the discussions around content accessibility that require the vendor—these must happen early in the project. This discussion should focus on key concerns involving development that impact content accessibility, such as: does the backend of the digital interactive offer a facility for describing images, delivering captions, and displaying sign language? In addition to these concerns, ensure your organization has the bandwidth to establish a content accessibility strategy.
• Ensure the vendor’s statement of work explicitly defines that repeated efforts to remediate known accessibility violations are performed at the vendor’s expense. It is not fair to the client to repeatedly pay a vendor to fix their own initially inaccessible work. We see this far too often within website projects. Aside from the harm to the client and end users, this setup gives a false impression around the costs of accessibility to those with less insights or technical experience to understand the nuanced reasons for those expenses.

Accessibility Consultant Involvement

If you are partnering with accessibility consultants, it is critical to bring them into the project from the start. This leads to a far more inclusively designed end product, and it saves resources (both financial and personnel), because previous decisions need not be remediated or changed based on their feedback. The terms of this collaboration should inform the vendor requirements in any relevant statements of work, e.g. the vendor must be available to hop on calls with said consultant.

Accessibility Consultant Criteria

• Is the vendor’s own website accessible?
• Will they collaborate within your development and issue tracking environments?
• Do they understand the way organizations within your field operate?
• Do they possess a strong understanding of both the technical requirements (WCAG, ARIA, etc.) and content-level considerations (visual descriptions, workflow considerations, collaboration within institutional or grant-defined mechanisms)?
• Do they follow an evaluation methodology that involves manual testing across browser and assistive technology combinations and employ persons with disabilities who are native users of these assistive technologies?
• Do they welcome and encourage a collaborative process throughout the project, or just offer an audit at the end? (In fifteen years of doing this work, I have never witnessed a project that achieved accessibility conformance from only an audit.)

Conclusion

Incorporating initial considerations into the procurement process not only ensures that accessibility and inclusion objectives can be met, but results in an end product that is overall more sustainable, intentional, and welcoming.

I have discussed the above considerations with a focus on procuring website-development-related services, but it is important to recognize that parallels exist in all forms of digital services and potential procurement needs. Interactives, experiential media, mobile apps, and other digital technologies all require and benefit from equal thought and intention when approaching accessibility and inclusive design.

The work of digital accessibility is often phrased as expensive, difficult, or burdensome. By incorporating the recommendations here into your workflow and throughout project milestones, the work of digital accessibility is instead embedded in your process. Being intentional in how you incorporate accessibility and inclusion into procurement, from developing an RFP through finalizing contracts, will help ensure your digital experiences are born accessible and can be enjoyed by all users.