Completing an Accessibility Conformance Report (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:

Remove the categories not relevant to your product or service.

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 do not review this success criterion. If your product is an authoring tool, then you will respond to the Authoring Tools category.

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. In that case, note that "the support docs do not have videos, so this success criterion is not applicable."

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

• 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 ICT 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. Digital accessibility issues must be identified as bugs. These bugs should be prioritized on a roadmap for future correction. Complete a new ACR 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.

Refer to Section 508's Guide to Accessible Web Design and Development and the W3C's ARRM: Accessibility Roles and Responsibilities Mapping.

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 for 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 ICT may be found inaccessible in the complaint. However, the university is responsible for all its ICT. 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.