Project Management and Procurement

Digital accessibility should be considered throughout the lifecycle of a digital product or service—from initial planning and requirements through selection, implementation, monitoring, renewal, and retirement.

Use this page to identify accessibility responsibilities, include accessibility in project and procurement activities, review vendor evidence, evaluate products, document decisions, and monitor accessibility after implementation.

Purchasing, licensing, piloting, accepting, or using a product provided by another organization does not transfer the public entity’s responsibility to provide accessible programs, services, activities, information, web content, and mobile applications.

The depth of the review may be scaled according to the product’s use and risk. However, low cost, free access, placement on an approved-product list, or availability through an existing contract does not by itself establish that a product is accessible.

Using this guidance

This page provides general implementation guidance and should not be interpreted as legal advice or as a replacement for established procurement, contracting, technology, security, privacy, or legal-review processes.

NCDPI offices should follow applicable NCDIT, state procurement, agency, and legal requirements. Public school units should integrate accessibility into locally adopted procurement and technology-review processes and consult the appropriate local procurement staff, administrators, and legal counsel.

For current legal requirements and technical standards, visit Understanding Digital Accessibility Laws and Requirements.

Quick references

These resources complement the fuller lifecycle guidance below.

Start with where you and your system are right now

Select the part of the lifecycle that best matches the work currently underway:

  1. Plan the project or purchase
  2. Define accessibility requirements
  3. Prepare the solicitation or purchase
  4. Review vendor accessibility evidence
  5. Demonstrate and test the product
  6. Compare options and document the decision
  7. Include accessibility in the contract
  8. Implement and monitor the product
  9. Renew, replace, or retire the product
  10. Use templates and working tools
  11. Find information for vendors
  12. Address questions requiring legal review

Plan for the project or purchase

Accessibility decisions should begin before a solicitation is written, a product is selected, or a development project begins. Early planning helps the team identify intended users, important tasks, product risks, evidence needs, testing responsibilities, and decision authority.

What to do:

  • Define the educational, programmatic, operational, or business need.
  • Identify the people who will use or interact with the product, including students, families, employees, educators, administrators, and members of the public with disabilities.
  • Identify the most important tasks each user group must be able to complete.
  • Consider the ways users may access the product, including keyboard navigation, screen readers, screen magnification, voice input, captions, personalized display settings, mobile devices, and other assistive technologies.
  • Identify all relevant product components. These may include public webpages, authenticated interfaces, mobile applications, administrative tools, forms, dashboards, documents, reports, media, integrations, and third-party content.
  • Identify the project owner, procurement contact, technology owner, accessibility reviewer, program representative, decision-maker, and any required legal or policy reviewers.
  • Include accessibility in the project scope, requirements, user stories, acceptance criteria, schedule, and issue-tracking process.
  • Include people with disabilities or staff who understand their access needs when defining user journeys and reviewing important workflows.
  • Determine whether an existing accessible product or service can meet the need before purchasing or developing another tool.
  • Plan time and resources for documentation review, demonstrations, testing, remediation, training, implementation, and ongoing monitoring.
  • Identify accessibility risks early rather than waiting until selection or launch.

What to document

Retain:

  • The identified need.
  • Intended users and user roles.
  • Critical user tasks.
  • Product components and integrations.
  • Accessibility responsibilities.
  • Applicable requirements.
  • Planned evidence and testing.
  • Identified risks.
  • Budget and scheduling considerations.
  • The person or group authorized to make the final decision.

Planning resources

The NCADEMI directory is a research starting point. Product information should still be confirmed with the vendor and evaluated against the organization’s intended use.

Define accessibility requirements

Accessibility should be defined as a product requirement rather than treated as an optional feature or discussed only after a product has been selected. Requirements should address both the applicable standards and the actual tasks users must be able to complete.

What to do:

  • Identify the applicable laws, policies, technical standards, and organizational requirements.
  • For covered web content and mobile applications under ADA Title II, include WCAG 2.1 Level A and Level AA.
  • Identify any additional functional or technical requirements that apply to software, hardware, documents, media, authoring tools, support services, or other product components.
  • Describe the critical tasks that people with disabilities must be able to complete.
  • Apply the requirements to the actual product; not only the vendor’s public marketing website.
  • Identify all product versions, modules, user roles, interfaces, integrations, and platforms included in the purchase.
  • Include requirements for keyboard access, visible focus, meaningful labels, understandable errors, text resizing, zoom and reflow, contrast, media access, assistive-technology compatibility, and other relevant outcomes.
  • Address the accessibility of documents, reports, dashboards, exports, training materials, help content, and customer-support systems.
  • For authoring tools, require information about how the product supports the creation and validation of accessible output.
  • Include accessibility expectations for updates, upgrades, new features, configuration changes, and integrations.
  • Identify the accessibility evidence the vendor must provide.
  • Define how accessibility will be evaluated, scored, accepted, monitored, and documented.
  • Identify responsibility for correcting barriers and providing timely access while unresolved issues are addressed.

