Feature Wiki
Tabs
Autocomplete-attributes for Login and registration form
Page Overview
[Hide]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.
- The Login Screen needs autocomplete-attributes for the username
- The registration form should have autocomplete-attributes for username, given-name , family-name, email.
- Password Assitance Form needs autocomplete-attributes for the username and email but NOT for the Password itself.
- 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
- …
9 Discussion
10 Implementation
{ The maintainer has to give a description of the final implementation and add screenshots if possible. }
Test Cases
- {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}.
Last edited: 27. Mar 2024, 12:26, Tödt, Alexandra [atoedt]