Turn obligations into inspectable evidence

Two major U.S. government accessibility timelines changed in 2026. The Department of Justice extended the ADA Title II web and mobile application compliance dates for state and local governments, and the Department of Health and Human Services extended parallel Section 504 dates for recipients of HHS financial assistance. The extensions are operationally important, but they are not a reason to stop accessibility work. Both rule sets continue to point covered organizations toward WCAG 2.1 Level AA, and both agencies continue to describe web and mobile accessibility as part of broader nondiscrimination obligations.

For technology leaders, procurement teams, web owners, and vendors, the practical task is to use the extra year to move from broad intent to an evidence-backed program: identify which rule applies, inventory the digital services in scope, classify exceptions carefully, test high-value user journeys, fix procurement language, and preserve evidence that accessibility is being designed and validated throughout the lifecycle. this analysis is an operational summary, not legal advice; organizations should confirm applicability and interpretations with counsel or their responsible compliance authority.

The 2026 extensions created two different timelines

The Department of Justice issued an interim final rule effective April 20, 2026 extending the ADA Title II web and mobile accessibility compliance dates adopted in 2024. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Public entities with fewer than 50,000 people, and special district governments, now have until April 26, 2028. DOJ's updated fact sheet and planning guidance reflect those revised dates.

HHS issued a separate interim final rule effective May 7, 2026 for recipients of HHS financial assistance covered by the Department's Section 504 rule. Recipients with 15 or more employees now have until May 11, 2027 to meet the web and mobile accessibility requirements. Recipients with fewer than 15 employees now have until May 10, 2028. HHS described the change as a one-year extension and said the technical standard remains WCAG 2.1 Level AA.

Those dates are easy to blur together because the rules address similar accessibility outcomes. They should not be treated as interchangeable. ADA Title II status depends on the nature and population of the public entity. HHS Section 504 status depends on receipt of HHS financial assistance and the employee threshold used in that rule. Some organizations may be affected by both regimes, while others may fall under only one. The first project-management step is therefore a documented applicability map rather than a generic deadline entered into a calendar.

The extension is schedule relief, not a reset of accessibility obligations

DOJ's Title II resources emphasize that state and local governments already have obligations to provide accessible services, programs, and activities. The 2024 web rule adds specific technical requirements for web content and mobile applications, but the one-year extension does not convert accessibility into an optional future project. DOJ's planning guidance still tells public entities to identify responsible people, learn the rule, determine the compliance date, inventory web content and mobile apps, assess current accessibility, prioritize remediation, examine vendor contracts, and create policies.

HHS makes a similar distinction. Its 2026 announcement says the extension does not impose new obligations and gives recipients additional time to meet the specific technical standard. HHS also reminds recipients of continuing legal obligations to ensure programs and activities are accessible to people with disabilities. That matters for operational planning: a team should not interpret a 2027 or 2028 technical-conformance date as permission to leave a known barrier in a critical service untouched for another year.

A defensible roadmap separates immediate access problems from the full conformance program. High-consequence user journeys such as applying for benefits, accessing health information, submitting public forms, paying fees, requesting records, scheduling services, reviewing notices, or using authentication should receive priority based on user impact and service criticality. Lower-risk legacy content can then be handled through a documented inventory and remediation schedule, including evaluation of any rule-specific exceptions.

WCAG 2.1 Level AA is the common technical center of gravity

Both the DOJ Title II rule and the HHS Section 504 web and mobile provisions use WCAG 2.1 Level AA as the core technical standard. WCAG 2.1 includes testable criteria covering keyboard access, reflow, text spacing, non-text contrast, status messages, form semantics, orientation, input purpose, pointer interactions, and other accessibility needs. A program that treats accessibility as color contrast plus image alt text will miss a large portion of the actual interface and workflow risk.

Public-sector teams should also distinguish the legally referenced standard from newer design targets. WCAG 2.2 is available and may be valuable as an additional engineering target, but a procurement document should not casually substitute one standard for another without explaining the intended requirement. The strongest approach states the controlling legal or contractual baseline, any additional accessibility objective, the product and content scope, and the acceptance method.

This precision matters when buying software. A vendor may provide an Accessibility Conformance Report based on a particular VPAT edition, WCAG version, product release, or configuration. Buyers should compare the report to the rule and the actual deployed system rather than assuming that the word accessible is a complete answer. Zeph Tech's accessibility procurement checklist is designed to help teams request comparable evidence before award.

Inventory the service, not just the public website