Avoid vague requirements

Statements such as “the product should be accessible,” “the vendor should follow accessibility best practices,” or “the product should be ADA compliant” do not create a clear, testable expectation.

Identify the applicable standard, covered product components, required user tasks, vendor evidence, evaluation activities, and acceptance process.

Special consideration for instructional materials

Purchases involving textbooks and related core instructional materials may include responsibilities under the National Instructional Materials Accessibility Standard and the National Instructional Materials Access Center.

NIMAS and NIMAC support the production and timely delivery of accessible formats such as braille, large print, audio, and accessible digital text for eligible students. They do not replace the broader responsibility to procure accessible digital educational materials and technology.

Use:

Requirements resources

Prepare the solicitation or purchase

Include accessibility expectations in the initial solicitation, purchasing process, development agreement, or product-review request. Raising accessibility only after selection limits the organization’s ability to compare products, negotiate commitments, and choose a product that supports intended users.

Include the following:

  • The applicable accessibility requirements and standards.
  • The product components, versions, platforms, and user roles covered by the requirements.
  • The critical user tasks the product must support.
  • The accessibility documentation vendors must submit.
  • A request for a current, product-specific Accessibility Conformance Report when appropriate.
  • Requirements for the vendor to disclose known barriers and affected workflows.
  • Supplemental accessibility questions when an ACR does not provide sufficient information.
  • An identified vendor accessibility contact.
  • Accessibility-focused demonstration expectations.
  • Independent testing or testing-evidence expectations when appropriate.
  • Requirements for accessible documentation, training, support, reports, and generated content.
  • Accessibility scoring or evaluation criteria.
  • Expectations for remediation plans or roadmaps when barriers exist.
  • Accessibility deliverables that must become part of the final agreement.
  • Responsibility for costs associated with agreed remediation, retesting, and accessible alternatives.
  • Expectations for product updates, new releases, integrations, and future accessibility evidence.

For smaller or informal purchases

Formal RFPs are not the only decisions that require accessibility review.

Apply the same core questions, scaled to risk, when reviewing:

  • mall purchases.
  • Subscription renewals.
  • Free or freemium tools.
  • Pilots and trials.
  • Donated products.
  • Grant-funded technology.
  • Products selected directly by a school, department, classroom, or program.
  • Add-ons, extensions, plugins, and integrations.

At a minimum, document the intended use, critical tasks, available accessibility evidence, known barriers, and the person who approved the decision.

Solicitation resoruces

 

Review vendor accessibility evidence

Vendor documentation can help a review team understand the accessibility of a product. However, the presence of documentation does not establish that the product is accessible or that it will support the organization’s intended users and tasks.

VPAT or ACR?

The Voluntary Product Accessibility Template, or VPAT®, is the blank reporting template maintained by the Information Technology Industry Council.

When a vendor completes the appropriate VPAT with product-specific evaluation results, the completed document is an Accessibility Conformance Report, or ACR.

The term “VPAT” is often used informally to refer to the completed report. This page uses VPAT for the template and ACR for the completed product report.

Evidence to request

Depending on the product and its level of risk, request:

  • A current, product-specific ACR.
  • The product name, version, components, modules, interfaces, and platforms covered.
  • The report date.
  • The standards and WCAG versions included in the report.
  • A description of evaluation methods.
  • The automated tools, manual tests, assistive technologies, browsers, devices, and operating systems used.
  • Information about who performed the evaluation.
  • Known accessibility barriers and affected workflows.
  • Independent audit or testing reports, when available.
  • Accessibility documentation and user instructions.
  • Installation and configuration information needed to support accessibility.
  • Samples of accessible output produced by authoring tools.
  • An accessibility contact and escalation process.
  • A remediation roadmap identifying specific issues, planned actions, product versions, owners, and target dates.
  • Information about testing by people with disabilities.
  • Information about accessibility in product design, development, quality assurance, and release processes.

