Dave Lane (2c210da8) at 07 Apr 03:29
fixing translation files, removing the 'needs work' and fuzzy desig...
Dave Lane (4e8eea51) at 06 Apr 23:40
attempted fixes to French PO and MO files
Dave Lane (03890126) at 05 Apr 05:49
updated localisation configuration, and tweaked fr_FR translation
Dave Lane (847669a9) at 04 Apr 03:26
fix problem with sending email for password recover
Dave Lane (a373319f) at 04 Apr 02:38
tweaked README for languages
Dave Lane (524e7758) at 04 Apr 01:31
updated language details and instructions
Dave Lane (46495039) at 01 Apr 05:53
fixed issue with submitting invalid form
Dave Lane (f1cd385d) at 31 Mar 02:48
initial commit working multisite and subsite string replacement
... and 3 more commits
Dave Lane (d1eee590) at 16 Nov 21:57
a couple more translation tweaks
Dave Lane (65371b9f) at 16 Nov 21:45
fixed some missing namespace tags in traslation functions, which we...
... and 1 more commit
Dave Lane (ba5c1b33) at 16 Nov 03:14
updated translation string
Many thanks to Greg Gay (from Ryerson) for his very useful feedback and guidance!
For the inline red error messages, add a role="alert" to the elements containing the messages. This will force screen readers to read them when they appear, without having to go looking for the messages.
For the X button to close the registration, welcome, update password, and login dialogs, add a text label "close". An aria-label="close" would work for this purpose, added to the button markup. They currently announce as "button".
The success dialog that opens after logging in, opens briefly, but then disappears before I, with vision, can read the message or get to the OK button, and the screen reader does not seem to notice that dialog. It does not block logging in with the screen reader, but it would make it more difficult to tell whether the login was successful.
Optionally you could include a success dialog/message after logging out.
I did not go through a full registration, to see what happens after. But, maybe extrapolate from the above and apply that to whatever happens after successfully (or not) registering.
Dave Lane (f5038f6a) at 26 Sep 23:41
fixing 2 of the 4 components of issue #19
I have addressed 1 and 2 (adding 'role="alert"' to red error messages, and I've added the 'aria-label'='close' and also 'title'='Close' just for good measure to the close button (X)...
The behaviour of 3 is a tricky one - when the login and log out happen, they trigger a reload of the page, removing any existing dialog window... the dialogs signalling that the login was successful doesn't really require user acknowledgement, but if they're on a very slow computer or network, it gives them the option of doing so, removing the dialog until the reload completes.
I haven't done 4 because the 'logout' removes the workflow from the plugin's control... I thought that the telltale login prompt that returns to the screen with the reload, showing the user that they are no longer logged in, would be sufficient feedback...
Many thanks to Greg Gay (from Ryerson) for his very useful feedback and guidance!
For the inline red error messages, add a role="alert" to the elements containing the messages. This will force screen readers to read them when they appear, without having to go looking for the messages.
For the X button to close the registration, welcome, update password, and login dialogs, add a text label "close". An aria-label="close" would work for this purpose, added to the button markup. They currently announce as "button".
The success dialog that opens after logging in, opens briefly, but then disappears before I, with vision, can read the message or get to the OK button, and the screen reader does not seem to notice that dialog. It does not block logging in with the screen reader, but it would make it more difficult to tell whether the login was successful.
Optionally you could include a success dialog/message after logging out.
I did not go through a full registration, to see what happens after. But, maybe extrapolate from the above and apply that to whatever happens after successfully (or not) registering.
The dialogs are all modals, so should be marked up with related WAI-ARIA (see https://www.w3.org/TR/wai-aria-practices/#dialog_modal). Modals should trap the cursor in the dialog, with focus looping through the dialog, rather than moving to the page in behind the dialog when focus reaches the last element. Dialog are closed by either user input (submitting registration or login), or using the Escape key. If the dialog is dismissed, focus should return to where the dialog was opened from.
Improved with commit 728b973a and merger of 'accessibility' branch into version 1.1.0.
Submitted by Greg Gay: Once a menu or modal dialog is opened it is possible to navigate and submit the form, though when navigating through it focus leaves the dialog and returns to the content in behind it. Focus should remain in popup dialogs until manually dismissed (i.e. Esc), or the login or register link etc. are pressed.
Ref: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
Addressed with full redesign of modal behaviour introduced in 1.1.0 from 'accessibility' branch. Thanks to Greg Gay for his invaluable input!