Opened 10 years ago
Closed 10 years ago
#29955 closed defect (bug) (invalid)
Section 508 issues found on WordPress 4.0 admin page.
Reported by: | johnnygo | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.0 |
Component: | Administration | Keywords: | close |
Focuses: | accessibility | Cc: |
Description
I would like to request for there (5) section 508 issues to be fixed in future release(s).
- When navigating throughout the screen the “Collapse menu” button is not accessible via the keyboard.
Expected result: All user interface elements are expected to be accessible via the keyboard.
- The “Date Format” radio buttons are made available for JAWS to announce as, “Date Format radio button checked to change the selection use the up or down arrows” instead of announcing the label for each radio button. As an example the first radio button is expected to be made available for JAWS to announce as, “Date Format, September 23, 2014 radio button checked 1 of 5 to change the selection use the up or down arrows”.
Expected result: All labels for radio buttons are expected to be made available for JAWS to announce correctly.
- The radio button groups are not correctly formed which makes the groups not available for JAWS to correctly announce. As an example the first radio button is announced as “Date Format radio button checked to change the selection use the up or down arrows” instead of announcing it as, “Date Format, September 23, 2014 radio button checked 1 of 5 to change the selection use the up or down arrows”.
Expected result: All radio button groups are expected to be formed correctly and made available for JAWS to correctly announce.
- When navigating through the screen certain interface elements are not made available for JAWS to correctly announce. As an example the “HD” button is made available for JAWS to announce as, “Unlabeled 7 button” and the “Play” button is made available for JAWS to announce as, “Unlabeled 9 button”.
Expected result: All user interface elements are expected to be made available for JAWS to correctly announce.
- When the user attempts to login with incorrect login information a message appears on the screen, “ERROR: The password you entered for the username admin is incorrect. Lost your password?” This statement is not made available for JAWS to announce automatically.
Expected result: All dynamically appearing messages are expected to be made available for JAWS to announce.
Attachments (3)
Change History (14)
#1
in reply to:
↑ description
;
follow-up:
↓ 2
@
10 years ago
#3
@
10 years ago
Hey, johnnygo - is it possible for you to split this ticket into 5 separate tickets, one for each issue raised? It's much easier to track and assign issues if they're more specific. (If you don't have time, that's cool; I'll just take care of it myself if you can't or I don't hear from you in the next few days.)
#4
in reply to:
↑ description
@
10 years ago
About:
- When the user attempts to login with incorrect login information a message appears on the screen, “ERROR: The password you entered for the username admin is incorrect. Lost your password?” This statement is not made available for JAWS to announce automatically.
Attached patch could be a simple way to have error messages automatically announced after page refresh, given that the login form fields receive focus on page load. Would like to ask the accessibility team their feedback and availability for testing.
Tested with Firefox + NVDA, seems error messages are read out correctly.
This solution could be used also for the other login forms: lost your password, reset password...
Moved also two question marks, small detail in order to have screen readers read out text with a proper tone.
Aside:
having the form fields focused with JavaScript conflicts with the browser trying to focus on the "Would you like to remember the password..." built-in popup, at least in Firefox. A bit annoying for keyboard users.
#5
@
10 years ago
About 2. and 3. made some testing:
- Firefox + NVDA date and time labels are read out correctly
- IE 8 + JAWS 15 labels are completely ignored
Seems because those labels are associated implicitly with their controls, which is valid markup, but maybe JAWS isn't happy with this:
<label>some label text <input ...></label>
Quickly tried to give them an explicit association with for
and ID
<label for="someid">some label text</label> <input id="someid" ...>
JAWS gets happy and reads out the labels correctly.
Maybe new versions of JAWS don't have this issue, to be honest I don't know and unfortunately I can't test IE 9/10/11 and JAWS 16. This would require some discussion and testing by the accessibility team.
#6
@
10 years ago
Tested a bit more issues 2. and 3.
Turns out IE 8 and JAWS 15, when in "form mode", don't read out the implicit label because there's a <span>
wrapping the label text. So with this HTML:
<label><input type="radio" name="test"> <span>implicit label<span></label>
the label text is just ignored. I guess it make sense, when there's an implicit label, IE 8 and JAWS 15 expect to find a text node and instead they find a <span>
.
Oddly, looks like this happens just for radio buttons. See attached test case.
So, lesson learned: never use a span or other elements to wrap a radio button implicit label text.
Patch coming.
#7
@
10 years ago
In the proposed patch for the options - general screen:
- removed
span
s wrapping implicit radio buttons label: they make JAWS ignore the label text - updated the JavaScript part related to the ".example" text
- added 2 missing labels for custom formats text fields
- added "aria-describedby" for elements with a description paragraph
- added some
screen-reader-text
- small CSS fixes including spinner position
Outstanding accessibility issues:
- moving the focus on the custom format fields makes screen readers skip important information
- try a better association between the "example" date and time (the ones changed by JavaScript on radio buttons click) and the input fields
- the link: "to be different from the directory" it's confusing when read out of context, I would propose to change the wording of that sentence and use something like "Learn how to give WordPress its own directory".
Accessibility team testing and any thoughts welcome :)
Replying to johnnygo:
About this specific issue, just proposed a patch in #29958