Review the nontechnical information first

Confirm:

  • The product name and version match the product under consideration.
  • The report is recent enough to reasonably represent the current product.
  • The report covers the modules and interfaces the organization intends to use.
  • The correct standards and WCAG version are included.
  • The vendor provides a meaningful accessibility contact.
  • The evaluation methods describe more than general product knowledge or an automated scan.
  • The report explains which assistive technologies and manual methods were used.
  • Notes and introductory sections provide useful information about product scope, known limitations, and evaluation.

Review the conformance tables

For each applicable criterion:

  • Review the vendor’s conformance claim.
  • Read the remarks and explanations.
  • Look for product-specific implementation details.
  • Identify the affected feature or workflow when support is partial.
  • Identify the user impact when the product does not support a criterion.
  • Confirm that “Not Applicable” is explained.
  • Treat criteria that were not evaluated or that lack evidence as unanswered questions.
  • Request clarification when remarks repeat the criterion without explaining product behavior.
  • Compare the claims with product demonstrations, testing, user reports, and other evidence.

Warning signs

Follow up when:

  • The ACR is several product versions old.
  • A cloud product has a substantially outdated report.
  • The product, version, or scope is unclear.
  • Important product components are excluded.
  • The report covers the vendor’s marketing website rather than the purchased product.
  • The evaluation methods are missing or vague.
  • Nearly every criterion is marked “Supports” with little explanation.
  • Remarks repeat WCAG language rather than describing the product.
  • Automated testing appears to be the only evaluation method.
  • The vendor does not identify known barriers.
  • The vendor cannot explain how a “Partially Supports” or “Does Not Support” claim affects users.
  • The vendor does not have an accessibility contact.
  • The vendor treats the existence of an ACR as proof of accessibility.
  • The vendor refers to a “VPAT certification.” ITI provides the template but does not certify VPATs or ACRs.
  • The vendor will not demonstrate important accessibility-related workflows.
  • The roadmap lacks specific issues, owners, product versions, or target dates.

ACR resoruces

Demonstrate and test the product

A product demonstration should show how people complete real tasks—not only display an accessibility settings menu or describe the vendor’s intentions. Testing should focus on the product version, configuration, components, and workflows the organization expects to use.

Before the demonstration

  • Select three to seven important user tasks.
  • Include tasks performed by different user roles when applicable.
  • Prioritize tasks that are essential to participation or independent use.
  • Give the tasks and expected accessible outcomes to the vendor in advance.
  • Identify the keyboard, assistive-technology, zoom, mobile, media, document, or communication features that should be demonstrated.
  • Ask the vendor to use the version and configuration under consideration.
  • Include program, accessibility, technology, procurement, instructional, and user representatives as appropriate.
  • Include people with disabilities when possible and appropriate.
  • Prepare a shared worksheet for recording findings.
  • Determine whether the session may be recorded or whether detailed notes are needed.

During the demonstration

Ask the vendor to demonstrate applicable tasks using:

  • Keyboard-only navigation and operation.
  • Visible keyboard focus.
  • Logical focus order.
  • Screen-reader navigation and interaction.
  • Text resizing, browser zoom, and responsive reflow.
  • Forms, labels, required fields, instructions, errors, and confirmation.
  • Menus, dialogs, tables, filters, dashboards, and dynamic updates.
  • Captions, transcripts, audio description, and media-player controls.
  • Documents, reports, and exports produced by the product.
  • Administrative, educator, student, employee, family, and public interfaces as applicable.
  • Mobile applications or mobile web access.
  • Authentication and single sign-on.
  • Integrations, embedded content, extensions, and third-party components.
  • Help systems, support forms, and user documentation.
  • Content-creation features when the product is an authoring platform.

As the vendor to explain

  • Which product areas have known accessibility barriers.
  • Which assistive technologies have been tested.
  • How accessibility defects are reported and prioritized.
  • How people with disabilities participate in product testing.
  • How new releases are checked for accessibility regressions.
  • What fixes are planned and when they are expected.
  • How accessibility support questions are escalated.
  • How customers are informed of known barriers and workarounds.

After the demonstration

  • Record identified barriers, affected users, severity, frequency, and available workarounds.
  • Compare the demonstration with the ACR and other vendor claims.
  • Identify what was demonstrated but not independently verified.
  • Request written follow-up for unanswered questions.
  • Request a remediation roadmap for significant barriers.
  • Conduct or obtain independent testing for higher-risk products when appropriate.
  • Test representative critical tasks rather than relying only on a general scan.
  • Document the evaluation team’s findings and any conditions that would need to accompany a purchase.

A demonstration is evidence, not proof

A successful scripted demonstration does not establish that the complete product is accessible. Use demonstrations together with documentation review, testing, user feedback, and ongoing monitoring.

Demonstration and testing resources

Compare options and document the decision

Compare products using the same documented accessibility requirements, intended users, critical tasks, and evidence expectations.

Whenever possible, incorporate accessibility into the organization’s existing scoring matrix, product-review process, procurement record, and approval workflow rather than creating a separate accessibility-only decision process.

The review should consider

  • Whether important tasks can be completed independently.
  • The severity and user impact of identified barriers.
  • Whether barriers affect timeliness, privacy, independence, participation, or ease of use.
  • The quality and credibility of available evidence.
  • Whether vendor claims align with demonstrations and testing.
  • Whether workarounds provide genuinely comparable access.
  • The feasibility and specificity of vendor remediation commitments.
  • The accessibility of other available products.
  • The organization’s intended use, length of use, and ability to monitor unresolved issues.

Use decision language tied to the review scope

Appropriate decision outcomes may include:

  • Meets the documented accessibility requirements for the reviewed scope and use.
  • Meets the documented requirements with specified conditions or remediation commitments.
  • Does not currently meet one or more critical accessibility requirements.
  • Insufficient evidence is available to make an informed decision.
  • Additional demonstration, testing, or vendor clarification is required.

Avoid labeling an entire product simply “compliant,” “partially compliant,” or “noncompliant” when the review covered only selected documentation, components, or tasks.

Document the review

At a minimum, retain:

  • The product and version reviewed.
  • The intended use and expected length of use.
  • Intended users and critical user tasks.
  • The product components included in and excluded from the review.
  • The scope and limitations of the accessibility review.
  • The documentation, demonstrations, and testing considered.
  • Significant barriers and their likely effect on users.
  • Available workarounds or interim access methods.
  • Vendor explanations and remediation commitments.
  • The accessibility recommendation.
  • The organization’s final decision.
  • Any conditions, responsible parties, target dates, and verification expectations.
  • The date of the next accessibility review or renewal decision.

Retain this information with the organization’s other procurement, technology-review, project, or contract records rather than maintaining a separate accessibility record when the existing process can capture it adequately.

Resources for comparison and decision making

Optional documentation aid

Organizations should incorporate accessibility into their existing procurement, product-review, project-management, and approval records whenever possible.

Teams whose existing process does not capture sufficient accessibility information may use the Optional Digital Accessibility Review Addendum and adapt it to local procedures.

The addendum is a planning and documentation aid. Completing it does not certify that a product is accessible, establish legal compliance, approve a purchase, or determine that an exception applies.

 

Include accessibility in the contract

Accessibility commitments made during evaluation should be reflected in the final agreement. Verbal assurances, sales presentations, and informal roadmaps are difficult to enforce when they are not incorporated into the organization’s approved contracting process.

Contract terms and sample language should be reviewed through the organization’s normal procurement and legal processes. Examples and guidance are starting points and should not be treated as legal advice.

Contract topics to address

Depending on the product and agreement, consider:

  • The applicable accessibility standards and requirements.
  • The product, version, modules, interfaces, integrations, and services covered.
  • The vendor’s submitted ACR and other accessibility representations.
  • Required accessibility documentation and support.
  • The accessibility of vendor-created documents, training, media, help systems, and support materials.
  • The accessibility of content produced by an authoring tool.
  • Known barriers and agreed remediation commitments.
  • Specific corrective actions, responsible parties, affected product versions, and target dates.
  • Acceptance criteria and validation of completed fixes.
  • Reporting of newly discovered accessibility defects.
  • Vendor cooperation with testing, complaints, and user reports.
  • Accessibility expectations for updates, upgrades, redesigns, and new features.
  • Regression testing after significant product changes.
  • Notification before changes that may affect accessibility.
  • Accessibility training for administrators, content creators, or users when needed.
  • Product configuration needed to support accessibility.
  • Accessibility contacts and escalation procedures.
  • Responsibility for remediation, retesting, and related costs.
  • Documentation that must be updated before renewal.
  • Corrective-action, renewal, replacement, or termination options where appropriate.