DOJ's Title II rule reaches web content and mobile apps a public entity provides or makes available directly or through contractual, licensing, or other arrangements. HHS similarly addresses web content and mobile applications provided or made available by covered recipients. That means an accessibility inventory should include more than the main public website. Teams should look for SaaS portals, embedded payment services, appointment systems, document viewers, online forms, authentication flows, public records tools, kiosks where relevant, mobile applications, and third-party components that are part of the user journey.

The inventory should identify ownership and control. Record the service owner, vendor, contract, product version, authentication method, content owner, critical workflows, known accessibility evidence, current defects, and renewal or replacement date. This converts accessibility from a vague web-team responsibility into a governed technology portfolio. It also exposes procurement use: a system renewing six months before the compliance date deserves a different plan than one entering a five-year term now.

For document-heavy services, classify the document problem separately from application accessibility. PDFs, spreadsheets, presentations, word-processing documents, scanned images, and generated reports can create barriers even when the surrounding portal is accessible. Both DOJ and HHS rules include carefully bounded exceptions for certain content, but exceptions should be evaluated against the actual rule text and service context rather than used as a blanket reason to ignore archives or preexisting documents.

Turn the extra year into contract use

One of the highest-value uses of the extension is procurement cleanup. Every new solicitation, renewal, amendment, or major implementation creates an opportunity to require clearer accessibility evidence. Ask vendors for the current Accessibility Conformance Report for the exact product and version proposed, the test methods used, known defects affecting material workflows, remediation commitments, the accessibility product owner, and the event that triggers a new report or retest.

Acceptance language should define what happens when an accessibility defect is found. Identify which severity levels block release, who validates remediation, how retesting is documented, whether accessibility defects affect service-level or quality obligations, and how major interface changes are reviewed. For configurable systems, divide responsibility among the platform vendor, implementation partner, content authors, and agency. Accessible components can still produce inaccessible configured workflows, and accessible source content can still be rendered poorly by a product.

Public portal procurement deserves special attention because the public experience often combines search, filters, tables, forms, downloads, account functions, and records. Teams evaluating a portal should test representative workflows with keyboard-only navigation and appropriate assistive technology instead of accepting a home-page scan. The public-sector software RFP checklist and software evaluation scorecard can be used alongside accessibility evidence so the requirement affects the actual selection decision.

Build a 2026-to-2028 evidence trail

A good accessibility program should be able to show how it moved from discovery to measurable improvement. Start with a dated inventory and applicability decision. Preserve baseline testing results for critical workflows. Create remediation tickets tied to specific success criteria or user barriers. Record product versions and test environments. Keep vendor ACRs and clarification responses. Capture acceptance decisions and any documented exceptions or limitations. Repeat material tests after major releases rather than treating accessibility as a one-time certification exercise.

For large state and local governments and larger HHS-funded recipients, the revised 2027 dates make 2026 the year to establish the operating model. For smaller entities and special districts with 2028 dates, the longer runway should enable phased remediation instead of deferral. Early inventory also improves budgeting because it reveals whether the largest cost is content remediation, vendor replacement, application development, document conversion, testing capacity, or governance.

Organizations should also monitor the agencies' official rule pages for further changes. A static project plan is risky when regulatory materials can be amended, clarified, or supplemented. The safest practice is to store the authoritative source URL next to each compliance milestone and assign someone to re-verify it before major procurement, release, or audit decisions.

Questions to take into the next accessibility review

• Which entities, programs, websites, mobile apps, and vendor-operated services are in scope for us?
• Are we tracking the correct 2027 or 2028 deadline for each applicable rule?
• Which critical public or patient workflows have been manually tested, not merely scanned?
• Do current contracts require product-specific accessibility evidence and dated remediation commitments?
• Which documents or archived materials are being treated as exceptions, and is that classification defensible?
• What product, interface, or content change triggers retesting?
• Can leadership see a dated evidence trail from baseline findings through remediation and acceptance?

The 2026 extensions create breathing room, but the most valuable outcome is not a later deadline. It is the opportunity to replace reactive remediation with a repeatable accessibility operating model. Teams that use the additional year to improve inventory, procurement, testing, ownership, and evidence will be in a stronger position for compliance and will also deliver digital services that work better for the people who depend on them.

Updated September 2, 2026: FedRAMP 20x is no longer only a pilot or near-term transition. FedRAMP opened the Class A pipeline on August 3 and announced August 31 openings for the Class B and Class C pipelines. The FedRAMP homepage now reports 30 FedRAMP 20x certified services. For public-sector buyers, that makes the question more specific than simply asking whether a vendor is ‘FedRAMP compliant.’ Buyers should identify the exact certification class, confirm the marketplace record and service boundary, understand what evidence remains reusable, and document the agency-specific risk decision that still belongs to the agency.

What changed between the pilots and September 2026

FedRAMP describes Phase 3 of 20x as wide-scale adoption. Phase 2 tested the model at the Moderate impact level and concluded in March 2026. FedRAMP’s published lessons emphasized that automated validation and Key Security Indicators could scale, while also identifying the need for clearer assessor guidance, consistent machine-readable schemas, concise evidence context, explicit failure criteria, and assessor feedback close to the provider’s own validation evidence.

The Consolidated Rules for 2026 now provide a common rule structure for agencies, cloud service providers, assessors, and FedRAMP. FedRAMP’s July 30 certification-path update stated that Class A opened August 3 and that Class B and Class C would open August 31. Class B is the updated path associated with the previous Low level, while Class C replaces the Moderate impact path. FedRAMP also says it plans to pilot Class D, aligned with High, later in 2026 before broader availability in 2027.

That shift matters to acquisition language. A solicitation should no longer use ‘FedRAMP’ as a vague checkbox. It should state the expected certification class or acceptable transition state, the federal information and functions in scope, the service boundary, the evidence the agency expects to inspect, and any agency-specific controls or conditions that remain outside reusable FedRAMP certification evidence. Teams should verify current dates and statuses against FedRAMP’s live program pages rather than recycling acquisition language written before the 20x class model became operational.

The marketplace record is useful, but it is not the whole decision

FedRAMP’s marketplace is more important as a common discovery and status surface. It is where buyers can confirm the listed cloud service, certification class, authorizing relationships, and other program data. FedRAMP’s current homepage reports hundreds of certified cloud services overall and 30 services certified through 20x, which is evidence that the new path is moving beyond a small pilot cohort.

Marketplace data also became more operationally useful in late August. FedRAMP published a requirement, effective August 26, for providers to include general service pricing information or a link to public pricing information in marketplace data. For buyers, that creates an additional cross-check between a provider’s federal listing, its general commercial pricing context, and the actual proposal presented to the agency. It does not make procurement price analysis automatic, but it creates another public datum that should be reconciled rather than ignored.

The same FedRAMP marketplace rule set says providers must not simultaneously request both a Rev5 Program Certification and a 20x Validation for the same cloud service offering. That matters during vendor diligence because transition language can otherwise become ambiguous. Ask which path the provider is actually pursuing, what milestone has been reached, and which evidence package applies to the service being evaluated. A roadmap statement is not the same thing as a current certification state.

The certification package is becoming a living evidence set

FedRAMP’s 20x package guidance treats the certification package as maintained certification data rather than one static folder downloaded at award. Providers may expose information through trust centers, documentation portals, downloadable files, APIs, or a combination of methods. The buyer-side requirement is to understand which evidence is authoritative, how it is updated, how access is governed, and how the agency preserves the evidence it relied upon when the provider’s live portal later changes.

That should change the questions asked in demonstrations. Instead of asking whether the vendor ‘has the package,’ ask which portions are continuously maintained, which evidence is machine-readable, how changes are versioned, how agency reviewers receive updates, and what happens when evidence access is interrupted. Ask who owns the post-award evidence channel on both sides. A clean pre-award demonstration is not enough if operational staff cannot reliably retrieve the same evidence after contract signature.

A polished trust center can make evidence easier to consume, but presentation quality is not equivalent to security quality. Buyers should distinguish provider assertions, independent assessment results, continuously generated validation outputs, architecture descriptions, and agency-specific statements. The procurement file should capture enough of the relied-upon evidence to explain why the agency made its decision on that date.

Security Decision Records make traceability more important

The Consolidated Rules describe a Security Decision Record as a persistently maintained, verified, and validated record of security decisions over the lifecycle of the cloud service offering. The practical implication is not that traditional documentation disappears. It is that claims should connect more directly to decisions, implemented behavior, validation, and change.

During evaluation, ask how the provider records material security decisions and how those decisions connect to identity, network, data, logging, vulnerability, and administrative controls. Look for traceability between the declared service boundary, the decision record, automated validation, independent assessment, vulnerability information, and significant-change notifications. A control statement is more useful when reviewers can see how it is tested and what happens when the test fails.

Agencies should maintain their own decision record as well. FedRAMP certification is reusable evidence; it is not a substitute for deciding whether the service is appropriate for the agency’s intended use. Record the use case, data categories, impact assumptions, integrations, privileged paths, exceptions, compensating measures, accepted residual risk, reviewers, and conditions that force the agency to revisit the decision.

Persistent validation belongs in the vendor evaluation

FedRAMP’s 20x direction emphasizes persistent validation. Phase 2 lessons highlighted timely access, usable interfaces, consistent machine-readable schemas, concise context, clear failure criteria, assessor feedback beside provider validation, and review of validation code. Those details are procurement-relevant because they determine whether an agency can understand security posture after selection rather than only during an authorization event.

Ask vendors to demonstrate a small number of concrete validation paths. Identity configuration, vulnerability handling, boundary enforcement, and logging are useful examples. Ask what is tested, how frequently, what evidence the test creates, who reviews failures, which failures block release or trigger escalation, and which portions were independently assessed. The goal is not to prescribe one security tool. It is to establish that the provider can turn security expectations into repeatable evidence.

Machine-readable evidence may also support agency portfolio oversight. An agency operating many cloud services may want to ingest status data, certification metadata, vulnerability information, or change notifications into GRC, vulnerability, incident, or architecture workflows. Contract teams should identify those interface and access needs early so a PDF-only process does not become an avoidable bottleneck later.

Vulnerability, change, and exit evidence deserve contract language

The 2026 rules include updated expectations for vulnerability detection and significant changes. Buyers should translate those program requirements into service-management interfaces: where notifications arrive, which events require action, what fields are included, what severity or timing information is available, and how the agency can subscribe through an inbox, portal, API, or ticket integration.

Do not accept the phrase ‘continuous monitoring’ without identifying the receiver and escalation path. The agency needs to know which team receives provider information, how it enters incident and vulnerability workflows, how exceptions are tracked, and how material changes reach architecture or authorization reviewers. Contract language should assign ownership on both sides.

Exit and continuity belong in the same evidence discussion. Ask how the agency obtains records, logs, configuration information, audit history, and agency data at termination; how long security evidence remains available after the relationship ends; and how access changes during transition. Initial certification quality does not eliminate operational risk if the agency cannot preserve the information needed for investigations, records obligations, migration, or handoff.

A stronger public-sector evidence request

For a material cloud procurement, request the exact FedRAMP marketplace listing or certification path, current class and status, declared service boundary, evidence-sharing method, and independent assessment information appropriate to the offering. Then request the architecture view, identity and administrative model, data flows, encryption approach, audit and logging capabilities, vulnerability process, incident-notification process, significant-change process, and post-award evidence-access model.

Ask for examples that show how the process works, not only policy statements: a redacted validation result, sample significant-change notice, sample vulnerability status record, audit event, failure criterion, or explanation of how a Security Decision Record changes after an architectural change. The objective is not to recreate FedRAMP’s assessment. It is to obtain enough relevant proof to support the agency’s own purchasing and authorization decision.

Zeph Tech’s Vendor Security Questionnaire can structure the security evidence request, while the Software Evaluation Scorecard helps preserve comparable evidence across competing offerings. For larger acquisitions, the Public-Sector Technology Procurement Toolkit carries the same decision into requirements, accessibility, migration, continuity, and exit planning.

Questions for the next procurement or architecture review

• Which FedRAMP certification class and current marketplace status apply to this exact cloud service offering?
• Is the provider pursuing 20x or Rev5 for this offering, and what transition assumptions are embedded in the proposal?
• Can reviewers access current certification evidence before award, and will that access continue after award?
• Which security assertions are persistently validated, and what happens when validation fails?
• How will vulnerability, incident, and significant-change information enter the agency’s own workflows?
• Can the agency preserve the evidence it relied on when live provider documentation changes?
• What agency-specific controls, integrations, or risk decisions remain outside reusable FedRAMP evidence?
• What change in scope, data, architecture, ownership, or certification state forces a new agency review?

FedRAMP 20x can make federal cloud security evidence more current and more reusable, but it does not remove disciplined buying. The strongest procurement process uses FedRAMP as one authoritative evidence layer, defines the agency decision that evidence must support, preserves a traceable record of the decision, and establishes how risk information will keep flowing after award.

Updated September 2, 2026: Accessibility belongs in software procurement before the demo, not in remediation after go-live. For U.S. federal agencies, Section 508 requires information and communication technology that agencies procure, develop, maintain, or use to conform to the Revised 508 Standards unless an applicable exception is documented. GSA’s current Section508.gov guidance continues to frame accessibility as an acquisition-lifecycle responsibility spanning requirements, market research, solicitation language, vendor evidence, evaluation, acceptance, and post-award validation. Buyers should treat an Accessibility Conformance Report as evidence to examine—not a checkbox that ends the review.

