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

(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.

(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.

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.

(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?

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.

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.

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

Perhaps we should say "Username or card number" ?

Yes, I agree Owen

*** Bug 33764 has been marked as a duplicate of this bug. ***

*** Bug 33765 has been marked as a duplicate of this bug. ***

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

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)

*** Bug 7867 has been marked as a duplicate of this bug. ***

Any suggestions on the pref name?

Decision reached: OPACLoginLabelTextContent

Just noticed that this is not translatable in this way.

Didn't see your comment before SO! Changing back to NSO

I think it needs to be sentence case i.e. "Cardnumber or username" rather than "Cardnumber or Username"

It looks like there are now some merge conflicts with html_helpers.inc

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>

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>

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>

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.

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"

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?

Created attachment 159342 [details] [review]
Bug 33766: Fix whitespace and add i18n to helper block

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

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>

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>

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>

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.

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"

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 ":".

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).

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>

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>

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>

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.

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"

Created attachment 168605 [details] [review]
Bug 33766: (follow-up) Enable use of translation functions in html_helpers.inc

(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"?

Created attachment 173757 [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>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 173758 [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>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 173759 [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>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 173760 [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.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 173761 [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"

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 173762 [details] [review]
Bug 33766: (follow-up) Enable use of translation functions in html_helpers.inc

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

A rebase and a signoff