Do not rely only on

  • A general statement that the vendor supports accessibility.
  • A promise to follow accessibility best practices.
  • The existence of an ACR.
  • A roadmap without specific barriers, owners, product versions, and dates.
  • A requirement that places all responsibility on the purchaser to provide accommodations after barriers occur.
  • A contract clause that cannot be verified through evidence, testing, or acceptance criteria.

Contract resources

Implement and monitor the product

Accessibility review does not end when a contract is signed. Configuration, customization, integrations, local content, updates, and changes in user workflows can introduce new barriers or expose barriers that were not identified during procurement.

During implementation

  • Confirm that the implemented version, modules, and configuration match what was evaluated.
  • Test important workflows before broad release.
  • Review authentication, single sign-on, integrations, embedded content, and mobile access.
  • Confirm that local branding, themes, or customization have not introduced barriers.
  • Review administrator, educator, employee, student, family, and public interfaces as applicable.
  • Confirm that product-generated documents, reports, email, media, and other output are accessible.
  • Train administrators, content creators, instructors, support staff, and other relevant users.
  • Make accessibility documentation and known workarounds available.
  • Establish an accessible method for reporting barriers.
  • Identify who receives, triages, escalates, and tracks accessibility concerns.
  • Determine how timely access will be provided while barriers are investigated or corrected.
  • Record acceptance results and unresolved risks before launch.

Monitor the product

  • Track unresolved barriers and vendor commitments.
  • Review release notes for changes that may affect accessibility.
  • Retest important workflows after significant updates.
  • Review accessibility-related complaints, support requests, and recurring workarounds.
  • Request updated ACRs and documentation after significant product changes.
  • Verify completed remediation rather than relying only on vendor confirmation.
  • Confirm that local staff continue creating accessible content within the product.
  • Review third-party integrations and embedded content after changes.
  • Include accessibility status in regular product-owner and vendor meetings.
  • Retain evidence needed for renewal decisions.

Work collaboratively with vendors

Product accessibility is strengthened by clear responsibilities, accurate information, and consistent communication.

Establish:

  • A purchaser accessibility contact.
  • A vendor accessibility contact.
  • A shared issue and decision record.
  • A process for reporting newly identified barriers.
  • A cadence for reviewing remediation progress.
  • Clear expectations for known limitations and workarounds.
  • Advance communication about product changes.
  • Documentation that can continue through staffing or organizational changes.

Collaboration supports progress, but it does not replace contractual accountability, accessibility testing, or the public entity’s access responsibilities.

Implementation resources

Renew, replace, or retire the product

Accessibility should be reassessed before renewal, significant expansion, migration, or retirement. Do not assume that the original review still represents the current product.

Before renewal

  • Request a current ACR and updated known-issues information.
  • Review unresolved barriers and remediation commitments.
  • Determine whether promised fixes were completed and verified.
  • Review accessibility-related complaints, support requests, and workarounds.
  • Retest important user tasks.
  • Review significant product, platform, integration, configuration, or ownership changes.
  • Determine whether accessibility documentation and support remain current.
  • Evaluate whether the vendor has communicated transparently and responded effectively.
  • Compare the product with available alternatives.
  • Determine whether contract changes, corrective actions, or additional conditions are needed.
  • Document the decision and next review date.

Possible renewal outcomes

  • Renew.
  • Renew with documented accessibility conditions.
  • Continue temporarily while a replacement is implemented.
  • Require additional evidence or testing before deciding.
  • Replace.
  • Retire.

When replacing or retiring a product

  • Evaluate the replacement before committing to it.
  • Plan an accessible migration.
  • Confirm that data exports, reports, archives, and transition materials are accessible.
  • Communicate changes in accessible formats.
  • Preserve important accessibility records.
  • Confirm that users do not lose necessary access during the transition.
  • Remove outdated public links, instructions, integrations, and documentation.
  • Identify who will monitor the replacement after launch.

Renewal resource

NCDIT Accessibility Checklist for Procurement and Contract Managers

Templates and working tools

This section is currently under construction

Optional external tools and examples

The following resources may help organizations collect vendor information, consider a vendor’s broader accessibility practices, or structure ongoing vendor management.

They are optional examples and external resources; not NCDPI-required processes, product certifications, legal determinations, or substitutes for reviewing the accessibility of the specific product, version, components, and intended use.

Organizations should review each resource’s scope, terminology, licensing, and organizational assumptions before adopting or adapting it.

