We accomplished quite a lot with D7 in getting in 3 classes to make it easier for themers to know how to hide information from everyone, show it to screen readers and show it on focus. I want to fist take a moment to say how amazing this is. I have yet to hear of any other CMS that has adopted a systematic method in core to give people clear and tested means to do this. It really isn't a trivial issue (even though it's just a few lines of css) because this formal process allows for themers to over-ride this in their themes if they wish. If all modules have been using the same structure then sites can have a single, updatable way for them to implement content for accessibility.
- The .element-hidden is used for elements which should not be immediately displayed to any user.
- The .element-invisible class hides elements visually, but keep them available for screen-readers.
- The .element-focusable class extends the .element-invisible class to allow the element to be focusable when navigated to via the keyboard.
I do think this should be re-considered for D8. Now that we've got experience implementing this in many sites, where are the places where it didn't work or where the solution wasn't flexible enough? Jeff's suggested that this solution may have caused issues with Google Chrome & vertical tabs. Are there other places where this approach isn't sufficient?
There are reports of problems with this in some versions of the Blackberry. Drupal 8 should be compared against a whole new series of devices and we should be looking at phasing out some of the old devices. Heck, maybe we won't even have to worry about IE7 support in D8.
Snook.ca looked at our work and suggested a modification to. His observations were that by forcing a scrollbar in Webkit and Opera, it does, in fact, seem to cause overflow. A compromise from the comments that was proposed was:
.element-invisible {
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px);
}
I've posted some other comments from Paul Jackson that I started working through in GDO. He was working with IE6/7 & for government sites and ran into some problems with the onfocus class. He was suggesting:
.element-invisible.element-focusable:active,
.element-invisible.element-focusable:focus
{
position: static;
clip: auto;
height: inherit !important;
width: inherit !important;
overflow: inherit !important;
}
I don't see any way to get around using !important, but there's definitely some grief about that, but maybe there is a way. Perhaps there's a cleaner CSS3 way to do that.
Would it be useful to build on this to also provide in a standardized way to display unpublished content in an accessible manner. I'm not sure what other standardizations could help to provide better accessibility, but we do have to re-consider this with each new major release.
I saw & loved @sun's comment ".element-invisible in system.base.css. I believe most of you participated in the original issue and follow-up issues, so kinda needless to state that those effective 3 lines of code required an evil and neverending nightmare of proposals, patches, manual browser-testing, accessibility testing, follow-up fixes, and whatnot. There are countless of non-obvious details in those innocent 3 lines, but none of them are documented. "
And want to restate that because ya. It was a massive thread and I don't want anyone else to have to read through that let alone start another marathon session on this for D8.
For this issue we do really need to have a nice chart which plots the supported browsers & css solutions & documents issues with them. The issue queue isn't the best way to easily wrap ones head around the trade offs with any given solution. But heck, maybe we'll be able to discuss this in a Prairie format that provides richer ways to gather best practices.
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedsubscribe
Comment #2
Jeff Burnz CreditAttribution: Jeff Burnz commentedI'd strongly back the establishment of more formal testing guidelines. Perhaps we can set up google doc spreadsheets with browsers, devices and patch numbers etc.
We also need to have a list of all the places we have used this class - then classify those, maybe by module and element type (instance types) - try to get a picture of where this has been used and where the problem areas are.
We need to have a very planned and incremental approach. Test the obvious bugs first and then retest all the known instance types in all the browsers and devices. Testing every known instance is probably not feasible nor productive.
I think our clip approach has held up remarkably well, only the odd minor issue and the one major issue with Blackberry OS 5.x, given the wide usage of the class - what I would say is that we can't do that again - it was a little bit reckless imo, we put in a lot of instances of this class with bugger all follow up testing and just crossed our fingers it wouldn't blow up.
So, document usage, more rigorousness testing, better planning, incremental change.
Comment #4
mgiffordUpdating this with a note from GDO/accessibility - http://groups.drupal.org/node/120224#comment-520024
Not sure if we'll need IE6 or IE7 testing for D8, but these hacks may come in useful!
Comment #5
Everett Zufelt CreditAttribution: Everett Zufelt commentedComment #6
RobLoachWe should probably follow ideologies that already exist for us, like the jQuery UI CSS Framework...
Comment #7
bryancasler CreditAttribution: bryancasler commentedsubscribe
Comment #8
mgifford@Rob - I'm all for re-using concepts, and as much as we can borrow from jQuery's UI would make sense.
Jeff posted another instance where we aren't finding a solution for element-invisible that is working well in this instance:
http://drupal.org/node/1057912#comment-4997606
Should we have another class in D8 which can be used to bring a non-focusable element offscreen?
Comment #9
Jeff Burnz CreditAttribution: Jeff Burnz commented.ui-helper-hidden-accessible: looks like the one Rob is suggesting, I use this technique for non-focusable elements because its rock solid, as long as its off-top its no problem from what I recall of our testing during element-invisible dev.
Comment #10
RobLoachWhat if we were to replace instances of...
... All throughout core. Start using this jQuery UI thing we have available to us.
Comment #11
Jeff Burnz CreditAttribution: Jeff Burnz commentedNo, not really that simple. .ui-helper-hidden is display: none; precisely what we don't want and can't replace element-invisible with such a thing. .ui-helper-hidden-accessible uses absolute positioning which is useful for non-focusable elements, but in all practicality useless for focusable elements. Our class definitions are far more sophisticated and robust. We don't want to go backwards here. If jQuery were to get with the times and include real accessible class definitions and stick with them, then maybe, but right now its Drupal setting the pace with regards to this sort of thing.
Comment #12
mgiffordJust realized that the invisible fieldset proposed here fieldset.fieldset-invisible is worth looking at too:
#504962: Provide a compound form element with accessible labels
Also, links to another use case here:
#1361102: Expose visually-hidden visibility for Field's Label in Manage Display
Comment #13
JacineThe fix I've been using for this is in HTML5 Boilerplate: https://github.com/h5bp/html5-boilerplate/blob/master/css/style.css#L258
Comment #14
Everett Zufelt CreditAttribution: Everett Zufelt commentedI'm onboard with this change. We have spent a lot of time evangelizing on the current names. But, I like the rationale of moving to names that are already in use in H5BP. Since there have been no strong arguments against, and this makes things easier to understand, then +1.
Comment #15
mgiffordWanted to note that the new Zen theme is using the snook.ca code #1638036: Make visually-hidden component match Drupal 8's
And also call to the renaming suggested in #1363112: Simplify names of "element-x" helper classes
Comment #16
mgiffordThis started as a meta issue, but the patch for this is moving to #1363112 so for now I'm marking this as a duplicate.
Comment #17
mgiffordGoogle still is directing folks to this queue over #1363112: Simplify names of "element-x" helper classes