Summary
- ICANN published the final Universal Acceptance Expert Working Group guidelines on 9 September 2026. They advise ICANN’s future work; they are not a deployed dashboard or a binding compliance regime.
- The guidelines combine indicators measured directly by ICANN, data collected with partners, stakeholder self-reporting and end-to-end assessment of real user journeys.
- The future reporting system should label those evidence classes separately. A self-report can be useful without being treated as an independently reproduced result.
Imagine a government marks its public services “UA-ready” in a standard template. Beside it, a testing team records whether a user with an internationalized email address could register, sign in, receive a message and recover an account. If a consolidated dashboard turns both into the same green square, the interface has made an evidentiary decision that neither source made.
That is the governance problem inside ICANN’s newly published Guidelines for Advancing Universal Acceptance Adoption. The final document asks for a framework that can measure awareness, policy support, implementation and capacity development. It encourages self-reporting, proposes self-assessment templates and imagines incentives to improve participation. It also names end-to-end success through an application as a key cross-cutting indicator.
All of those inputs can be valuable. They do not become interchangeable merely because they occupy neighbouring columns.
Four domains are not one ladder
The guidelines’ four-part structure is useful precisely because activity and operating results occur at different distances from the user.
An awareness event shows that a conversation occurred. A procurement clause shows that an institution has stated a requirement. A training count records exposure to technical material. A successful account-recovery journey shows that a particular service, configuration, identifier and time produced an outcome. None of those observations is automatically false or trivial. Nor does one prove the next.
The final text acknowledges this separation. It asks that indicators make clear what is measured, how the measure contributes to support, and who will measure and report it. It lists implementation signals ranging from registrations and MX-derived observations to data held by platforms. It then identifies a multilingual user’s end-to-end journey through an application as a cross-sector measure.
The danger arrives after collection. A dashboard optimised for one headline trend may normalize unlike objects: event counts with service rates, published policy with executed behavior, available testing tools with completed tests. The visual aggregate can imply a maturity ladder even when the underlying rows describe different predicates.
Self-reporting solves one scarcity and creates another
Guideline 47 asks ICANN to work with intergovernmental organizations to encourage member-state self-reporting. It proposes templates aligned with common and stakeholder-specific indicators and incentives that improve data availability. This is a practical response to a global measurement problem. ICANN cannot directly inspect every government portal, registrar interface, mail service, open-source package and private application in every relevant script.
Self-reporting can reveal projects that an outside crawler would miss. It can identify the responsible team, a remediation programme or a service that requires authenticated access. It can also expose local context that a global test corpus handles poorly.
But a declaration remains evidence produced by the party describing itself. The relevant limitation is provenance, not presumed dishonesty. Teams may use different definitions, test only a front-end field, report a favourable product version, omit an unsuccessful path or carry an old result through a software change. Even a careful respondent can answer a broader question than its evidence supports.
The official Public Comment summary records this concern. Contributors proposed independent validation alongside voluntary self-assessment and warned that incentives can make self-reported data optimistic. Others asked for a published methodology, initial baseline and regular reporting calendar. The checked final PDF does not expressly require independent validation, a methodology or a reporting calendar. That is a bounded observation about the document, not evidence that ICANN has rejected those controls or will omit them from implementation.
Direct measurement also needs a boundary
The same discipline applies to measurements made by ICANN or a contracted tester. Independence is not magic. A test can use a narrow corpus, miss an authenticated workflow, observe a temporary condition or become stale after a library update. A DNS or MX observation may say something about infrastructure without proving that a user can complete registration, authentication and recovery.
ICANN’s existing UA resources already show how concrete testing becomes. Its registry and registrar roadmap maps gates across interfaces, protocols, processing, storage, reports and mail behavior. It calls for unit and system tests, multiple scripts, normalized and unnormalized inputs, specific protocol fields and the delivery behavior needed for EAI. ICANN’s evaluation catalogue points to platform studies and reusable tools.
Those materials do not create a universal test for every stakeholder named in the 2026 guidelines. They do show that “tested” can carry inspectable detail: what system, what gate, what input, what expected result and what limitation.
Publication starts the implementation question
ICANN announced the final document on 9 September; the PDF is dated 20 August. It follows the February–April Public Comment process and the working group’s review of submissions. The announcement says ICANN will use the guidelines to inform future UA work, share plans and collaborate with the community.
The status remains deliberately advisory. The document says ICANN will assess the guidelines and determine how to pursue them as appropriate and practicable. It does not announce a live dashboard, a completed baseline, a certification programme or a decision that every recommendation will be implemented.
That makes the present moment useful. Evidence classes are cheapest to preserve before a data model and public display harden. Retrofitting provenance after years of aggregated scores is possible, but the original test objects, denominators and versions may no longer be recoverable.
Sources
- https://www.icann.org/en/announcements/details/icann-publishes-universal-acceptance-expert-working-group-guidelines-09-09-2026-en
- https://www.icann.org/en/system/files/files/guidelines-advancing-ua-adoption-20aug26-en.pdf
- https://www.icann.org/en/public-comment/proceeding/draft-guidelines-for-advancing-ua-adoption-23-02-2026
- https://itp.cdn.icann.org/en/files/ua-ewg/guidelines-for-advancing-universal-acceptance-adoption-public-comment-23-02-2026-en.pdf
- https://itp.cdn.icann.org/en/files/ua-ewg/summary-report-draft-guidelines-advancing-ua-adoption-12-05-2026-en.pdf
- https://www.icann.org/en/system/files/files/ua-ewg-18aug25-en.pdf
- https://www.icann.org/ua-evaluations-en
- https://www.icann.org/en/system/files/files/universal-acceptance-roadmap-registry-registrar-systems-31aug22-en.pdf
- https://heng.lu/the-policy-mirror/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

