What accessibility questions do I need to ask my vendor before purchasing a Mobile App?

Please use the following checklist before starting your mobile App:

1. Does the App have a VPAT?

A VPAT is a Voluntary Product Assessment Template. It documents how accessible an App is using WCAG criteria. To ensure the App is accessible to people with disabilities we want them to be largely WCAG 2.0 AA compliant.

  • White-labeled Apps are more likely to have a VPAT. It is a clear indicator that the vendor has experience creating accessible Apps. This speeds up the ability for Duke to do accessibility assessments.
  • Custom Apps usually do not have a VPAT already, because it is new custom work. It does not mean it has problems. It does mean it will take longer to assess if the App conforms to WCAG criteria.

Apps with a VPAT indicating WCAG 2.0 AA compliance are the smoothest route to launching an accessible app.

2. Does the vendor have an accessibility statement?

An accessibility statement demonstrates a company's commitment to creating accessible products.

  • Vendors with an accessibility statement shows some accessibility awareness.
  • If a vendor does not already have an accessibility statement, it tends to demonstrate a lack of accessibility awareness.

3. How will the vendor verify that the App is accessible and conforms to applicable WCAG criteria?

  • They should describe their mobile App QA testing process. This should include automated tests, manual checks, and testing with screen readers.
  • If an app is made for both Android and iOS they need to be tested separately.

4. If the App hosts a service that provides human-to-human interaction, does it allow for third parties to join the interaction to provide accommodations?

  • Participants who are deaf or hard of hearing may need the ability for sign language interpreters or live human captioners to join the interaction.
  • Participants who are blind or have low vision may also need the ability to add a participant for assistance.

5. Include accessibility requirements in the procurement language so expectations are clear.

  • When vendors and customers start out on the same page, there will be fewer surprises when it's too late. 

6. When agreeing to a timeline, allow enough time for reviews.

Assessments are free for Duke websites.  Reviewing the designs for accessibility issues before code development starts will always save you money. Set milestones with your vendor for that leave room for accessibility reviews. 

  • Let us know when you start a new project to get on our schedule.

    • Design review:
      • If it is on our schedule, one day for design reviews is usually adequate. 
      • If it is not on our schedule, we will work it in as soon as we can. 
    • Functionality/code review:
      • Please leave 5 business days.  If it is on our schedule, it might take one day. If there are a lot of problems it will take more days. 
      • If it is not on our schedule, we will work it in as soon as we can. 
  • We need to ensure people with disabilities have equal access to the website and it's web content before it launches.
  • The fanfare and social media that go along with launching a website bring attention to it. External entities look for new website launches and will scrutinize the work for accessibility. 
  • The drama involved in fixing a site after launch is unnecessary and stressful for all parties. 

When a vendor knows the app will be reviewed they will do better work.

  • They are more likely to review the website for quality assurance.
  • They are more likely to put better developers on the project. 

Helpful documentation and articles for vendors: