Thanks to @merlinofchaos in #1963124-7: Resolve WCAG2 accessibility errors on main settings page I learned that the #states mechanism uses CSS display:none; to hide content.
Unfortunately, this means that for screen reader users, nothing gets presented to the user. For a keyboard only user this isn't a problem because when they select a checkbox new ones appear, but screen reader users need to either have access to all of the checkboxes or be alerted that there is a change to the page.
I think the best approach is to simply mimic what we did with element-hidden & element-invisible and make a:
.js .js-hide {
display: none;
}
.js .js-invisible {
position: absolute !important;
clip: rect(1px, 1px, 1px, 1px);
overflow: hidden;
height: 1px;
width: 1px;
word-wrap: normal;
}I think that would address the problem, but it ties into core/misc/states.js
Any thoughts on this would be appreciated.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | drupal_process_states-1966990-12a.patch | 524 bytes | mgifford |
| #12 | drupal_process_states-1966990-12.patch | 546 bytes | mgifford |
| #4 | drupal_process_states-1966990-3.patch | 493 bytes | mgifford |
Comments
Comment #1
larowlanOuch! This will be great if we can refactor that easily.
Comment #2
mgiffordI think this would involve adding a hidden state to states.js
But I'm really not sure how the visible/invisible code works here:
Or how to add a 3rd state to this.
Comment #3
mgiffordGetting an initial patch rolling for testing. Maybe it can all be just visually hidden rather than adding a new state.
Comment #4
mgiffordThought it was attached. Also, here's a related issue #1899836: Accessibility improvements for States API
Comment #5
mgifford#4: drupal_process_states-1966990-3.patch queued for re-testing.
Comment #6
seutje commentedodd, I wanted to group the selectors with .element-hidden, but I couldn't find it anywhere in core CSS, even though it's still being used as a class o.O
I take it .visually-hidden wouldn't work for this use-case?
Comment #7
mgiffordThis is the table between D7 & D8 with the hidden/invisible changes:
Hope this clarifies things.
Comment #8
mgifford#4: drupal_process_states-1966990-3.patch queued for re-testing.
Comment #9
mgifford4: drupal_process_states-1966990-3.patch queued for re-testing.
Comment #10
jhedstromPatch still applies--were folks agreed on this fix? The table in #7 is a great overview.
Comment #12
mgiffordThe base is here core/modules/system/css/system.module.css
I'm not sure what is extended by
/* @extend .visually-hidden */in core/themes/bartik/css/style.cssIt is slightly different in core/modules/config_translation/css/config_translation.admin.css
It is missing the
word-wrap: normal;in:I'll file an issue for config_translation.admin.css so that it keeps up.
Comment #14
damienmckennaIs this something that could be backported to D7? There are some efforts to improve the CTools / Panels world, e.g. #1963124: Resolve WCAG2 accessibility errors on main settings page, #2280853: Keyboard trap when using ctools modal, but would core improvements be considered?
Comment #15
mgiffordIn general I would think so, but .js-hide isn't used in D7. Right now ctools 7 is using
display:none; in several places css/dropdown.css, css/collapsible-div.css, css/dropbutton.css, js/modal.js, page_manager/css/page-manager.cssIt would be good for someone who knows ctools better to verify that it shouldn't be used in all of these cases. If it doesn't convey any semantic meaning, then
display:none;is ok, but often there is meaning which is obscured.Comment #16
damienmckennaComment #20
mgiffordComment #21
larowlanCorrect me if I'm wrong, but this would mean that the screenreader reads the fields aloud.
I've commonly used states to build a form on the client-side without needing AJAX calls, to save on server load/round trips.
In these instances the hidden fields should not be read until such time as the particular selection has been made.
And in those instances I think we'd want to use Drupal.announce to announce their presence?
Thoughts?
Comment #22
mgiffordHmm.. True.. It would be better to use Drupal.announce in those cases.
I don't know the process states well enough to know if we could build in a Drupal.announce call automatically when the selection is made.
Having it read outloud twice is better than not having it be visible at all. What are the best defaults here to see that we can make this accessible to the broadest base?
Comment #23
mgiffordChanging title of this issue to allow for a better solution.
Comment #24
mgiffordComment #36
quietone commenteddoing Bug Smash triage,
There hasn't been any discussion here in 7 years, has this been fixed in the meantime?
Comment #38
smustgrave commentedSince there hasn't been a follow up to #36 in a year going to close for now.
But please if still a bug reopen, updating issue summary where needed.
Thanks!