Description
A field generated from an XClass property has no way to declare its autocomplete purpose, so any form built with XWiki - App Within Minutes applications, class-based edit forms, custom sheets - produces inputs without an autocomplete attribute. Browsers and password managers cannot identify what the field collects and do not offer the value they could have stored for the user.
This means content created with XWiki cannot satisfy WCAG 2.1 success criterion 1.3.5 "Identify Input Purpose" (level AA, EN 301 549 9.1.3.5) whenever it collects information about the user, and the authoring tool therefore does not enable the production of conforming content in the sense of EN 301 549 11.8.2.
Current situation
Every correct autocomplete attribute in XWiki today is written by hand for one specific form:
- as a literal attribute in the login template,
- as a params entry consumed by generateHtml in register_macros.vm for the registration and password forms,
- as a client-side jQuery patch keyed on the field name in the user profile sheet (
XWIKI-18002).
com.xpn.xwiki.objects.classes.PropertyClass and its subclasses contain no reference to the attribute at all, so nothing is available to an application author.
Expected behaviour
A property should be able to declare its input purpose, and the generated field should carry it as an autocomplete attribute. StringClass.displayEdit already sets accessibility attributes on the input it builds - it adds an aria-label fallback - so this would follow an established pattern.
Property types that already imply their purpose should default to it rather than requiring a choice: EmailClass to email and PasswordClass to current-password or new-password. StringClass and TextAreaClass need the author to select one, with an unset default so that nothing changes for existing properties.
Benefit
- The three hand-written mechanisms above could converge on one, and the JS patch of
XWIKI-18002could eventually be dropped.