Start with the legal baseline, then define the product standard you actually need

Federal acquisition teams should distinguish the Revised 508 Standards from newer web accessibility guidance. Section508.gov’s materials describe the Revised 508 technical requirements as aligned with WCAG 2.0 Level A and Level AA. WCAG 2.2 is a newer W3C Recommendation and adds success criteria including Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, and Accessible Authentication. W3C recommends using the latest WCAG version where possible, but that does not mean a buyer should rewrite the federal legal baseline as if Section 508 itself simply equals WCAG 2.2.

A strong solicitation separates mandatory requirements from additional accessibility goals. Identify which Revised 508 provisions apply to each ICT component, document any legitimate exception analysis, and then state any additional contract requirements the agency wants the solution to satisfy. If WCAG 2.2 AA is a contractual or design objective beyond the incorporated federal baseline, say so explicitly and define how it will be tested. Clear requirements reduce disputes later about whether a vendor promised legal conformance, broader best-practice conformance, or both.

This distinction also improves market research. Vendors may publish ACRs based on different VPAT editions and different technical standards. Compare the report’s stated standard, product version, module, and evaluation date to the actual solicitation. An impressive accessibility landing page does not prove that the specific version, configured implementation, mobile experience, authoring workflow, or integration being purchased meets the agency’s requirements.

Request an ACR, but evaluate what is inside it

Section508.gov advises federal buyers to request accessibility information from vendors and contractors. For standard commercial or government off-the-shelf ICT, an ACR provides a structured way to describe conformance. Buyers should read the product name, version, report date, scope, evaluation methods, applicable standards, and remarks before treating the conformance labels as meaningful.

Pay particular attention to Partially Supports, Does Not Support, Not Applicable, and similar entries. The remarks should identify the affected function, the condition under which the barrier appears, and any workaround or remediation path. A report containing uniformly positive conclusions but little test detail deserves more scrutiny, not less. The buyer should be able to tell what was actually evaluated.

Freshness matters because software changes continuously. Ask what product build the report covers, whether material interface changes occurred after the report, and what event triggers an updated ACR. For SaaS, accessibility evidence maintenance belongs in the ongoing contract relationship. A report for a materially different interface is historical evidence, not proof of the current service.

Use the newer ACR supplement to ask better defect questions

Section508.gov’s Government ACR Supplement, reviewed in August 2026, gives buyers a more operational model for accessibility gaps. It asks for the affected product area or workflow, impacted user group, workaround, and related defect context instead of relying only on a conformance label. That is a useful procurement pattern even when the exact supplement is not contractually required.

When a vendor discloses a gap, ask four questions: what user task is affected, which users experience the barrier, whether a realistic workaround exists, and when the product team expects to remediate and retest the problem. A defect such as unlabeled form fields, an inaccessible address workflow, or a keyboard trap should be described in terms of functional impact rather than buried in generic remarks.

This also helps buyers compare risk across vendors. One product may have more disclosed defects but better evidence, clearer ownership, and dated remediation. Another may report near-perfect conformance with little test detail. Procurement scoring should reward evidence quality and realistic remediation governance rather than incentivizing vendors to disclose less.

Test the workflow, not only isolated pages

Accessibility problems often appear at the boundaries between components: authentication, modal dialogs, file upload, document preview, tables, charts, date pickers, search filters, notification banners, generated PDFs, rich-text editors, or third-party integrations. A procurement evaluation should therefore use representative end-to-end workflows rather than checking only a landing page.

Choose tasks that matter to actual users. For a records system, that may include signing in, finding a record, filtering a table, opening an attachment, editing metadata, completing a form, receiving validation feedback, exporting a report, and signing out. For a public portal, include search, pagination, document access, form submission, status messages, and mobile use. For an internal workflow application, include keyboard-only operation and assistive-technology interaction with the highest-volume and highest-consequence tasks.

Automated scanning is useful but cannot establish full conformance. Combine it with keyboard review and appropriate manual or assistive-technology testing. Document the test environment, browser, platform, assistive technology where used, product build, test steps, expected result, actual result, severity, and disposition. The evidence should be reproducible enough that agency and vendor reviewers are discussing the same defect.

Use accessibility as an acceptance criterion, not only a pre-award promise

Section508.gov frames procurement as a lifecycle that continues after award. Put measurable accessibility acceptance criteria into the statement of work, quality plan, backlog definition of done, or other appropriate contract artifact. Define what must be tested before release, who performs the testing, which evidence the contractor supplies, which severity levels block acceptance, how remediation is tracked, and how retesting occurs.

