Autocomplete-attributes for Login and registration form

1 Initial Problem

The BITV Testcase 1.3.5a fails. 

Please consult the materna report, p. 53 -55, fig. 27-29.

2 Conceptual Summary

Users are required to enter their User Name at the login screen and adjecent screens.

Autocomplete attributes talk to browsers and convey the purpose of a field this unburdens the browser from making educated guesses.

These autocomplete attributes are only to be used if I myself fill in the following field at the following locations. This must not be used i.e. in the user administration. 

1. The Login Screen needs autocomplete-attributes for the username
2. The registration form should have autocomplete-attributes for username, given-name , family-name, email.
3. Password Assitance Form needs autocomplete-attributes for the username and email but NOT for the Password itself.
4. Form for those who forgot their username need and automplete-attribute email.

Please consult the list of autocomplete-attributes is here https://www.w3.org/TR/WCAG22/#input-purposes

3 User Interface Modifications

3.1 List of Affected Views

• Login Screen 
• registration form 
• Password Assitance Form
• Forgot Password Form 

3.2 User Interface Details

No visible change

3.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: {Please add your name.}
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.