#32600 closed enhancement (fixed)
wp.a11y.speak improvements
Reported by: | afercia | Owned by: | |
---|---|---|---|
Milestone: | 4.3 | Priority: | normal |
Severity: | normal | Version: | 4.2 |
Component: | General | Keywords: | has-patch |
Focuses: | accessibility, javascript | Cc: |
Description (last modified by )
Now that wp.a11y.speak()
is in core and we have some weeks of real usage experience, we'd like to propose a first round of possible improvements. We have a couple of things for now:
1.
Noticed during the Menu Customizer development and testing, looks like sometimes the previous message gets announced before the current message.
We couldn't consistently reproduce this so, technically, it's not a bug but (see comment 1) we agreed in the last accessibility team meeting to change the aria-relevant value from "all" to the default "additions text".
Basically there's no point in getting also the "removals", at least in this WordPress implementation. Also, see for reference: http://www.w3.org/TR/wai-aria/states_and_properties#aria-relevant
Note: aria-relevant values of removals or all are to be used sparingly. Assistive technologies only need to be informed of content removal when its removal represents an important change, such as a buddy leaving a chat room.
2.
Add the ability to specify the politeness level of the live region. Looks like there's some interest in this feature initially reported by @drew and it would be a nice to have, also making wp.a11y.speak()
a bit more flexible.
For reference: http://www.w3.org/TR/wai-aria/states_and_properties#aria-live
Also, any improvements proposal and feedback would be very welcome and appreciated.
Attachments (6)
Change History (32)
#2
follow-up:
↓ 4
@
9 years ago
- Keywords has-patch dev-feedback added
First pass. Initially tried to have just one live region and dynamically update the aria-live
attribute switching its value as seen in other implementations but after some testing I'm not convinced all screen readers out there can get that right. Decided to go with two separate live regions.
The patch also changes the aria-relevant
attribute to the default value additions text
and introduces one new function to clear the live regions in order to allow repeated strings to be read out.
Tested and it's functional, would appreciate some devs eyes about best practices, code cleaning, etc.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#4
in reply to:
↑ 2
;
follow-up:
↓ 5
@
9 years ago
Replying to afercia:
Tested and it's functional, would appreciate some devs eyes about best practices, code cleaning, etc.
It looks like there is a lot of duplication in the code that creates the two containers. Maybe that could be refactored.
#5
in reply to:
↑ 4
@
9 years ago
Replying to jdgrimes:
It looks like there is a lot of duplication in the code that creates the two containers. Maybe that could be refactored.
Yup, initially tried with an object with default options to be expanded with objects with specific options using $.extend()
but didn't see any real advantage in that. Maybe using a separate function to build the HTML.
#6
follow-up:
↓ 7
@
9 years ago
Refreshed patch uses a function to build the two live regions. Not sure about this though. Yes, the first version is a bit dumb but maybe cleaner IMHO.
#7
in reply to:
↑ 6
@
9 years ago
Replying to afercia:
Refreshed patch uses a function to build the two live regions. Not sure about this though. Yes, the first version is a bit dumb but maybe cleaner IMHO.
I prefer this second patch, because it will be easier to extend in the future if needed. But ultimately, either way works. :-)
I do think that this part should be changed:
57 // Populate the polite and assertive jQuery objects. 58 if ( 'assertive' === politeness ) { 59 $containerAssertive = $container; 60 } else { 61 $containerPolite = $container; 62 }
Rather than putting that in the speakMarkup
function (maybe addSpeakContainer
would be a better name?) I think the $container
should just be returned by the function. Then instead of this:
87 speakMarkup( 'wp-a11y-speak-polite', 'polite' );
You'd do this:
87 $containerPolite = speakMarkup( 'wp-a11y-speak-polite', 'polite' );
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
9 years ago
#14
@
9 years ago
In 32600.5.patch: changed/simplified some names. We are in a "private" name space, no need to prepend anything. Simplified addContainer()
a bit. Still wishing we can change the aria-live
attribute on the fly. Would make all of this much simpler/cleaner.
Made 32600-alt.patch for testing. It changes aria-live
on the fly, then refreshes the DOM (re-inserts the element) and waits for these operations to complete before inserting the new message. @afercia, could you see if that works in the screen readers that didn't work before.
This ticket was mentioned in Slack in #core by afercia. View the logs.
9 years ago
#16
@
9 years ago
Hello all,
Rian asked me to test the patch that fix the double message "Menu deleted Menu created" in VoiceOver. I just finished the test, the bug is fixed. I tested two functions: adding a new menu and adding a menu item, in both cases VoiceOver only announced one message "Menu created".
Would you like me to test some other functions?
I did the test on: http://pctje.xs4all.nl/trunk/src/wp-admin/
With Safari 8.0.6 and OS X Yosemite 10.10.3.
#17
@
9 years ago
After some testing and research I'd recommend a couple of things:
aria-live="assertive"
alone doesn't make most screen readers actually interrupt the current task; adding arole="alert"
together witharia-live="role-assertive"
does- the live regions must be present in the DOM on page load; screen readers don't get the "on the fly" changes on the live region attributes; makes sense since the
aria-live
attribute notifies browsers/screen readers to monitor changes inside a live region and not on the live regions itself
About the last point I would recommend to have a look at this post by Steve Faulkner: http://www.paciellogroup.com/blog/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/ and especially at the enlightening conversation between Mr. Faulkner and Mr. Craig in the comments. And they know what they're speaking about :)
Side note: using an alert role will make some browser announce "Alert" before the message.
For the ones willing to do some testing, I've prepared two demos:
- using two live regions: http://s.codepen.io/afercia/debug/XbzRzE?
- using just one live region, changing its attributes on the fly: http://s.codepen.io/afercia/debug/RPjVQb?
In both demos, a total of 4 messages are dispatched to the live regions, one each 5 seconds. Just let your screen reader start reading out the text in the page and check when it gets interrupted by an "assertive" message. When it gets interrupted, let your screen reader start reading again (just use the up arrow) and check what happens after 5 seconds and so on.
Tested in Firefox 38 + NVDA 2015.2, IE 8 + JAWS 15, Chrome 43 + ChromeVox 45 and only the first demo (the one with two live regions) works consistently for me. Please notice that ChromeVox will always interrupt the current task, regardless the message being "polite" or "assertive". Not a surprise, ChromeVox has so many quirks...
Would greatly appreciate some testing in modern IE and Safari + VoiceOver. Also, any feedback more than welcome.
#18
@
9 years ago
Hello @afercia,
I can help testing the two demos on Safari + VoiceOver.
I'll post my comments tomorrow.
Have a good day!
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#20
@
9 years ago
@afercia
Tested your two demos in Safari (latest) plus Voiceover:
The first demo worked as I would expect: Reading of the page was interrupted by the assertive messages. But not by the polite ones. They only were announced if something else was not being read.
The second demo did not work for me at all. Nothing was announced, whether page content was being read or not.
#21
@
9 years ago
Hi @afercia,
I've tested the two demos. I got the same results than David for demo 2. VoiceOver did not announced any of the 4 messages.
For demo one, I got different results than David. While repeating several times the demo, I noticed that message 4 "Speaking now polite 2" did not interrupt the reading but it was being announced twice in some cases at the end of the reading.
Assertive message 1 did interrupt the reading of the text. Polite message 1 did not interrupted the reading but assertive message 2 did, the thing here is that while interrupting the reading, VoiceOver was announcing the polite message 1 (instead of assertive 2).
I prepared a video to show the results, as it is easier to see than to explain only with words.
http://youtu.be/cKYhSSfb3rU
To start reading the text again, I'm using the combination of VO + space bar.
I'm using OX Yosemite with Safari 8.0.6
#22
@
9 years ago
- Keywords dev-feedback removed
- Milestone changed from Awaiting Review to 4.3
- Type changed from defect (bug) to enhancement
This ticket was mentioned in Slack in #core by obenland. View the logs.
9 years ago
#25
@
9 years ago
- Resolution set to fixed
- Status changed from new to closed
Let's close this as fixed.
If there things left to do, or there are follow ups we can still reopen or create new tickets.
About point 1, our testers were able to reproduce the bug in VoiceOver, see the video posted on Make WordPress Accessible by @rianrietveld at about 0:15 where it announces "Menu deleted Menu created" and similar thing at about 0:55.
https://make.wordpress.org/accessibility/2015/06/12/accessibility-usertest-menu-customizer/