Federal Section 508 gets most of the attention when teams talk about government procurement and accessibility. States have their own versions of the same requirement, and Texas runs one of the more procedurally strict ones in the country. Under 1 Texas Administrative Code Chapter 206, which governs state websites, and Chapter 213, which governs the procurement, development, and use of electronic and information resources more broadly, vendors working with Texas state agencies and institutions of higher education are expected to meet documented accessibility standards, and the Texas Department of Information Resources builds that expectation directly into how solicitations are evaluated.
The practical version of this rule is simple and easy to miss: vendors are required to submit accessibility documentation with their solicitation responses, and to provide updated documentation when a state agency or university requests it. Under current DIR contract requirements, that standard is WCAG 2.1 Level AA, aligned with Texas Government Code Chapter 2054 and the state's EIR accessibility framework. A proposal missing that documentation, or submitting documentation that does not hold up, can be screened out procedurally before a single reviewer evaluates the actual product being pitched.
The Fact: Texas Administrative Code 1 TAC 206 (state websites) and 1 TAC 213 (electronic and information resources) both align with federal Section 508 and currently point vendors toward WCAG 2.1 AA for state contracts and procurement. (Source: Texas Department of Information Resources, Digital Accessibility Procurement and Vendor Resources)
Two Rules, One Practical Requirement
1 TAC 206 governs Texas state agency websites directly, aligning state web standards with federal Section 508. 1 TAC 213 is broader: it governs electronic and information resources procurement, development, and use across state agencies, and this is the rule that most directly shapes how vendors get evaluated. Together, they mean that an accessibility standard applies both to what a state agency builds itself and to what it buys from an outside vendor, and the procurement side is enforced through required documentation submitted alongside a bid, not through a separate compliance audit that happens after a contract is already signed.
For a vendor, the operative fact is that DIR contracts require compliance with Texas Government Code 2054, 1 TAC 206, 1 TAC 213, and WCAG 2.1 AA, and vendors must submit accessibility documentation with their solicitation response. That documentation is functionally similar to a federal VPAT, an accessibility conformance report describing how the product performs against the relevant WCAG criteria, but tied specifically to the Texas procurement process rather than the federal one.
Why This Screens Out Bids Before Technical Review
Procurement evaluation for large state contracts is typically structured in stages, and administrative or compliance completeness is frequently checked before technical merit is evaluated at all. A proposal that is missing required accessibility documentation, or that submits a generic, clearly unverified document copy-pasted from a federal VPAT template without being adapted to the actual product being bid, can be flagged as administratively incomplete. That is a very different failure mode from losing on price or features. It means the evaluators scoring the actual technical proposal may never see it, because the bid did not clear the compliance gate that comes before that scoring even starts.
This is the same structural risk documented in our piece on how a Section 508 rejection kills a federal deal before it starts, just at the state level instead of the federal one, and Texas is one of the more procedurally explicit states about requiring this documentation up front rather than treating it as a post-award formality.
What Good Documentation Actually Requires
A defensible accessibility document for a Texas state solicitation is not a boilerplate statement claiming general WCAG awareness. It needs to reflect the actual product being proposed, ideally backed by a real third-party or independently verified accessibility evaluation against WCAG 2.1 AA criteria, not a self-attestation with no supporting evidence. Vendors that have never had their product actually tested against WCAG 2.1 AA are, in practice, submitting a document that will not survive a closer look if a Texas agency's procurement team asks a follow-up question, which they are increasingly likely to do given how much scrutiny state accessibility compliance now receives.
The Ongoing Obligation, Not Just the One-Time Bid
Vendors are also required to provide updated documentation when requested after a contract is already in place, which means this is not a one-time hurdle cleared at bid time and then forgotten. A product that passed WCAG 2.1 AA review at the start of a multi-year state contract and then shipped several redesigns without re-testing can find itself unable to produce current, accurate documentation when a state agency asks for a refresh, creating contract risk well after the sale closed.
If your company sells software or digital services to Texas state agencies, universities, or any public entity requiring EIR accessibility documentation, getting a real, current, independently verified conformance report in place before your next solicitation is worth doing well ahead of the deadline, not during the scramble to submit a bid. Our broader Section 508 guide for vendors selling to US government covers the federal-level equivalent of this same documentation requirement in more depth.
Our team can run a real WCAG 2.1 AA evaluation of your product and help you build documentation that will actually hold up under a Texas agency's review. Reach us at experts@wcag.world, or review the Texas DIR's own procurement and vendor resources and EIR accessibility tools directly for the current requirements.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: request the relevant WCAG review.