Inclusion of an external tool or framework does not constitute NCDPI endorsement, certification, approval of a vendor or product, or adoption of the resource as a required procurement process.

  • Example supplier-information questionnaire: University of Michigan Supplier Accessibility Questionnaire 2025: A structured supplier questionnaire based partly on HECVAT questions. It contains University of Michigan–specific legal and policy language, so PSUs or NCDPI should adapt that introductory language before using it.
  • Education-technology vendor maturity resource: 1EdTech TrustEd Apps Accessibility Rubric: An education-technology supplier self-assessment and maturity model covering documentation, procurement communication, accessibility and conformance, and alternatives and accommodations. Public guidance and the rubric specification are available, but detailed completed supplier assessments generally require 1EdTech membership.
  • Organization-wide vendor accessibility maturity worksheet: Minnesota Policy-Driven Adoption for Accessibility worksheet: A vendor-level maturity worksheet examining the organization’s internal support for accessibility. It evaluates broader company practices rather than the accessibility of one specific product. The accompanying Minnesota accessible IT procurement page provides instructions and context for using it. 
  • Knowbility: Vendor in Good Standing Framework: The Vendor in Good Standing, or VIGS, Framework is a customizable vendor-management approach intended to connect regulatory expectations with operational implementation. It addresses four technical areas:
    • Privacy and security.
    • Architecture.
    • Artificial intelligence.
    • Digital accessibility.
  • The framework emphasizes clear expectations, collection of meaningful vendor data, ongoing communication, development roadmaps, and continuous improvement rather than comparing vendors only against one another. VIGS may be useful to organizations seeking a broader, ongoing vendor-governance model rather than a one-time accessibility review. It does not replace an ACR, evaluation of the specific product, testing of critical user tasks, or the organization’s procurement and legal-review processes. 

Information for vendors

Vendors should be prepared to provide accurate, current, product-specific accessibility information and to demonstrate how accessibility is incorporated throughout the product lifecycle.

NCDPI and public school unit reviewers may request:

  • A current product-specific ACR.
  • Product, version, component, and platform information.
  • A description of evaluation methods.
  • The assistive technologies and manual methods used during testing.
  • Known accessibility barriers and affected workflows.
  • A remediation roadmap.
  • An accessibility contact and escalation process.
  • Product-specific demonstrations.
  • Information about accessible design, development, quality assurance, and release practices.
  • Information about testing by people with disabilities.
  • Accessible documentation, training, and support.
  • Samples of accessible content created by authoring tools.
  • Updated accessibility evidence following significant product changes.
  • Cooperation in investigating and correcting reported barriers.

Vendors should not describe the existence of an ACR as proof that a product is fully accessible. Transparency about known barriers, testing methods, and improvement plans provides purchasers with more useful information than unsupported claims of complete compliance.

Vendor resources

Legal review: fundamental alteration and undue financial and administrative burdens

Determinations involving a fundamental alteration or undue financial and administrative burdens require individualized analysis and appropriate legal and administrative review.

These determinations are not routine procurement exceptions and should not be made or communicated by a vendor, content creator, project team, accessibility reviewer, or procurement employee acting alone.

Consult the appropriate:

  • Organizational leadership.
  • Legal counsel.
  • ADA or Section 504 coordinator.
  • Procurement and contract staff.
  • Program owner.
  • Accessibility specialist.
  • Finance or budget staff when applicable.
  • Other officials responsible for the affected service, program, or activity.

Under ADA Title II:

  • The public entity has the burden of demonstrating that the required action would result in a fundamental alteration or undue financial and administrative burdens.
  • The decision must be made by the head of the public entity or an appropriate designee.
  • All resources available for the funding and operation of the affected service, program, or activity must be considered.
  • The decision must be accompanied by a written statement explaining the reasons.
  • The public entity must still take other actions that provide access to the maximum extent possible.

Staff should not use a checklist, template, vendor statement, or website resource as a substitute for the required individualized review and decision process.

Legal resources

Need help?

Questions about incorporating digital accessibility into project planning, procurement, vendor-documentation review, demonstrations, testing, implementation, or renewal may be directed to the NCDPI Digital Accessibility Coordinator.

Contact Josh Barton, NCDPI Digital Accessibility Coordinator.

Questions involving procurement authority, solicitation requirements, contract language, exceptions, or legal interpretation should also be directed through the organization’s established procurement, administrative, and legal-review processes.