Preserve form data across session re-login
G181 has one defining constraint and it is easy to miss. The data is encoded into the re-authentication page as hidden or encrypted data and passed straight back through, and the server never stores it. That is the whole point, because there are situations where holding a user's entered data temporarily is either illegal or a security risk, and this technique gets them through re-login anyway. The other technique for the same rule caches the data on the server instead. W3C lists this as sufficient for 2.2.5 Re-authenticating, a Level AAA rule, and only where it genuinely lets people continue without loss. Verifying it takes knowledge of the implementation rather than observation, since both approaches look identical from the browser. W3C adds a caution worth heeding. Where the data is sensitive, think hard about how it travels to and from the login page.
How we find it in an audit
Our reviewers fill a form, force the session to expire, log back in and check that every answer returned. That establishes the outcome. Establishing which technique produced it means asking the engineering team where the data lived during login, which is the only way to tell these two apart and the reason this check needs a conversation as well as a browser.
How affected users experience it
An insurance claim form is long, and reading it through speech makes it longer. Someone who is thirty minutes in has invested real effort, and losing it to a login screen is not an inconvenience. It is the point at which a person decides to phone instead, or to give up on the claim. Returning them to a full form after re-authenticating costs them nothing but the login.
Passes vs. fails
Passes
On timeout the claim data travels through the re-login flow encrypted, and after authenticating the user returns to a form with all answers intact.
Fails
An insurance claim form logs the user out after 30 minutes, and re-login lands on an empty form with every answer gone.
Other ways to satisfy this rule
3 guides on this site are filed under 2.2.5 Re-authenticating. W3C lists this one as sufficient for that rule when used for providing options to continue without loss of data, so the condition is part of the test rather than a footnote to it.
This guide is our interpretation of W3C technique G181: Encoding user data as hidden or encrypted data in a re-authorization page. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.