Configured and custom solutions deserve special attention. A platform can provide accessible components while an agency or implementation partner creates inaccessible forms, documents, labels, reports, or extensions. Conversely, accessible source content can become inaccessible when rendered by the product. The contract should identify ownership for standard components, configured workflows, authored content, integrations, generated documents, training, and final acceptance.

Accessibility should also appear in quality surveillance. If a release materially changes navigation, authentication, core workflows, document output, or a major UI component, define whether that change triggers regression testing or an updated ACR. Treating accessibility as part of normal release governance is more sustainable than reopening a one-time compliance project after users report barriers.

Ask about remediation and product governance before you need them

No mature buyer should assume a complex product will never have an accessibility defect. The procurement question is how the vendor finds, prioritizes, communicates, and fixes defects. Ask for the accessibility intake path, severity model, remediation targets, release process, regression approach, customer-notification practice, and product owner. Ask whether accessibility findings live in the same product-management system as other defects or disappear into an unowned compliance queue.

For known gaps, request a remediation plan identifying the affected function, user impact, workaround, target release, owner, and validation method. Avoid undated commitments. If a gap affects a core task, determine before award whether an alternate means of access is realistic for the user population and operational setting. Section508.gov’s procurement guidance discusses best-meets situations where no technically acceptable commercial alternative fully conforms, but that is a documented acquisition decision—not a blanket waiver of accessibility expectations.

Governance should survive product change. Contract terms can require notice when a release materially changes an accessibility claim, replaces a major component, or causes an ACR to be updated. The agency should have a named accessibility owner or review function that receives those changes and determines whether new testing is required.

WCAG 2.2 strengthens evaluation without changing the legal label

WCAG 2.2 provides useful additional tests for modern interfaces. Focus Not Obscured is relevant to sticky headers and overlays. Dragging Movements matters when essential functions depend on drag-and-drop. Target Size matters for dense interfaces and mobile use. Accessible Authentication matters when login flows introduce cognitive-function tests or other avoidable barriers. These are practical design and procurement signals even when the mandatory Section 508 baseline remains tied to the Revised 508 Standards.

If an agency chooses to require WCAG 2.2 AA contractually, define scope: standard product, configured implementation, public content, internal administration, mobile web, native applications, generated electronic documents, or all of them. Then define testing and acceptance. A sentence that says ‘must be WCAG compliant’ is ambiguous because it omits version, level, product scope, exceptions, and evidence.

For non-federal public-sector buyers, the controlling legal requirements may differ by jurisdiction. The evidence discipline remains useful: identify the applicable rule, define scope, request a conformance statement, test material workflows, document gaps, and place remediation and regression expectations into the operating relationship.

A buyer evidence pack for accessible software

Ask each shortlisted vendor for the current ACR covering the product and version proposed, the methods used to produce it, known accessibility defects affecting material workflows, remediation governance, and the accessibility product contact. For custom development or configuration, request the accessibility test plan, development standards, component or design-system practices, and evidence that accompanies each release.

During evaluation, preserve the ACR version and date, workflow-test notes, demonstrations, defect list, vendor clarifications, remediation commitments, exception decisions, and scoring rationale. Connect those items to the procurement record rather than storing them in an isolated accessibility folder that reviewers never see during award.

Zeph Tech’s Accessibility Procurement Checklist can structure that evidence request. The Software Evaluation Scorecard makes accessibility findings visible alongside security, implementation, support, and exit risk, while the Public-Sector Technology Procurement Toolkit carries the same evidence through a broader acquisition lifecycle.

Questions for the next software evaluation

• Which Revised 508 provisions apply to each ICT component being purchased?
• What exact product version and technical standard does the ACR cover?
• Which material workflows were manually tested, and can the vendor demonstrate them with keyboard and assistive technology?
• For each known gap, what task is affected, which users are impacted, what workaround exists, and what dated remediation commitment is recorded?
• Are we intentionally requiring WCAG 2.2 beyond the federal baseline, and have we defined scope and acceptance?
• Who owns accessibility for custom configuration, third-party components, generated content, documents, and integrations?
• What product change triggers an ACR update or agency retest?
• Will accessibility defects affect acceptance, quality surveillance, and contractor performance after award?

An ACR is valuable because it creates a structured starting point for the conversation. It is not a substitute for requirements, workflow testing, acceptance, or ongoing oversight. The strongest procurement process makes accessibility visible from market research through post-award operations, preserves evidence at each stage, and distinguishes clearly between the legal baseline and any higher design standard the agency chooses to require.

