Bug 33766 - Accessibility: Fix ambiguous form-field in opac-auth.tt
Summary: Accessibility: Fix ambiguous form-field in opac-auth.tt
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Matt Blenkinsop
QA Contact: Testopia
URL:
Keywords:
: 7867 33764 33765 (view as bug list)
Depends on:
Blocks: 23003
  Show dependency treegraph
 
Reported: 2023-05-18 13:02 UTC by Matt Blenkinsop
Modified: 2024-07-12 07:49 UTC (History)
13 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 33766: Fix ambiguous "Login" field (1.55 KB, patch)
2023-05-18 13:09 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (1.60 KB, patch)
2023-05-18 15:46 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.06 KB, patch)
2023-08-17 12:49 UTC, Paul Derscheid
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.14 KB, patch)
2023-08-17 12:59 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 33766: (follow-up) Fix ambiguous "Login" field (14.41 KB, patch)
2023-08-17 15:00 UTC, Paul Derscheid
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.14 KB, patch)
2023-08-31 15:25 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 33766: (follow-up) Fix ambiguous "Login" field (14.49 KB, patch)
2023-08-31 15:26 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 33766: (sign-off follow-up) Fix sentence case (1.92 KB, patch)
2023-08-31 15:26 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.17 KB, patch)
2023-08-31 16:20 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Fix ambiguous "Login" field (14.52 KB, patch)
2023-08-31 16:20 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (sign-off follow-up) Fix sentence case (1.95 KB, patch)
2023-08-31 16:20 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Enable translation for strings (1.89 KB, patch)
2023-08-31 16:20 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Change "cardnumber" to "card number" (2.28 KB, patch)
2023-08-31 16:20 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.17 KB, patch)
2023-10-25 16:37 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Fix ambiguous "Login" field (14.51 KB, patch)
2023-10-25 16:37 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (sign-off follow-up) Fix sentence case (1.95 KB, patch)
2023-10-25 16:37 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Enable translation for strings (1.89 KB, patch)
2023-10-25 16:37 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Change "cardnumber" to "card number" (2.28 KB, patch)
2023-10-25 16:37 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: Fix whitespace and add i18n to helper block (1.22 KB, patch)
2023-11-29 15:36 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.15 KB, patch)
2023-12-04 17:01 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Fix ambiguous "Login" field (14.69 KB, patch)
2023-12-04 17:01 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (sign-off follow-up) Fix sentence case (1.95 KB, patch)
2023-12-04 17:01 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Enable translation for strings (1.89 KB, patch)
2023-12-04 17:01 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Change "cardnumber" to "card number" (2.28 KB, patch)
2023-12-04 17:01 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: Fix ambiguous "Login" field (12.17 KB, patch)
2024-07-08 16:29 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Fix ambiguous "Login" field (13.44 KB, patch)
2024-07-08 16:29 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (sign-off follow-up) Fix sentence case (1.95 KB, patch)
2024-07-08 16:29 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Enable translation for strings (1.89 KB, patch)
2024-07-08 16:30 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Change "cardnumber" to "card number" (2.28 KB, patch)
2024-07-08 16:30 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 33766: (follow-up) Enable use of translation functions in html_helpers.inc (799 bytes, patch)
2024-07-08 16:30 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Blenkinsop 2023-05-18 13:02:55 UTC
The form field for "userid" is called Login. This is confusing for screen readers and has been flagged as non-compliant in an accessibility report carried out for the British Museum.
Comment 1 Matt Blenkinsop 2023-05-18 13:09:30 UTC
Created attachment 151416 [details] [review]
Bug 33766: Fix ambiguous "Login" field

This patch changes the use of "Login" to "Username" to assist with screen reading

