WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#31144 closed defect (bug) (fixed)

Options general screen, accessibility improvements

Reported by: afercia Owned by: azaozz
Milestone: 4.2 Priority: normal
Severity: normal Version: 4.1
Component: Administration Keywords: has-patch, commit, 4.2-strings
Focuses: accessibility Cc:
PR Number:

Description

Splitting this out from #29955 see points 2. and 3.

Basically, the date format and time format radio button labels don't get read out by JAWS. It reads out just "radio button checked". Should read the label text with the date/time example formats.

After some testing with IE 8 and JAWS 15, turned out when in "form mode", JAWS doesn'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.
Simple test case: http://codepen.io/afercia/full/BydyKx/

So, lesson learned: never use a span or other elements to wrap a radio button implicit label text.

In the proposed patch some more issues addressed:

  • removed spans 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 :)

Attachments (4)

31144.patch (8.6 KB) - added by afercia 5 years ago.
31144.2.patch (8.6 KB) - added by afercia 5 years ago.
31144.3.patch (8.6 KB) - added by afercia 5 years ago.
31144.4.patch (8.6 KB) - added by DrewAPicture 5 years ago.

Download all attachments as: .zip

Change History (27)

@afercia
5 years ago

#1 @afercia
5 years ago

  • Keywords has-patch needs-testing added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

#3 @DrewAPicture
5 years ago

  • Milestone changed from Awaiting Review to 4.2
  • Priority changed from normal to high
  • Status changed from new to assigned

Patch still applies.

@joedolson: Mind taking a second look here?

#4 @joedolson
5 years ago

Will do.

#5 @joedolson
5 years ago

This all looks fine. The patch adds a lot more context and explanation for users of screen readers.

I agree with Andrea about the text for moving WordPress into a different directory; this doesn't make a lot of sense out of context. However, the suggested text is also problematic; but I don't have a great suggestion. I've found that a lot of people struggle with the idea that the software can run somewhere other than where the files are installed. As a simpler suggestion, I'd change the link wrapper to surround "want your site home page to be different from your WordPress installation directory". Complete text:

"Enter the address here if you <a>want your site home page to be different from your WordPress installation directory</a>"

While I don't think that this patch totally resolves every possible issue on the page, it is a vast improvement.

@afercia
5 years ago

#6 @afercia
5 years ago

Thanks Joe, updated patch with your suggested new link text.

#7 @rianrietveld
5 years ago

  • Keywords needs-testing removed

Test results WPa11y test team of 31144.2.patch:

Jeff de Wit : Additional descriptions are being read out loud now, so that's good (like the "In a few words, explain what this site is about." for tagline). NVDA didn't have the same issue JAWS seems to have with the radio button fields though (based on the description in the ticket).

Greg Wocher: Everything I looked at seemed to be labled well in JAWS and NVDA on my Windows 8.1

Tina Tedesco (JAWS 15): Everything read out clear and understandable.

Michelle DeYoung (various screen readers and devices: I looked at the General Settings screen again and it announces very well with NVDA/FF. Kudos to the developers! If you want, the example text for the custom date and time formats can be read with the label/input association by using the aria-describedby as done with a few of the other items. It will make it easier on the screen reader user by not making them jump between forms and virtual mode to access the small content items around the form elements.

Malgorzata Mlynarczyk (various screen readers and devices): all fine! :)

Last edited 5 years ago by rianrietveld (previous) (diff)

#8 follow-up: @SergeyBiryukov
5 years ago

  • The period in line 135 should probably be moved out of the link text.
  • The 'custom date format screen reader text' context is unnecessary. _x() is meant to distinguish the same string used in different contexts, and that string is not used anywhere else.

#9 in reply to: ↑ 8 @afercia
5 years ago

Replying to SergeyBiryukov:

  • The period in line 135 should probably be moved out of the link text.

It's a subtle thing, related to the way screen readers read out punctuation. Tested with NVDA, moving the period out of the link, it will be read out:

"Enter the address here if you "
link "want your site home page to be different from your WordPress installation directory"
"dot"

Keeping it inside the link, it will make screen readers do what periods are meant for: a little pause.

In the updated patch, removed 2 unnecessary translation context.

@afercia
5 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by helen. View the logs.


5 years ago

#13 follow-up: @helen
5 years ago

  • Type changed from enhancement to defect (bug)

Let's call a bug a bug. @afercia - how much of the original ticket description is still accurate? For the future, I'd keep the patch description for a comment after opening the ticket. :)

#14 in reply to: ↑ 13 @afercia
5 years ago

Replying to helen:

@afercia - how much of the original ticket description is still accurate?

@helen, the third "outstanding issue" was added in 31144.2.patch and that's the link text. The other two ones have separate tickets, see #31356 and #31354

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

#16 @joedolson
5 years ago

What's currently stopping this ticket from moving forward?

#17 @DrewAPicture
5 years ago

  • Keywords commit added

31144.4.patch looks good for commit.

#18 @DrewAPicture
5 years ago

  • Priority changed from high to normal

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#20 @DrewAPicture
5 years ago

  • Keywords 4.2-strings added

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#23 @azaozz
5 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from assigned to closed

In 31993:

Accessibility improvements for Options general screen: add missing labels and aria attributes.
Props DrewAPicture, afercia. Fixes #31144.

Note: See TracTickets for help on using tickets.