Updated September 2, 2026: The EU AI Act became broadly applicable on 2 August 2026, but the implementation picture is not the one many 2024 compliance plans assumed. Regulation (EU) 2026/1744, the Digital Omnibus on AI, changed the timetable for high-risk systems shortly before the main application date. The result is a split calendar: many governance and transparency duties are active now, some amended prohibited-practice and synthetic-content provisions take effect in December 2026, general-purpose AI obligations have applied since August 2025, and the principal high-risk-system requirements move into 2027 and 2028. Organizations should update control maps to the amended law instead of treating every obligation as either fully live or uniformly delayed.

What is already live in September 2026

The AI Act’s general application date remains 2 August 2026. The consolidated legal text shows Chapters I and II applying from February 2025 subject to newly amended exceptions, Chapter III Section 4 and several other governance and enforcement provisions applying from August 2025, and Articles 102 through 110 applying from 27 July 2026. The practical point is that the Digital Omnibus changed selected dates; it did not suspend the entire AI Act.

Organizations should therefore maintain an inventory that distinguishes legal role, intended purpose, system category, geography, and obligation family. A provider, deployer, importer, distributor, and authorized representative do not inherit the same responsibilities. Those roles depend on facts such as who places the system on the market, whose name or trademark is used, who substantially modifies the system, and how the system is actually deployed.

Transparency work should be treated as an operating control. Teams need to know where people encounter AI, where synthetic or manipulated content is produced or published, who owns disclosures, and how the disclosure is tested across interfaces and channels. A policy document is weak evidence on its own. Stronger evidence connects the inventory record to the product surface, disclosure text, owner, test result, exception rationale, and change trigger.

December 2, 2026 is the next near-term transition date

The Digital Omnibus added a specific transition for providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video, or text content and were placed on the market before 2 August 2026. Those providers must take the necessary steps to comply with Article 50(2) by 2 December 2026. That makes synthetic-content provenance and marking a near-term engineering issue rather than something organizations can postpone until the later high-risk dates.

The amendment also moved selected prohibited-practice provisions added by the Digital Omnibus to 2 December 2026. Teams maintaining policy maps should therefore avoid a single status field that says ‘Article 5 active’ without identifying the paragraph and amendment involved. The safest operating record captures the specific article, applicability date, system facts, control owner, and evidence location.

For product teams, the useful question is whether a December deadline requires an actual technical or release change. If a system generates synthetic content, document the current output-marking mechanism, downstream transformations that could remove or alter it, API behavior, supported formats, customer responsibilities, and testing evidence. Where the organization is a deployer rather than the provider, preserve the provider’s documentation and identify which additional disclosure duties belong to the deployment context.

The Digital Omnibus moved the principal high-risk deadlines

Regulation (EU) 2026/1744 amended Article 113 so that Chapter III Sections 1, 2, and 3—other than the specified Article 6(5) exception—apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I. The law explains that delayed standards, specifications, guidance, and national-authority readiness contributed to the revised timetable.

This is a legal delay, not evidence that preparatory work has no value. A provider waiting until the final quarter before the deadline will still need to confirm classification, establish data-governance controls, produce technical documentation, design logging, define human oversight, validate accuracy and robustness, connect cybersecurity testing to release governance, and establish post-market monitoring. Those activities can depend on procurement, architecture, engineering, and assurance cycles that are much longer than a few months.

The amended timetable makes classification discipline more important. Annex III use cases and Annex I product-related systems now have different principal dates. A single spreadsheet field called ‘high risk’ is therefore inadequate. Record the classification basis, article and annex reference, system role, geography, evidence owner, review date, and the event that would force reclassification.

Public-authority high-risk deployments have an additional transition point

The amended text also states that providers and deployers of high-risk AI systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 in the relevant transition provision. Public-sector teams should not read that outer date as permission to ignore current procurement and architecture decisions. Systems procured now can remain in service for years, and contract terms established in 2026 may determine whether the authority can later obtain documentation, logs, testing evidence, version information, and remediation support.

For public-sector procurement, use the longer horizon to improve contract quality. Request role analysis, intended-purpose documentation, model and version information, data-flow information, human-oversight capabilities, logs, evaluation evidence, incident notification, material-change notice, and exit data. Make the evidence refreshable so the authority is not trying to reconstruct a 2026 procurement record in 2029.