Test plan:
1) On the OPAC homepage, click on Lists in the top left
2) Click Log in to create your own lists
3) The login form should have the first field labelled as Username, not Login
Comment 2 Owen Leonard 2023-05-18 13:51:20 UTC
(In reply to Matt Blenkinsop from comment #0)
> has been flagged as non-compliant in an accessibility report
> carried out for the British Museum.

What is problematic screen reader behavior? It seems wrong to me that the screen reader should care what name or id the field has as long as it has an associated label.
Comment 3 Laura Escamilla 2023-05-18 15:44:56 UTC
(In reply to Owen Leonard from comment #2)
> (In reply to Matt Blenkinsop from comment #0)
> > has been flagged as non-compliant in an accessibility report
> > carried out for the British Museum.
> 
> What is problematic screen reader behavior? It seems wrong to me that the
> screen reader should care what name or id the field has as long as it has an
> associated label.

It's not so much an issue with the screen reader device, but with the patrons using the device to login into our Opac. Since the field is currently named "Login" it might confuse patrons using the screen reader since they might not understand that it is the "Username" field.
Comment 4 ByWater Sandboxes 2023-05-18 15:46:55 UTC Comment hidden (obsolete)
Comment 5 Katrin Fischer 2023-05-18 15:50:08 UTC
Sorry, but have to veto here: we picked login on purpose as Koha accepts both, the username and the cardnumber. So login was the best fit we found that was not indicating one or the other only.
Comment 6 Laura Escamilla 2023-05-18 16:12:52 UTC
(In reply to Katrin Fischer from comment #5)
> Sorry, but have to veto here: we picked login on purpose as Koha accepts
> both, the username and the cardnumber. So login was the best fit we found
> that was not indicating one or the other only.

Maybe we can update it to "Login ID"? That way patrons will understand that it's intended to be a username/cardnumber field and not the Login button itself?
Comment 7 Katrin Fischer 2023-05-18 17:12:08 UTC
But doesn't the screen reader indicate if something is a link or button? Just wondering because login seems a very common field label. And I worry with login ID people will overthink it. Would be great to get more opinions/eyes on this one.
Comment 8 Jonathan Field 2023-05-19 09:37:25 UTC
I'll post the full comment from the screen reader assessor: -

"Providing a descriptive form field label will allow users to know what information to enter in a form field. Where a series of form fields relate to similar information, the context of the form fields needs to be included in the field description. The form field label should also show how it relates to other items in the form.

On the ‘Login’ page there is a form field ambiguously labelled ‘Login’. This labelling does not help the user to understand what information is required.

When there are any fields that are not sufficiently labelled it will be very difficult, or impossible for the information to be successfully submitted. All form fields need to be labelled clearly. This will allow a screen reader user to have all the information needed to complete any process. When all form fields are clearly labelled, then it is not only beneficial to the visitor, but also for the site owners; as correct information will get to them."

So, to summarise, "Login" is really the action that is happening on this page (we are "logging" into the system), it is ambiguous to the user as to what information to provide in order to initiate the "login". As you say, in order to login, we can use "username or cardnumber" here so maybe we should label as such?

As things stand this is a WCAG 2.1 Priority A fail, not even AA.
Comment 9 Katrin Fischer 2023-05-19 11:34:59 UTC
I see the problem, I just feel there is no easy solution. 

For us some libraries don't use the cardnumbers (chip cards), but only a username, other only use cardnumbers, others use both. The flexibility of Koha makes it hard to give an accurate description in terms of "one that fits all"

Not a native speaker, so not sure if any of these would work:

* Login name
* User ID

Make it super accurate, but preference + template driven to allow one of those options:

* Username
* Cardnumber
* Username/cardnumber
Comment 10 Owen Leonard 2023-05-19 12:15:44 UTC
Perhaps we should say "Username or card number" ?
Comment 11 Jonathan Field 2023-05-19 13:44:41 UTC
Yes, I agree Owen
Comment 12 Matt Blenkinsop 2023-05-19 13:53:44 UTC
*** Bug 33764 has been marked as a duplicate of this bug. ***
Comment 13 Matt Blenkinsop 2023-05-19 13:54:08 UTC
*** Bug 33765 has been marked as a duplicate of this bug. ***
Comment 14 Matt Blenkinsop 2023-05-19 13:55:20 UTC
There are multiple instances of this that need changing once a solution is agreed on, closing the other bugs and will wrap all the changes into this bug once we have a way forward
Comment 15 Katrin Fischer 2023-05-19 14:23:25 UTC
We have a lot of variations where libraries only use one or the other, but having both on the label reflects what Koha actually does, so we can do that.

(Still a fan of the pref idea tho - jQuery'ing your way out of such a change is no fun with lots of languages)
Comment 16 Katrin Fischer 2023-08-04 19:32:43 UTC
*** Bug 7867 has been marked as a duplicate of this bug. ***
Comment 17 Paul Derscheid 2023-08-17 08:54:22 UTC
Any suggestions on the pref name?
Comment 18 Matt Blenkinsop 2023-08-17 09:08:09 UTC
Decision reached: OPACLoginLabelTextContent
Comment 19 Paul Derscheid 2023-08-17 12:49:43 UTC Comment hidden (obsolete)
Comment 20 Paul Derscheid 2023-08-17 12:57:09 UTC
Just noticed that this is not translatable in this way.
Comment 21 Matt Blenkinsop 2023-08-17 12:59:53 UTC Comment hidden (obsolete)
Comment 22 Matt Blenkinsop 2023-08-17 13:00:42 UTC
Didn't see your comment before SO! Changing back to NSO
Comment 23 Paul Derscheid 2023-08-17 15:00:31 UTC Comment hidden (obsolete)
Comment 24 Matt Blenkinsop 2023-08-21 14:04:20 UTC
I think it needs to be sentence case i.e. "Cardnumber or username" rather than "Cardnumber or Username"
Comment 25 Matt Blenkinsop 2023-08-31 15:25:58 UTC Comment hidden (obsolete)
Comment 26 Matt Blenkinsop 2023-08-31 15:26:02 UTC Comment hidden (obsolete)
Comment 27 Matt Blenkinsop 2023-08-31 15:26:05 UTC Comment hidden (obsolete)
Comment 28 Owen Leonard 2023-08-31 16:20:33 UTC Comment hidden (obsolete)
Comment 29 Owen Leonard 2023-08-31 16:20:35 UTC Comment hidden (obsolete)
Comment 30 Owen Leonard 2023-08-31 16:20:38 UTC Comment hidden (obsolete)
Comment 31 Owen Leonard 2023-08-31 16:20:40 UTC Comment hidden (obsolete)
Comment 32 Owen Leonard 2023-08-31 16:20:43 UTC Comment hidden (obsolete)
Comment 33 Lucas Gass 2023-10-24 17:15:11 UTC
It looks like there are now some merge conflicts with html_helpers.inc
Comment 34 Owen Leonard 2023-10-25 16:37:44 UTC
Created attachment 157854 [details] [review]
Bug 33766: Fix ambiguous "Login" field

This patch introduces a new syspref 'OPACLoginLabelTextContent' which can be set
to the following values
- Cardnumber
- Username
- Cardnumber or Username

To test:
- Check that the label for
    - The masthead inc
    - The opac-auth template
    - The opac-main template
    - The opac-password-recovery template
    - The opac-registration-confirmation template
    - The opac-reset-password template
    - The sco-main template
  reflect the changes you made to the syspref

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 35 Owen Leonard 2023-10-25 16:37:47 UTC
Created attachment 157855 [details] [review]
Bug 33766: (follow-up) Fix ambiguous "Login" field

This follow-up fixes some problems w/ the unconventional
parts of the first commit. We now use conditionals in
a BLOCK to map the selected value from the preference
to string representations which should now be easily
translatable.

To test:
- Check that the label for
    - The masthead inc
    - The opac-auth template
    - The opac-main template
    - The opac-password-recovery template
    - The opac-registration-confirmation template
    - The opac-reset-password template
    - The sco-main template
  reflect the changes you made to the syspref

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 36 Owen Leonard 2023-10-25 16:37:50 UTC
Created attachment 157856 [details] [review]
Bug 33766: (sign-off follow-up) Fix sentence case

"Cardnumber or Username" is now "Cardnumber or username"

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 37 Owen Leonard 2023-10-25 16:37:52 UTC
Created attachment 157857 [details] [review]
Bug 33766: (follow-up) Enable translation for strings

In my test the strings inside a SET directive were not picked up for
translation. This patch adds the t() function around the new strings in
order to allow them to be translated.

To test, apply the patch and test the translation process for any
language, in this example fr-FR:

- Run 'perl translate update fr-FR'
- Open misc/translator/po/fr-FR-messages.po
- Look for the affected strings: "Username", "Cardnumber", and
  "Cardnumber or username."
- Update the po file with translations of the strings
- Run 'perl translate install fr-FR'
- View the OPAC in your translated language and test each setting of
  OPACLoginLabelTextContent to confirm that the translated strings
  appear.
Comment 38 Owen Leonard 2023-10-25 16:37:55 UTC
Created attachment 157858 [details] [review]
Bug 33766: (follow-up) Change "cardnumber" to "card number"

"Cardnumber' isn't really a word, and I think it comes off as
librarian-speak. This patch updates it to "Card number"
Comment 39 Lucas Gass 2023-10-25 17:21:52 UTC
I found 2 issues here: 

1. There is now a space between the text and the colon.
Card number or username :

2. I notices that on opac-auth, I do not see the translated string and instead only get a colon. 
If I add [% PROCESS 'i18n.inc' %] it seems to fix that. 

However, since I can use the modal login on any page, I find a lot of pages where we do not do so. 

Can we add [% PROCESS 'i18n.inc' %] inside the block in html_helpers?
Comment 40 Matt Blenkinsop 2023-11-29 15:36:29 UTC
Created attachment 159342 [details] [review]
Bug 33766: Fix whitespace and add i18n to helper block
Comment 41 Matt Blenkinsop 2023-11-29 15:37:15 UTC
Looks like some whitespace was being added either side of the string. I've removed it and added the i18n block to the helper block
Comment 42 Owen Leonard 2023-12-04 17:01:09 UTC
Created attachment 159546 [details] [review]
Bug 33766: Fix ambiguous "Login" field

This patch introduces a new syspref 'OPACLoginLabelTextContent' which can be set
to the following values
- Cardnumber
- Username
- Cardnumber or Username

To test:
- Check that the label for
    - The masthead inc
    - The opac-auth template
    - The opac-main template
    - The opac-password-recovery template
    - The opac-registration-confirmation template
    - The opac-reset-password template
    - The sco-main template
  reflect the changes you made to the syspref

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 43 Owen Leonard 2023-12-04 17:01:12 UTC
Created attachment 159547 [details] [review]
Bug 33766: (follow-up) Fix ambiguous "Login" field

This follow-up fixes some problems w/ the unconventional
parts of the first commit. We now use conditionals in
a BLOCK to map the selected value from the preference
to string representations which should now be easily
translatable.

To test:
- Check that the label for
    - The masthead inc
    - The opac-auth template
    - The opac-main template
    - The opac-password-recovery template
    - The opac-registration-confirmation template
    - The opac-reset-password template
    - The sco-main template
  reflect the changes you made to the syspref

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 44 Owen Leonard 2023-12-04 17:01:14 UTC
Created attachment 159548 [details] [review]
Bug 33766: (sign-off follow-up) Fix sentence case

"Cardnumber or Username" is now "Cardnumber or username"

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 45 Owen Leonard 2023-12-04 17:01:17 UTC
Created attachment 159549 [details] [review]
Bug 33766: (follow-up) Enable translation for strings

In my test the strings inside a SET directive were not picked up for
translation. This patch adds the t() function around the new strings in
order to allow them to be translated.

To test, apply the patch and test the translation process for any
language, in this example fr-FR:

- Run 'perl translate update fr-FR'
- Open misc/translator/po/fr-FR-messages.po
- Look for the affected strings: "Username", "Cardnumber", and
  "Cardnumber or username."
- Update the po file with translations of the strings
- Run 'perl translate install fr-FR'
- View the OPAC in your translated language and test each setting of
  OPACLoginLabelTextContent to confirm that the translated strings
  appear.
Comment 46 Owen Leonard 2023-12-04 17:01:19 UTC
Created attachment 159550 [details] [review]
Bug 33766: (follow-up) Change "cardnumber" to "card number"

"Cardnumber' isn't really a word, and I think it comes off as
librarian-speak. This patch updates it to "Card number"
Comment 47 Phan Tung Bui 2024-01-09 21:09:48 UTC
When i enter an incorrect username or password on the opac-user pl pages then click on log-in, instead of seeing the expected information like your username or card number, you only see a colon ":".
Comment 48 Owen Leonard 2024-02-06 12:15:18 UTC
html_helpers.inc defines a variable, preference_value, with the contents of the OPACLoginLabelTextContent system preference. This variable seems to be available everywhere but on the login screen (opac-auth.tt).
Comment 49 Owen Leonard 2024-07-08 16:29:53 UTC
Created attachment 168600 [details] [review]
Bug 33766: Fix ambiguous "Login" field

This patch introduces a new syspref 'OPACLoginLabelTextContent' which can be set
to the following values
- Cardnumber
- Username
- Cardnumber or Username

To test:
- Check that the label for
    - The masthead inc
    - The opac-auth template
    - The opac-main template
    - The opac-password-recovery template
    - The opac-registration-confirmation template
    - The opac-reset-password template
    - The sco-main template
  reflect the changes you made to the syspref

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 50 Owen Leonard 2024-07-08 16:29:56 UTC
Created attachment 168601 [details] [review]
Bug 33766: (follow-up) Fix ambiguous "Login" field

This follow-up fixes some problems w/ the unconventional
parts of the first commit. We now use conditionals in
a BLOCK to map the selected value from the preference
to string representations which should now be easily
translatable.

To test:
- Check that the label for
    - The masthead inc
    - The opac-auth template
    - The opac-main template
    - The opac-password-recovery template
    - The opac-registration-confirmation template
    - The opac-reset-password template
    - The sco-main template
  reflect the changes you made to the syspref

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 51 Owen Leonard 2024-07-08 16:29:59 UTC
Created attachment 168602 [details] [review]
Bug 33766: (sign-off follow-up) Fix sentence case

"Cardnumber or Username" is now "Cardnumber or username"

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 52 Owen Leonard 2024-07-08 16:30:02 UTC
Created attachment 168603 [details] [review]
Bug 33766: (follow-up) Enable translation for strings

In my test the strings inside a SET directive were not picked up for
translation. This patch adds the t() function around the new strings in
order to allow them to be translated.

To test, apply the patch and test the translation process for any
language, in this example fr-FR:

- Run 'perl translate update fr-FR'
- Open misc/translator/po/fr-FR-messages.po
- Look for the affected strings: "Username", "Cardnumber", and
  "Cardnumber or username."
- Update the po file with translations of the strings
- Run 'perl translate install fr-FR'
- View the OPAC in your translated language and test each setting of
  OPACLoginLabelTextContent to confirm that the translated strings
  appear.
Comment 53 Owen Leonard 2024-07-08 16:30:05 UTC
Created attachment 168604 [details] [review]
Bug 33766: (follow-up) Change "cardnumber" to "card number"

"Cardnumber' isn't really a word, and I think it comes off as
librarian-speak. This patch updates it to "Card number"
Comment 54 Owen Leonard 2024-07-08 16:30:08 UTC
Created attachment 168605 [details] [review]
Bug 33766: (follow-up) Enable use of translation functions in html_helpers.inc
Comment 55 Jan Kissig 2024-07-12 07:49:58 UTC
(In reply to Owen Leonard from comment #52)
> Created attachment 168603 [details] [review] [review]
> Bug 33766: (follow-up) Enable translation for strings
> 
> In my test the strings inside a SET directive were not picked up for
> translation. This patch adds the t() function around the new strings in
> order to allow them to be translated.
> 
> To test, apply the patch and test the translation process for any
> language, in this example fr-FR:
> 
> - Run 'perl translate update fr-FR'
> - Open misc/translator/po/fr-FR-messages.po
> - Look for the affected strings: "Username", "Cardnumber", and
>   "Cardnumber or username."
> - Update the po file with translations of the strings
> - Run 'perl translate install fr-FR'
> - View the OPAC in your translated language and test each setting of
>   OPACLoginLabelTextContent to confirm that the translated strings
>   appear.

I am trying on ktd but I get stuck on 

> - Look for the affected strings: "Username", "Cardnumber", and
>   "Cardnumber or username."

It is not found inside that file. Also checked for "Card umber or username." 

As I understand the specific string should be picked up automatically by calling "perl translate update fr-FR"?