Obtaining a Temporary Exception from the Office of Digital Accessibility

If you are proceeding with procuring, implementing, or renewing usage of a digital product or service with known accessibility issues then our office will assist you in preparing a Temporary Exception. A Temporary Exception documents:

1. Details about the product, its intended use, audience type, and size

2. The justification for proceeding with an inaccessible product

3. Details about inaccessible features

4. Alternative access plans to support any user who encounters an accessibility barrier

5. Plans and timelines for making the product accessible or replacing it with one that is

Before requesting a Temporary Exception, please gather the following information:

1. Designated owner or primary POC for the product 
   ​This person should have a good understanding of how to use the product and be able to communicate with the vendor about accessibility requirements and complaints.

   • If this is a High Risk product, then also identify the appropriate senior leadership member who can review and provide approval for the document once completed.

2. Description of the product and its intended use/functionality at Stanford

3. Types of users

   • Students

   • Prospective students

   • Staff

   • Faulty

   • Alumni

   • General public

4. Number of users 
   If there are multiple types of users, such as staff administrative and students, then capture counts for each user type.

5. Whether the product is required for use by students and/or staff or faculty

   • Students

     1. No, not required

     2. Yes, but not required

     3. Yes, not required, but highly recommended or improves student experience

     4. Yes, required

   • Staff or faculty

     1. No, not required

     2. Yes, but not required

     3. Yes, not required, but highly recommended

     4. Yes, required

6. Whether the product is already in use and for how long

7. Accessibility documentation from the vendor. Ask them for the following:

   • Information or formal documentation (VPAT, Accessibility Conformance Report, etc.) about how the current product version conforms to the Web Content Accessibility Guidelines 2.0 (WCAG 2.0), Level A and Level AA standard. Formal documentation is expected to be dated within the past 12 months.

   • Contact information for the designated representative at the company to address issues, questions, or the resolution of accessibility barriers in the application.

   • Description of the types of automated and manual accessibility testing procedures that are conducted as part of the software development lifecycle, including any specific tools and/or assistive technologies used.

8. Results of an accessibility review completed by our office
   If no review has been completed, you can submit a request for review if an environment is available. 

9. Contract length or planned lifecycle:

   • Less than a year

   • 1-2 years

   • 3-5 years

   • More than 5 years

10. Information about why this product was chosen despite accessibility issues. This usually falls into the following categories with supporting comments:

    • Commercial unavailability: this product is the only or best solution in the marketplace to meet the business needs despite its deficiencies. 

    • Restricted/limited access: only a few people will use the service with none having known disabilities that will impact their access to it.

    • Fundamental alteration to business operations or program service (need some description of this)

    • Other (provide details)

11. Contact method, details, and expected response time for a user to report an accessibility issue

12. Alternative access plans to provide the same information or service for someone who does run into a barrier

13. If available, plans and timelines from the vendor or developer to address accessibility issues and bring it into substantial conformance with WCAG 2.0 AA

When you have gathered as much of this information as possible, you can submit the temporary exception request form. 

After a request is submitted a representative from our office will reach out and either schedule a meeting to gather more information up front, or create a draft of the Temporary Exception and share it for review and editing.

Completing the document is a collaborative process and may necessitate one or more meetings to complete all sections. 

Once all sections are complete our office Director, Sean Keegan, will do a final review and add his signature. If the product is high risk, this will not be done until after the senior leadership member has reviewed and approved from the business side.