Zeph Tech’s Public-Sector Technology Procurement Toolkit and Vendor Security Questionnaire can be used to preserve those evidence requests alongside the broader acquisition record rather than treating AI compliance as a separate legal attachment.

Earlier obligations still matter

AI-literacy duties and many prohibited-practice rules began applying in February 2025. Governance rules and obligations for providers of general-purpose AI models began applying in August 2025. The Digital Omnibus did not erase those earlier dates. Organizations should preserve evidence of training, prohibited-use controls, model-provider due diligence, escalation procedures, and role-specific governance rather than rebuilding the program only around the revised high-risk timetable.

AI literacy should reflect actual responsibilities. Procurement staff need to recognize product claims and contract gaps. Developers need to understand evaluation, logging, data handling, and misuse boundaries. Frontline deployers need to recognize where AI output cannot simply become a decision. Risk and legal reviewers need enough technical context to challenge intended-purpose and classification statements. Attendance records are useful, but role-specific objectives and practical checks are stronger evidence.

General-purpose AI governance also requires a supply-chain view. Record the model and version, provider terms, data-use settings, hosting route, retrieval sources, tools or actions the model may invoke, output destinations, and the trigger for re-evaluation. A deployer may depend on model-level documentation from a provider while remaining responsible for its own interface, instructions, monitoring, and downstream use.

A practical 30-day control reset

First, reconcile the AI inventory with the amended dates. Replace blanket ‘August 2026’ status labels with the specific obligation family that applies. Confirm whether each system implicates prohibited practices, transparency, general-purpose AI, potential Annex III high-risk use, Annex I product-related use, or none of those categories. Preserve uncertainty where classification is not yet resolved.

Second, inspect public and employee-facing experiences for transparency and synthetic-content handling. Capture test evidence showing disclosures or marking in context. Review generated-content workflows in marketing, support, public information, knowledge bases, document generation, and API-based publication. Assign an owner for changes in model behavior or delivery channel that could invalidate the current control.

Third, review contracts and vendor evidence. Ask for model cards or equivalent documentation, intended and excluded uses, data handling, retention, subprocessors, security controls, incident notification, version-change practices, evaluation evidence, logging support, and technical documentation. A vendor statement that a product is ‘AI Act compliant’ is not a substitute for evidence relevant to the buyer’s role and use case.

Finally, create a dated decision record that identifies the business owner, technical owner, risk owner, legal interpretation source, classification rationale, current controls, open gaps, next review event, and accountable approver. Link the record to evidence rather than duplicating unsupported conclusions across systems.

The evidence pack leadership should ask to see

For a material AI use case, leadership should be able to inspect an inventory record, role analysis, intended-purpose statement, data-flow or architecture view, model and vendor documentation, evaluation plan, test results, transparency evidence, human-oversight design, incident path, monitoring indicators, and a record of accepted residual risk. The pack should distinguish vendor-supplied facts from findings produced by the organization.

Useful metrics include the percentage of systems with a current owner, percentage with a dated classification rationale, evaluation coverage after material changes, unresolved high-severity findings, disclosure test coverage, time to disable or contain a problematic deployment, and incomplete vendor evidence requests. A count of ‘AI projects reviewed’ has little meaning if the review standard is undefined.

The Software Evaluation Scorecard can be used to make these evidence differences visible during a technology decision, while the Evaluation Brief Builder helps turn an AI use case into concrete questions before a vendor conversation.

Decision questions for the next steering meeting

• Which obligations are active for this system today, and what article-level basis supports that conclusion?
• Do any synthetic-content systems need a technical or operational change before 2 December 2026?
• Which systems depend on the 2027 Annex III or 2028 Annex I timetable, and what engineering lead time remains?
• Which public-authority deployments may rely on the later transition provision, and are current contracts preserving the evidence needed before 2030?
• Where are we relying on vendor assurances without documentation relevant to our own legal role?
• Can we trace every material system to an owner, intended purpose, model or version, data boundary, evaluation, and incident path?
• What change—new model, new data, new user group, new action, new geography, or substantial modification—forces reclassification or re-evaluation?

The practical advantage of the revised timetable is the opportunity to replace hurried checkbox work with an evidence-producing operating model. The organizations that use the extension well will arrive at the later high-risk deadlines with tested controls, current supplier evidence, and repeatable review habits. Organizations that read ‘delay’ as ‘do nothing’ will face the same engineering and governance work later with less time and weaker institutional memory.

this analysis is an implementation aid, not legal advice. Validate material decisions against the consolidated EU legal text, current Commission guidance, and qualified counsel for the relevant role and jurisdiction.