Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-24858

XClass properties cannot declare an autocomplete purpose for the fields they generate

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Minor
    • None
    • 17.10.13
    • XClass
    • Unknown

    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-18002 could eventually be dropped.

      Attachments

        Activity

          People

            Unassigned Unassigned
            Lucas C Charpentier Lucas
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: