Problem/Motivation
When Simpletest module is enabled, the big list of tests (at admin/config/development/testing) offers a text input to filter tests by name. When using this, the list shrinks dynamically. The change is easily noted visually, but is not conveyed to users with screen readers.
Proposed resolution
Use Drupal.announce() to convey a short message about the number of tests now present in the filtered list.
We already make such use of Drupal.announce() in similar filter UIs. Follow the approach found in:
- The modules list (see
core/modules/system/js/system.modules.js) - The block list (see
core/modules/block/js/block.admin.js)
Note: a debounce() is required to prevent too many updates and decrease the amount of announcements to a minimum.
Remaining tasks
This is basically a repeat of the approach we took in #2805205: Provide screen-reader feedback when filtering by block name..
- Devise the announcement string(s). Suggested: "6 tests are available in the modified list."
- Update
simpletest.jsandsimpletest.es6.jsto useDrupal.announce(), handling singular/plural results withDrupal.formatPlural(). - Update
simpletest.libraries.yml. This needs a dependency oncore/Drupal.announce(). - Manual testing:
- Use browser developer tools (e.g. firebug) to watch the content of
div#drupal-live-announce. It lives near the bottom of the HTML document, just before the closing body tag. A screenshot of the HTML with the correct message would be useful evidence of testing. - Alternatively, use the Devel accessibility module, which logs
Drupal.announce()messages to the browser's dev tools console. Again, this is good for a screenshot. - Testing with an actual screen reader is also recommended. Some screen readers have a visible caption window (e.g. macOS VoiceOver calls this the caption panel). This also makes good screenshot evidence.
- Use browser developer tools (e.g. firebug) to watch the content of
- Automated tests (FunctionalJavascript):
- Confirm the updated content of
div#drupal-live-announcewith JavascriptTestBase, for zero, singular, and plural result counts. - Follow the approach in
/core/modules/block/tests/src/FunctionalJavascript/BlockFilterTest.php.
- Confirm the updated content of
User interface changes
- No visible changes intended.
- Add a screen reader announcement to convey updates which are currently only apparent visually.
- Introduces a new translatable string for Drupal.announce().
API changes
None expected.
Data model changes
None expected.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | provide_screen_reader-2897430-9.patch | 6.25 KB | erik.erskine |
| #9 | drupal-announce-devtools.png | 171.89 KB | erik.erskine |
| #16 | Screen Shot 2017-10-20 at 1.45.27 PM.png | 304.64 KB | mgifford |
Comments
Comment #2
andrewmacpherson commentedI think this would be OK for a novice. Mostly it's a copy-paste job of what we did in #2805205: Provide screen-reader feedback when filtering by block name..
If you want a mentor, get in touch via the contact form tab on my user profile, or say hello in the #accessibility channel of Drupal Slack community, or just say so here.
Comment #3
andrewmacpherson commentedMinor updates to the plan.
Comment #4
andrewmacpherson commentedComment #5
andrewmacpherson commentedComment #6
andrewmacpherson commentedComment #7
andrewmacpherson commentedComment #8
erik.erskine commentedGoing to take a look at this today. Some mentoring would be appreciated - thanks!
Comment #9
erik.erskine commentedI've attached a patch that follows the approach suggested. Using the Devel accessibility module, the results are shown in the browser's console (see screenshot).
Yet to verify this with VoiceOver.
The test takes a very long time to complete (15 min compared to 1 min for an empty test). I think that's down to the number of rows in the table - around 3000. Does that matter?
Comment #10
andrewmacpherson commentedThanks for the patch Erik. This looks like it's doing the right thing from the screenshot. I'll give it a detailed look myself, and run tests locally.
Comment #12
mile23+1 nice to have accessibility and also nice to have any kind of test on the filtering.
The test is taking a reeeely long time, so we have to figure out how to fix that. It's ~20-30 seconds per request to render that form...
time says: 546.77 real 52.01 user 4.34 sys
Also we have a deprecation roadmap for simpletest: #2866082: [Plan] Roadmap for Simpletest
Comment #13
andrewmacpherson commentedSince we're now actively pursuing WCAG 2.1, I'm reclassifying this as a bug report.
It relates to the new WCAG 2.1 "Change of Content" success criterion. Under WCAG 2.0 the announcement was a nice-to-have, but under WCAG 2.1 it becomes a must-have. For a longer explanation, see #2864791-33: Implement new Success Criteria from WCAG 2.1.
Comment #14
andrewmacpherson commentedComment #15
andrewmacpherson commentedRemoving the novice tag; the test time quirk sounds tricky.
Comment #16
mgiffordThis looks good to me. You have to install the Testing module first, but after that it gives the expected results at the bottom of the search results.
Comment #18
GrandmaGlassesRopeManMissing trailing comma.
Comment #19
GrandmaGlassesRopeManComment #20
mile23See also: #2893117: Improve HTML caching of Simpletest UI test form which can help with test run time (and general performance).
Comment #21
mile23This test could mock the test_discovery service to return a known set of results. Mock
TestDiscovery::getTestClasses(). The benefits would be no file scan, and no dependency on the number or names of tests displayed.Comment #23
andrewmacpherson commentedThere's a parent plan about this now.
Comment #27
quietone commentedTriaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.
This looks like it belongs in the Simpletest project.