Why and How to File a VPAT

If you look down the first column for Criteria in Table 1: Success Criteria, Level A, you see the following:

1.1.1 Non-text Content (Level A)

Also applies to:

Revised Section 508

501 (Web)(Software)

504.2 (Authoring Tool)

602.3 (Support Docs)

We follow the Revised Section 508 technical accessibility standards. We need to look at which IT types are appropriate here to review:

• Web refers to a website, webpage, or web component (e.g., embedded or a plugin that generates a portion of the page).
• Software is about all types of software (e.g., desktop software, mobile app, web application, plugins). This includes online training, since your audience interacts with the training interface.
• Authoring Tool might still be about the software but from the author’s perspective. Think about how you write a Word document. Word is the software for reading Word documents. Word is also the authoring tool for creating Word documents. What features of Word did you use to author the document versus features used to read the document?
• Support Docs or Electronic Docs typically reference a support website, Word or PDF document, or some other support content like video recordings.

On the last two columns, respond to each applicable IT type. You can do each one separately:

• Web:
• Electronic Docs:
• Software:
• Authoring Tool:

Some success criteria may not be applicable. For example:

2.4.1 Bypass Blocks (Level A)

Also applies to:

Revised Section 508

501 (Web)(Software) – Does not apply to non-web software

504.2 (Authoring Tool)

602.3 (Support Docs) – Does not apply to non-web docs

If your software is not based on web code (e.g., HTML, XHTML, PHP, ASP), then you don’t review this success criterion. Similarly, if your support documentation is not on a website, then you don’t review this success criterion for Support Docs either. But you do for all Authoring Tools.

If you do not agree that your IT is applicable for a particular success criterion, you must state why in the Remarks and Explanations. For example, while 1.2.2 Captions (Prerecorded) (Level A) is applicable for all IT types, you may not use video in your support documentation. Note that "the support docs do not have videos, so this success criterion is not applicable."

Accessibility should be in the lifecycle of the EIR, not a one-time-only review. EIR can fall out of compliance for many reasons:

• Planning stage: Accessibility features are forgotten. This happens as new modules or components are planned out.
• Design stage: Color choice, font sizes, and layout spacing are forgotten. This happens when updating the design aspects of modules or components.
• Development stage: Changes to modules or components accidentally remove access. For example, a previous "listener" to assistive technology is removed. The assistive technology can no longer access the modules or components.
• Maintenance stage: Technology goes through upgrades. The EIR should be checked for compatibility issues. For example, older bootstraps may no longer talk to assistive technology.

Project lifecycles already have a testing stage for finding and correcting bugs. These bugs may have to be prioritized on a roadmap for future correction. The VPAT can be reviewed and filed at that time, along with the roadmap.

Accessibility should be tested at all stages, not just a testing stage. This reduces the work needed during each stage.

Improving accessibility throughout the process reduces complaints and questions. Accessibility helps improve usability, so everyone benefits.

Universities are responsible for buying technology that people with disabilities can use.

It is always possible for a person with a disability to make an ADA accommodations request. The university will review the request for reasonableness. The university will then contact you for help.

Texas House Bill 1463 gives the us sixty (60) days to fix issues. It is important that we collaborate to find a solution. If the person with the disability does not see effort or transparency to fix the issue, they may file a lawsuit.

Lawsuits have consequences for us both. Reputations can be harmed. The university can lose funding and programs. You can lose business.

Audits can be initiated with or without lawsuits. These are done by the Office of Civil Rights (OCR). A lawsuit can focus or expand an audit based on findings. Universities have seen some patterns in the audits that you should note.

For example, one EIR may be found inaccessible in the complaint. However, the university is responsible for all its EIR. So the audit reviews all university relationships with companies. Any company refusing to provide accessibility documentation or help with accommodations is noted.

Many resolution agreements include deadlines for getting those relationships into compliance. If the deadline passes, those agreements often include ending those business relationships. If the university does not see a way to meet the deadline, they may have to end those business relationships.

It is beneficial to the university and all companies we work with to progress. Progress is emphasized. Accessibility has its own benefits. Accessibility has financial benefits for companies. It extends a company's market reach. Accessibility has support benefits. It reduces usability issues and complaint feedback.