system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard

Ack. Let's just say I'm so happy that this is defined in modules/system/system-behavior.css so that when a major OS/browser does something quirky like this it can be caught & updated in the next minor release.

Now, this is a change suggested from:

.element-invisible {
  height: 0;
  overflow: hidden;
  position: absolute;
}

But unfortunately, the change you made ends up displaying all the text to the browser: Applied it here, but it will be gone next time I refresh the system http://drupal7.dev.openconcept.ca

Other people must have reported this, no? How does Apple recommend that people do this?

I do think it should be marked critical.

Although most of the enhancements that I know of that are presently using .element-invisible are not critical, it's a real waste if a good portion of the blind community won't even notice it.

It is also something which I do expect will be needed to provide more controls for screen-reader users, such as that being suggested for #448292: Drag and Drop for table rows is not accessible to screen-reader users. There needs to be some way to give extra information or controls to screen-readers that aren't required for sighted users.

I had expected Apple to give an example of their 'Skip to Main Content' links from http://www.apple.com/accessibility but apparently they don't. Strangely they also are using access keys.

I grabbed another option from http://drupal.org/node/473396#comment-1882340

Since it's based on this http://webaim.org/blog/hiding-content-for-screen-readers/ article and so I'm sure it will be more widely accepted.

I've applied this patch to my sandbox: http://drupal7.dev.openconcept.ca/

Oh ya, and this patch does work with VoiceOver on Safari on Snow Leopard. Here's a screencast -> http://screenr.com/nHg

I think this really needs more information before proposing a patch to fix the issue, because we don't really know what the issue is:

1) We should really try to nail down if this is a browser issue or a VoiceOver issue.

2) We need to know the specific situations this works and doesn't work; sounds like it works OK with focusable elements but maybe not with non-focusable elements?

The patch in #5 is a proof of concept but not a usable solution because we cant just apply that to things like Skip navigation (a focusable element) without issues such as the "page jump" issue. We'll need another class - which unfortunately complicates things for themers but may be the only reasonable way around this issue.

Seems then we either need two classes or mark it as won't fix.

1) The element invisible could be to changed to use the off-screen method, positioning the element with position absolute. This would be for use ONLY with non-focusable elements.
2) Add a new "hide focusable element" class that uses the existing values of .element-invisible. However this could only be used for elements that actually are going to be shown on focus. If they are not, then we have a problem...

The above is an over-simplification of the actual requirement, because as you mention, those elements only show because they are set to show on focus, but we don't always want focusable elements to show on focus. Skip navigation being the classic example. How to handle that? Right now I have no real work-around for this - the "page jump" issue being the blocker (are we overstating this issue too much, is it really a big issue?).

The "won't fix" is quite possibly an option because the element invisible class that we have come up with is most certainly a best practice - it works on all modern browsers and afaik with all other screen-readers and negates the requirement of more complicated approaches, which means its easy for themers and module developers to understand and use. I would not underestimate this last point, with such wide spread ignorance of basic accessibility among themers and developers it will be a miracle just to get them to use and understand .element-invisible. It will take years, and while not wanting to pander to FUD, I would not like to see this undermined by over complicating the issue by introducing two classes that appear to do the same thing, but one is especially required just to support one screen-reader, on one platform, that very few people actually use.

Could this possibly work?

.element-invisible {
  height: 1px;
  width: 1px;
  overflow: hidden;
  position: absolute;
  opacity: 0;
}

@Jeff Burnz: I'm unsure why you think that having "off-screen" positioning like this will create more issues then the current "height: 0; position: absolute" solution. As far as I can see, both uses absolute positioning, and as a consequence will not trigger "page jump" issues.

Yeh gads, sorry I was confusing two techniques I use all the time, my bad!

From what it seems, I assume the issue here is the height: 0; this is a guess though (I don't have an OSX machine handy for testing).

Be aware that Garland does not use element-invisible but rather a technique more like offscreen and with position:fixed; for the :focus styles.

I put up a page which tries out five different techniques: http://bit.ly/a0Nd3t

From what I recall of the original issue is this:

annmcmeekin commented that moving focusable elements outside the viewport was bad: http://drupal.org/node/473396#comment-1882406

Apart from that there's not a lot discussion around using the offscreen methods, and most centered on the element-invisible method because at the time it was thought to work with all screen readers including previous versions of VO.

We also identified that pretty much the only time you would want to show something on focus, that was previously hidden yet still available to screen readers, were skip navigation links. There are plenty of other things that get hidden and show on focus/click but they tend to use display:none (think jquery hide() with fieldsets) because we really don't want to clutter the "UI" with information for both normal view and screen readers.

So this issue with VO is a real bugbear, although Damien Tournoud's method above looks promising as do the position fixed methods I have used in the past (such as in Garland for the focused skip link).

EDIT: I just tested with NVDA and all the above links are read.

Thanks Everett, for me that basically confirms that height:0; is the problem here.

I'll build another page that uses the successful classes in more situations.

VoiceOver ignores elements that have a width of zero and a height of zero. Your hidden elements need to have width and height, otherwise they will be ignored by VoiceOver

I'm guessing this is a change that the Apple engineers made, likely with Snow Leopard to ignore elements that have a width of zero OR a height of zero. I don't think it's an and issue as otherwise we wouldn't have needed to start this thread (we were just focusing on height:0).

@enrique_palazzo do you have any suggestions of best practices for hiding content from browsers but presenting it to screen readers? We've had a very long discussion on this http://drupal.org/node/473396 and frankly I was pretty sure that we'd nailed this at the time. Apparently not.

The important thing though is that we can just rework element-invisible and apply it and we should be fine. If there's a new best practice we can adopt it and if folks want to override this in the theme they can.

This just does go to show how quickly accessibility is changing & the importance of having a community of people around to be constantly evaluating & improving Drupal!

So #5 or #11 work for folks? We do need to change this before D7 is released. Apple's apparently decided not to speak 0px values.

Mike, we need more testing, I'll work on some more examples tonight, I have test site up and will provide link with prelim patch applied.

Agreed with testing. Would be good to have a few folks to take a look at it in various different environments.

So I've applied the patch in #5 to this CSS:
http://drupal7.dev.openconcept.ca/modules/system/system-behavior.css

People can set up an account with it here http://drupal7.dev.openconcept.ca/

Good place to look for the behavior of the element-invisible class is in the breadcrumb's 'You are here' reference:
http://drupal7.dev.openconcept.ca/aggregator/sources

Which is available to everyone.

Just wanting to raise this again post-DrupalCon. I'd really hate it if Drupal 7 didn't work with the Mac.

We do need more testing, but there are a few solutions to evaluate.

I'm changing this to critical after doing some testing with VoiceOver in Safari. Apple has decided to strike out and not speak out the text of any element that has a height of 0. Therefore, if we want to have apple & iPhone users be able to benefit from the navigation elements we've been building into core we have to change how we hide them.

Fortunately it's just a matter of redefining element-invisible. I've been testing it with this alternative and it works fine:

.element-invisible {
  position: absolute;
  left: -10000px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

Redux:

There is a problem with accessibility of hidden elements using Voiceover on Mac. "VoiceOver / Safari 4.0.4 on OS X Snow Leopard do appear to properly recognize links that appear on foucus, like the skip link at the top of the Garland page, at least as it is implemented at http://zufelt.ca". I didn't see any information about other screen readers.

#5 is a patch, but the conversation implies it isn't the right fix. It's available for testing at #20.
#22 is a method, but not a patch to review. Marking needs work.

Critical means crash, data-loss, or no workaround right? I'm not sure this is critical, but if we get it fixed and tested then great.

I just tried VoiceOver on Safari 4.0.5 on Snow Leopard 10.6.3.

I've never used VoiceOver before, but after some fighting with it, I got it to read my D7 front page. I heard and saw a 'skip to content' link, which when I clicked it took me to the heading of the top node. So it seems to work for me.

+1 for this being critical at any rate. If Drupal isn't accessible then it's not even crashing for some users, it's not working at all.

Confirming I don't get "You are here" read to me.

I tried out #22 with voiceover and safari, the 'you are here' is read then.
Made a patch...

Confirming the patch fixes VoiceOver on Safari. RTBC.

(Off-topic: is the 'you are here' in the breadcrumb really meant to be an H2?)

Guys, can we check this stuff, but I am getting a very strange bug in RTL mode for both the existing implementation and the new proposed implementation.

It happens in all browsers, for Garland, Stark and Bartik although I am not sure as yet what the actual bug/issue is - the effect is a huge horizontal scrollbar, which looks like it doubles with width of the viewport out to the left.

Could we add a RTL version of the element work to address this?

 .element-invisible {
  position: absolute;
  right: -10000px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
 }

It's something I was certainly worried about previously but hadn't tested.

Also, do you have a screen-shot?

Hmmmm, the bug I am getting is intermittent, could be my system but I am not sure.

If I switch to using

.element-invisible {
position: absolute;
top: -10000px;
width: 1px;
height: 1px;
overflow: hidden;
}

All problems cease and desist, any reason why we cannot use top instead of left for non-focusable elements?

Bear with me Mike, I am putting together a whole series of screenshots and it might take a while, different left/right combos etc.

OK, well heres at least one screenshot and I'll describe my issues in detail.

If we use left or right negetive positioning this causes issues in RTL mode in both Firefox and Internet Explorer.

Firefox will expand the viewport in the direction of the negative positioning when the text direction matches the direction of the negative positioning. Use left -10000px and RTL and the viewport expands to the left, use right -10000px and LTR and the viewport expands to the right. In each case swapping text direction results in a normal view, no expansion.

In IE things are rather more strait forward. The same applies for LTR and use of right -10000px, but in RTL mode its broken no matter which positioning direction is used.

Is that enough to rule this out, because from here on in it descends into chaos across various other browsers inducing Opera and Safari, needless to say the behavior is very inconsistent.

Note also that I am getting very different results looking at the front-page verses a node.

@Everett - if its hidden above the viewport I get no issues at all.

The big issue that arises when ruling this out for focusable elements is: what is the alternative?

Negative text-indent, z-index, line-height, height, and opacity methods all have issues, so in all seriousness what are we to use for hiding skip navigation?

Heres one I have been testing that is right out of left field...

#skip-link {
  position: absolute;
  clip: rect(0px 0px 0px 0px);
}

It actually works in Firefox and IE, tested with NVDA only.

Looks like the clip solution works at first sight.
Works on firefox and chrone on ubuntu, let me check some more browsers, and voiceover...

Voiceover reads the text, thats OK.
Tested on safari 4 and firefox 3.6 on mac; firefox and chrome on ubuntu.
BUT, internet explorer 6 & 7 shows the text, don't know on IE8.

When i put a top: -99em, all is ok, on all above browsers, and voiceover reads the text.
Can anyone test on other screenreaders?

Here updated patch.

OK, then we could ignore the clipping and just do it with a top and position absolute.
Tested on all above browsers and voiceover, no problems found.

In IE things are rather more strait forward. The same applies for LTR and use of right -10000px, but in RTL mode its broken no matter which positioning direction is used.

Is that enough to rule this out…[?]

Yes. This is why we nixed the whole left/top: -really-big-negative-value-px; when we wrote the original .element-invisible class.

Regarding the top: -99em; used in the most recent patch, that's not going to work either. If you apply the class to element that is normally on the 102nd line of text, you'll end up with the text overlapping something higher up on the page. That's pretty much going to be true for any value of top. The only reason the negative top is used for "skip links" is because those are always the first thing on the page.

Regarding the clip method. That's a no-go. Unfortunately, IE6 and IE7 used a different syntax then IE8 for the clip propertly. Which means if you use the above syntax (which works in IE8), those elements will still be visible for IE6 and IE7. http://msdn.microsoft.com/en-us/library/ms530748(VS.85).aspx :-p boo.

Here's a patch that uses DamZ's opacity solution in comment #11.

@JohnAlbin

OK, fair enough. Didn't think about that.
I added filter: alpha(opacity=0); to your patch, for internet explorer 6 & 7 compatibility.

Looking good John and betz - tested with NVDA and all text read. No visual issues on Firefox3.6.

But it still doesn't seem to work with VoiceOver. Maybe they don't like opacity=0 either. I've written to Apple's accessibility folks for some guidance.

@mgifford
It works with me with voiceover. Please double check that the patch applied successfully.
I get the sentence 'heading level 2 you are here', which is what we should hear.

it's working on a fresh installed 10.6, without any updates.
And using safari 4.0.3

Confirming that the patch works for me on Safari 4.0.5 on Snow Leopard 10.6.3 -- 'you are here' is read.

can someone test on jaws?

I can confirm that it does work for me. I was tabbing though the links and was expecting Safari to read out the invisible heading before the breadcrumb. It does read it when VoiceOver begins reading the whole page. So I can't skip ahead and have it read to me, but if I'm patient and wait for it to read through the page it does eventually get there. This is because I'm tabbing between links I'm sure.

I'm not sure how to jump between headings in VoiceOver and believe I was just assuming it works differently than it does.

Safari Version 4.0.5 (6531.22.7)
Mac OSX 10.6.3
VoiceOver 3.0.1

@mgifford
That's odd... In my case it reads the 'you are here' before the breadcrumb and before the content.

I expect I'm just not using VoiceOver right. I've got the patch from #42 here:
http://drupal7.dev.openconcept.ca

To test in Arabic/Hebrew:
http://drupal7.dev.openconcept.ca/ar
http://drupal7.dev.openconcept.ca/he

What are the key combinations to navigate by headings with VoiceOver?

Annoying, but easy to remember, "press everything + h". Thanks it worked well!

@everett
Did you have a copy of Jaws? If so, could you test this out?

sub

BTW:

> Thanks for testing. The skip to link doesn't actually use the .element-invisible class.

Is that a separate bug? Surely we should be using only one technique to hide these things.

There was a very long thread to implement the .element-invisible & .element-hidden class

On focus is another behavior that has been suggested as a logical extension of this. At the moment it is being used by Skip to Main Content in core themes.

Good to add to this thread with ideas on a general class:
#639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes

It's a niggle, but "filter: alpha(opacity=0);" should go in an IE conditional stylesheet if we go with this approach, since it is an IE specific convention and doesn't validate (the CSS3 syntax would be opacity:0;).

Critical
When a bug renders a module, a core system, or a popular function unusable. Possible examples from core are the inability to create a new node or blocks won't display. These are to be fixed immediately because the software is not usable at all.

This issue does not fit into the definition at all. #4 even said it's not critical and then it got critical without arguing why it would be so.

@chx: I don't really care if it's listed as normal or critical as long as it is fixed. It's like if major browser decided to drop support for some CSS 2 that made invisible a large piece of Drupal's interface. It is very much a matter of being unable to display information properly to a major screen reader.

This is a trivial change in on very well defined CSS class. It was tested last year before Snow Leopard was released. Sadly we're always going to be chasing the manufacturers of AT (who don't seem to be keen on building standards).

@Owen - Would you see adding the filter: alpha(opacity=0); for the element-invisible class to these core themes -> themes/garldand/fix-ie.css & themes/seven/ie6.css

Not sure where else to add in IE specific fixes in core.

@mgifford - yes, although it looks like for some themes we will need a new IE* specific file (not one specific to just IE6).

This is for Garland though, right? The rest seem to have different options for IE & IE6.

$ ls themes/garland/
block.tpl.php comment.tpl.php fix-ie.css garland.info logo.png minnelli page.tpl.php screenshot.png style-rtl.css theme-settings.php
color CVS fix-ie-rtl.css images maintenance-page.tpl.php node.tpl.php print.css style.css template.php translations

$ ls themes/seven/
CVS ie6.css ie.css images logo.png maintenance-page.tpl.php page.tpl.php reset.css screenshot.png seven.info style.css template.php vertical-tabs.css

$ ls sites/all/themes/corolla
base.css color comment-wrapper.tpl.php forum-list.tpl.php ie8.css maintenance-page.tpl.php page.tpl.php print.css screenshot.png template.php
base-rtl.css colors.css corolla.info ie6.css images node--book.tpl.php poll-bar--block.tpl.php profile-listing.tpl.php style.css
book-navigation.tpl.php comment.tpl.php forum-icon.tpl.php ie7.css logo.png node.tpl.php poll-bar.tpl.php reset.css style-rtl.css

$ ls sites/all/themes/bartik/css/
colors.css ie6.css ie.css layout.css layout-rtl.css print.css style.css style-rtl.css

We discussed element-invisible for another reason here #766444: Add !important to CSS attributes of .element-invisible in system-behavior.css

With the current approach it is very likely that themers unintentionally reveal invisible elements like .block h2 for example by:

• adding a border
• adding a background-color or background-image (together with padding)

We discussed using "!important" here as an exception to the "no !important in core" rule to enforce this special case.

What if element-invisible is used for inline elements? Then width/height will not work. So we need "display: block" in addition with this approach.

Here is one of the suggestions from: http://drupal.org/node/766444#comment-2987150

.element-invisible {
  display: block !important; /* otherwise if used for inline elements width/height will not work */
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  overflow: hidden !important;
  border: none !important;
  padding: 0 !important;
  background-color: transparent !important;
  background-image: none !important;
}

The OFF-LEFT technique seems the most accessible of all approaches as quoted here:
http://drupal.org/node/766444#comment-2991926

What if we use OFF-LEFT for LTR together with the suggestions above and set "left: auto" for RTL.

This patch implements the suggestions from #64 (+ adding OFF-LEFT for LTR)

Line Endings.

Hm, again: fresh checkout. Implements #64

Does this work for rtl?
I would love to see a screenshot of that.

I cant see any visual issues in Firefox 3.6, IE6/7 or Chrome (LTR and RTL).

Thnx Jef for checking it out!

I've applied the patch in #72 to the sandbox here -> http://drupal7.dev.openconcept.ca

I've added screenshots for both RTL & LTR screens. There isn't much Hebrew/Ababic available in the interface, but it switches directions fine.

There are enough other issues with the way Drupal7 manages RTL that I'm not sure which of the problems are tied to patch above.

Ok convinced me..

Just read through this... I'm not sure about the VoiceOver issues so I wont mark this RTBC (though it seems all of that is resolved) but I'm happy with the patch in #72 as it relates to #766444: Add !important to CSS attributes of .element-invisible in system-behavior.css.

@Jacine - So !important will make this easier for folks to theme around? I'm just curious why you're advocating for it. Is the patch in #72 going to be that much easier to implement than the patch in #5?

If so we'll test it with VoiceOver and other browsers and see if we can't move ahead and bring this into core.

Patch #5 takes a similar approach but is not sufficient:
1. It uses the OFF-LEFT technique.
2. And in addition it limits the size of .element-invisible to 1px and hides the overflow. (These seem to be just additional fallbacks, since OFF-LEFT is enough if it works)

The problem with patch #5 is that it is no solution for RTL since it results in huge horizontal scrollbars. So we need a solution that even works if OFF-LEFT fails.

Limiting to 1px is not enough since its not uncommon to use backgrounds, borders, paddings for elemtents that are typically .element-invisible (like .block h2)

Patch #72 adresses these problems. Plus it uses the !important statement to enforce the solutions, especially important for RTL where OFF-LEFT fails.

Ok, I've taken the patch in #72 and applied it here -> http://drupal7.dev.openconcept.ca/node-100-forum

So that the !important elements are there:
http://drupal7.dev.openconcept.ca/modules/system/system-behavior.css
http://drupal7.dev.openconcept.ca/modules/system/system-behavior-rtl.css

It seems to work fine in VoiceOver. Testing in other AT would be good too before RTBCing it.

So !important will make this easier for folks to theme around? I'm just curious why you're advocating for it. Is the patch in #72 going to be that much easier to implement than the patch in #5?

@mgifford Yes. !important will help ensure it stays invisible as CSS is being written, by basically anticipating common "problem" properties and forcing resets on them. All a themer needs to do is apply a background and padding or borders to something like .block h2 and portions of it become visible again.

Less experienced CSS people would likely have issues tracking down the problem and some would probably just bypass trying to fix it altogether and just hide the title in the Blocks UI. The patch in #72 goes a long way in preventing problems like this from arising in the first place, which is a good thing for both sides. We want people to use this class instead of being frustrated by it and ripping it out. :)

Just for the record, this is a very special exception. I would not advocate the use of !important under most other circumstances. I rarely use it myself, and have spoken out against it being included in any core CSS file, but I believe it makes sense here.

This also fixes an issue we have in latests dev releases with element-invisible inside a "h2" header inside a search box.

It works for voiceover and got the code blessing from jacine.

Can someone please review this with AT as mgifford pointed out...
If we don't get this committed before next alpha/beta release people will post new issues (and I don't like duplicates)

EDIT: list of duplicates
#820808: Text field on search block is bugged in chrome

Here is a screen capture of it working in Safari with VoiceOver on Snow Leopard. This was the initial problem. I don't know of other issues with AT. http://screenr.com/5NK

I'm always happy to have more people review patches though. It's posted up here for those who want to test this http://drupal7.dev.openconcept.ca/

Can confirm it works on the latest Chrome 5.0.375 beta, Firefox 3.6.4 beta and IE8.

This seems pretty thoroughly tested; does something else need to be done before setting it RTBC?

I think it's good to be RTBC'd at this point.

Also can confirm this works in IE6 (winXP), FF3.5.9 (ubuntu).

Orca screenreader in FF on ubuntu 9.10 recognizes search button and hover text. unsure of intended behavior when clicking on search field.

unless someone with more expertise accessibility can identify issues, this is RTBC

( found as part of #LADrupal code sprint while working on Bartik core theme issue queue)

Thanks, derjochenmeyer and jacine, for moving this forward. I agree on the usage of !important here.

+++ modules/system/system-behavior.css	Fri May 21 12:53:25 2010
@@ -296,10 +296,18 @@
+ * causes issues for keyboard only or voice recognition users. "!important" is ¶

Trailing white-space here.

+++ modules/system/system-behavior.css	Fri May 21 12:53:25 2010
@@ -296,10 +296,18 @@
 .element-invisible {
...
+  position: absolute !important;
+  left: -999em !important;

+++ modules/system/system-behavior-rtl.css	Fri May 21 12:54:53 2010
@@ -84,3 +84,10 @@
+.element-invisible {
+  left: auto !important;

The element is visible in RTL.

+++ modules/system/system-behavior.css	Fri May 21 12:53:25 2010
@@ -296,10 +296,18 @@
+  background-color: transparent !important;
+  background-image: none !important;

Why not simply combined in one line?

background: transparent none;

65 critical left. Go review some!

@sun:

The element is visible in RTL.

The OFF-LEFT technique does not work for RTL (causing huge horizontal scrollbars in some browsers).
Also see: http://drupal.org/node/766444#comment-2992086

The element is still invisible in RTL since its positioned absolute with 1px dimension und no border, padding, margin, background.

The off-top approach (instead of off-left) was proposed in this and the other issue. In both issues, it was deemed to be a potentially better solution. JohnAlbin counter-argued that -99em or any other value won't necessarily be enough. I disagree; top: -99999em; is more than sufficient, almost zero chance to be visible. Same probability applies to the off-left approach, as there is _always_ a chance that it may not work due to a special theme, dumb browser, or whatever. The off-top approach is the most solid solution we identified so far, so we should figure out the lowest negative value in relative units (em) supported by all browsers and just go ahead with the off-top approach.

What about the clip approach suggested by @Jeff Burnz in #36?

In #41 @JohnAlbin mentioned the different syntax for IE6/IE7, but can't we use a CSS hack for those browsers?

This Article also suggests OFF-TOP:
http://www.abilitynet.org.uk/webarticle67

It also suggests a solution for links within invisible elements. I dont know if drupal-core has any links in element-invisible?

Instead of hiding the ‘skip navigation’ link completely from view, the more optimal solution which benefits both visual and non-visual users alike is to temporarily hide the link until such times as the it receives focus with the tab key. The screen reader user will hear the link be spoken whilst the visual user will see the link when it is given focus. Additionally, from a web developer’s perspective this means that the functionality can be provided without compromising the aesthetics of the web page. To achieve this you would incorporate the following code in your HTML and CSS

.element-invisible a:active, .element-invisible a:focus {
  position:static;
  width:auto;
  height: auto;
}

I don't support the idea of using CSS hacks because a best practice solution seems possible here.

I tested the OFF-TOP technique with browsershots.org
http://forward-media.de/off-top.php

All relevant browsers on browsershots.org hide invisible elements as expected using top: -999999em;

The following browsers dont hide elements when using only OFF-TOP (using -999em OR -999999em)
- MSIE 4.01 WIN 2000
- Dillo 2.2 Ubuntu

Attached patch implements the OFF-TOP technique together with suggested backup.

We need testing in rtl too

Screenshot showing 1) before patch - the issue, and 2) after patch, the result of the patch in 94.

RTL will be fine since there's no left/right stuff going on.

Can't RTBC since the patch failed, otherwise to me this looks good.

Do we need margin: 0 !important; also for extra caution?

My fault. New patch.

This one will work :)

CSS properties should be ordered alphabetically, according to our CSS coding standards, http://drupal.org/node/302199

Ordered alphabetically.

Well I think it is safe to rtbc this.

Although this leaves a jump-off-to-top-and-back difficulty for keyboard-only users when tabbing through all elements (including invisible links) on the page, I'm happy.

Just one last question to be safe: Did we already try to use the following?

.element-invisible {
  z-index: -100;
  position: absolute;
}

...and just that? -- Should at least work in modern browsers.

I thought we needed the width and height, so that the elements could be recognised by the screenreader.

We need to ensure that #104 is not an alternative solution. Boils down to do xbrowser tests, like we did before.

The negative z-index puts the element behind everything else (body is 0-based), the absolute positioning removes its width and height. I.e., the element is located where it normally would be, but hidden in the background.
Padding, margin, border might need some tweaking though.

@sun unfortunately that only works in FF.

Again, patch in #94 works cross browser + has no jump-off-to-top-and-back difficulty for keyboard-only users like @sun identified for the negative top solution.

The CSS hack being used for IE6/IE7 is valid CSS and likely never being supported for any other browser; besides we use this hack on other places in core. I think using this hack here is perfectly justifiable.

I guess you meant #101. So let's move on here.

Oops, I ment #92. #101 has the jump-off-to-top-and-back difficulty for keyboard-only users like you mentioned in #106.

re #104 -I haven't done any extensive testing but negative z-index can be unreliable, for example in IE6 if you nest the element inside a wrapper that has position: relative; applied to it, it will fail - from what I can tell IE6 resets all contained elements to z-index: 0; no matter what is declared otherwise.

In the browsers I tested in (IE6 and Firefox 3.6) you have to hide it behind another element, and that element must have a background, I cant seem to get it to hide below the body element, even when the body has a background.

I ended up doing something like this to get it work - so I think this is a bit tricky to implement and rather easy to break.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Accessibile techniques for hiding and showing content</title>
  <style type="text/css">
  .wrapper {
    background: #eee;
    height: 100px; 
    width: 500px;
  }
  .element-invisible {
    z-index: -100;
    position: absolute;
  }
  </style>
 </head>
 <body>
   <div class="wrapper">
     <div class="element-invisible">I should be hidden</div>
   </div>
</body>
</html>

@sun: z-index will only work if any background is set?
FF 3.6.3 does not hide the 2nd Element here: http://forward-media.de/z-index.php

RTBC was unintentional.

casey - for the clip method from what I can see position: absolute will need !important, otherwise I'm getting good results in further testing of this method.

Sun asked in my blog if this would work:

.element-invisible {
  position: absolute !important;
  clip: rect(0 0 0 0);
  clip: rect(0, 0, 0, 0);
}

I've found that it does. All browsers I tested in (FF3, IE6,7,8, Opera 10, Safari 5) all support clip values with only the space separator, and of course IE6/7 only support the space separator.

The spec says:

User agents must support separation with commas, but may also support separation without commas (but not a combination), because a previous revision of this specification was ambiguous in this respect.

Which is why I assume that Firefox, Opera and Safari support both.

In further testing of the clip method I have found that you can break this in IE7 by adding a large width to it - e.g. if the added width extends beyond the browser window you'll get a scroll-bar, probably pretty much an edge case in any regard but can be neutralized with width:1px !important;, all other browsers do not get the scroll-bar.

#114 Good job! Looks good to me. I tested this on Mac (FF 3.6.3, Chrome 5.0, Safari 4.0.5, Opera 10.10, Camino 2.0.2) and with browsershots.org. It successfully hides the elements in all browsers.

Here is an article that tests the clip: rect method in some screenreaders (using 1px, 1px, 1px, 1px >> looks good too):
http://www.access-matters.com/2005/04/23/screen-reader-test-results/

Comments:
http://www.access-matters.com/2005/04/24/quiz-5210-screen-reader-test-10/

Here is the patch. Implements #114

Do we still need this comment

Must not be used for focusable elements (such as links and form elements) as this causes issues for keyboard only or voice recognition users.

I applied it here - http://drupal7.dev.openconcept.ca/node/1

This solution wasn't working for me in Safari with Voice Over.

You should be able to get to hear 'You are here' but it is ignored.

Can someone remind me what was wrong with the patch here:
http://drupal.org/node/718922#comment-2918006

If it's simply a matter of the RTL issue then I'll add the cs to modules/system/system-behavior-rtl.css so that it is "right: -10000px;" rather than left.

There are a lot of potential solutions, to this problem, but It would be really helpful if people looked at the previous responses & gave a reason why they wouldn't work before going another direction.

Can someone remind me what was wrong with the patch here:
http://drupal.org/node/718922#comment-2918006

- Its not working in RTL (horizontal scrollbar)
- without "!important" its likely to be overwirrten by accident
- width & height are a backup solution if left fails, but without "border: none; padding: none;" this backup is likely to fail too

What do we have now?

1. CURRENT SOLUTION
   

   .element-invisible {
     height: 0;
     overflow: hidden;
     position: absolute;
   }  
   

   • PROs: ?
   • CONs: does not work with Apples Voice Over software because of height: 0; AND is buggy (http://drupal.org/comment/reply/718922#comment-3093748)
2. OFF-TOP (patch: http://drupal.org/node/718922#comment-3098286):
   • PROs: solid (if used with !important), works in all browsers, won’t give any hassles in RTL
   • CONs: can cause a page “jump” if applied to focusable elements
3. OFF-LEFT with backup (rerolled patch attached):
   • PROs: solid (if used with !important), works in all browsers
   • CONs: for RTL it relies on the backup (w&h 1px, no padding, no background, no borders)
4. CLIP: RECT (patch: http://drupal.org/node/718922#comment-3112956):
   • PROs: hard to break, relatively lightweight CSS
   • CONs: (#119) not working in Safari with Voice Over >> clip: rect(0, 0, 0, 0)
   • EDIT: We need to test clip: rect(1px, 1px, 1px, 1px)

according to http://www.access-matters.com/2005/04/23/screen-reader-test-results/ clip() should work in VoiceOver; but maybe only with rect(1px, 1px, 1px, 1px)?

Yeah, it'd be good to try with 1px, since that should yield the same result visually (nothing showing).

I see no harm trying alternative approaches, we should aim for the best method, not just a method that works. With clip you get a lot of the things being declared as !important for free.

Here is a patch

.element-invisible {
  position: absolute !important;
  clip: rect(1px 1px 1px 1px);
  clip: rect(1px, 1px, 1px, 1px);
}

EDIT If the element has a background color or image it will show 1px of it. We could use "background: transparent none !important;" to solve this.

I'm getting good results the patch in #121, no visual problems (off-left method). The Left: auto trickery is doing the job for RTL.

Just a quick question, with all this !important stuff does this actually need LEFT values at all? Can it be auto?

If clip doesn't work with 0 and we get some visuals with 1px I'm less excited about it. Thinking about the clip method - what if the bottom value is less than the top value, and the left value is greater than the right value - this would allow values to be entered but the top would overlap the bottom and the left overlap the right - just a thought?

1. I was wrong: rect(1px, 1px, 1px, 1px) sucessfully hides the element on Mac (FF 3.6.3, Chrome 5.0, Safari 4.0.5, Opera 10.10, Camino 2.0.2).
2. @Jeff Burnz: Actually the backup (w&h: 1px, no padding, no border, no background) for OFF-LEFT is sufficient enough to hide the element. But it shows 1px and is otherwise the same as clip: rect(1px, 1px, 1px, 1px) so clip: rect is more elegant (if it reads on screenreaders)

I really like the clip: rect(1px, 1px, 1px, 1px) technique. Can someone test #125 with screenreaders please?

I tested #125 here http://drupal7.dev.openconcept.ca/node/1

It seemed to work with VoiceOver in Safari.

I tested the following on browsershots.org with all preselected 61 browsers.

<h2 style="position: absolute !important; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px); background-color: rgb(102, 102, 102);">
  Invisible (position: absolute !important; clip: rect(1px 1px 1px 1px); clip: rect(1px, 1px, 1px, 1px); background-color: #666;)
</h2>

All work, except the attached.

Luckily drupal doesn't support does crappy browsers :)

+++ modules/system/system-behavior.css	Mon Jun 21 12:32:59 2010
@@ -302,10 +302,11 @@
+  clip: rect(1px 1px 1px 1px);

We want a trailing inline comment on this line, specifying the shorthand browser names+versions this is for, i.e.,

/* IE6, IE7 */

(IIRC)

Looks like tests were positive, so should be RTBC afterwards.

55 critical left. Go review some!

Implemented #131

Also deleted the following comment since clip: rect will not cause a page "jump" when used on focusable elements.

Must not be used for focusable elements (such as links and form elements) as this causes issues for keyboard only or voice recognition users.

I think we got a winner :)

Are we 100% sure about the page jumping issue, I've found that one very hard to get rid off no matter what technique used (even off-left method) - just saying for documentation sake here, not that we need to fix it or anything (not sure its even really possible).

If we've nailed this solution we definitely need to talk about it and also put links to this issue thread in the code. I think most folks will look at this and wonder why we went this route.

For something that should be so simple, it's been intensely complicated - especially considering the previous two issue queues have over 200 comments each.

When using TAB to navigate the focus will always try to jump to the position of the focused element, no matter if its visible or not. With OFF-TOP this is a problem because the element is positioned verticaly outside of the viewport. I tested focusable elements hidden with clip: rect(1px, 1px, 1px, 1px) here:
http://forward-media.de/clip.php

Another solution suggested by Jonathan Neal on adaptivethemes.com blog is to make the element visible on focus:

.element-invisible:active,
.element-invisible:focus {
  position: static !important;
  clip: auto;
}

The :active is required for IE6 and IE7. This is a fast, simple solution when you need to obscure a “Skip to main content link” or an HTML5 heading. This is especially great because you can obscure any text on the page, but allow focusable text to appear when it’s appropriate (i.e. on focus).

But I dont know if (actually I don't think that) we want this kind of (for most users unexcpeted) behavior to be in core.

Example: Regular users often use TAB to navigate forms. Lets say you use element-invisible for a form element you want to hide from regular users and just expose it to users with screenreaders it makes no sense at all to show it on focus.

I think the patch is good as it is. It solves these issues with lightweight CSS
#718922: system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard
#766444: Add !important to CSS attributes of .element-invisible in system-behavior.css
and its hard to break.

Changing the Status was unintentional.

If we cannot use any of these methods to hide focusable elements, we also should stop discussing "page jumps". In this case OFF-TOP is equally good.

So we need to focus on the question if screen readers read the elements hidden with clip: rect(1px, 1px, 1px, 1px). If it works, we should go with clip: rect because its solid and lightweight CSS. Otherwise the OFF-TOP or OFF-LEFT approach with backup is the safest alternative to go.

Attached is the clip: rect patch as in #132 with restored comment

Must not be used for focusable elements (such as links and form elements) as this causes issues for keyboard only or voice recognition users.

I have tested the clip method (patch in #140) in both NVDA and Jaws 11. I tested in Firefox 3.6, IE6, 7, 8.

NVDA:
Firefox - works.
IE (all versions) - works (NVDA is not good with IE at the best of times, so I would question if anyone actually uses this combination).

Jaws 11:
Firefox - works
IE (all versions) - works. Jaws is far superior with IE than NVDA.

One thing I found with Jaws 11 is that it does smart things like skipping the header/navigation etc when you repeat visit a page, it jumps to the first h1 on the page and starts reading, quite cool (off topic...).

OFF-TOPIC: I contacted Freedom Scientific technical Support (developers of JAWS) and asked what's their oppinion about the best method to provide extra information for blind users. This their response:

It is generally not good practice to hide content from sighted users but present it for blind users, it is confusing and error prone because we try and always present what is actually visible and if you are deliberately trying to circumvent the usual visibility you will cause us great headaches. A better approach is to make your presentation work well for both sighted and blind users alike by using judicious alt tags on graphical objects which are representing buttons, correct ARIA markup on widgets you expect to act like standard Windows controls, properly marked up data tables with headers attributes or th tags, explicitly linked labels for formfields etc.

http://jaws-support-response-templates.com/?q=hide%20content

The more I think about providing content that is not available visually, the more I disagree with this practice. Quite often in my work, I come across many low-vision JAWS users. These people are sighted and will use JAWS to assist what they see on the screen. These include people with glaucoma, tunnel vision, retinitis pigmentosa, etcetera. They sit very close to the screen with their color contrast changed to very strict settings or use screen magnification software. As they navigate the Web content with their screen reader, the content on the screen will move to where the cursor has focus. When they encounter hidden content with techniques such as these, they become confused and have to spend more time orientating themselves to what is being read to them versus to what they are seeing. They deal with page-jumping all the time and just like any user, they learn to expect such behavior in common scenarios, such as hidden skip links

Focusable elements are focusable for a reason; they functionally let users and devices know where they are.

I don't pretend to have a solution to these scenarios because this is a common practice across most frameworks and the last resort to many designers and developers making last minute decisions regarding accommodating accessibility. The troubleshooting on this issue has been great with a lot of wonderful ideas and effort, but I offer this information as this shows signs to me of over accessifying an issue.

...if you are deliberately trying to circumvent the usual visibility you will cause us great headaches.

I wonder who the us is in that sentence? Is this Freedom Scientific, Freedom Scientific technical support or end users (or all three).

@veeliam- do these low sighted users have the sites CSS turned off (so the page is linear) and load their own?

Interesting discussion. @sun your link is not working?

However, we should test CLIP-RECT (patch #140) and fix this issue, especially because its a hassle to themers who want to use borders, paddings and background on their H2.

see: http://drupal.org/node/718922#comment-3093748

Crossposting. Patch #140 successfully solves issues with seven theme:
http://drupal.org/node/821646#comment-3130214

I've reviewed this patch from a themer/CSS dev vantage point and it works great. For those wanting to read the CSS 2 spec on this property, you can find that information on the W3C site. http://www.w3.org/TR/CSS2/visufx.html#clipping

I consider this RTBC from a themer's perspective.

Is there any other perspective? :P :)

Let's commit this sucker. If we need to discuss the entire .element-invisible idea and usage on its own, then this should happen in a separate issue.

Impressive issue, great collaboration. I committed the latest patch to CVS HEAD. Thanks!

That never hurts. ;-)

I was under the impression that mgifford did some testing but there is certainly more testing that can be done.

@Dries I just tested it with Safari.

This is a good (as it was what the problem was originally trying to solve). However, it would be better to have it tested by a few other screen readers as well.

I'm assuming that Everett will do this and get back to us if there are any problems with what is in core. Might be good to open a new issue if this is anything other than moving this back to fixed.

Can we assume this is fixed, been a while and certainly a lot of work is going on in various screen-readers with no new reports for a long time.

Anyone interested in #897638: Make .element-invisible work for focusable elements like links?

Just an FYI in case anyone else comes across this.
I'm working on a Blackberry focused site, and it seems some older Blackberry browsers break this technique. Specifically tested in a Blackberry 9630 simulator running Blackberry OS 5.x, but also reported from an actual Blackberry user. In this case a big black H2 "Error Message" title sits over the top of the error message, making the actual error unreadable as well as ugly.

Since I'm not aware of any Blackberry based screen readers I'm using a fix of positioning the .element-invisible off screen with top: -9999px.

I don't know how old that is and I'm pretty sure in D7 there was no explicit support required for mobile devices. But how old is this Blackberry:
http://en.wikipedia.org/wiki/BlackBerry_OS#Current_versions

There are some ideas on how to extend this that have been added here:
http://snook.ca/archives/html_and_css/hiding-content-for-accessibility

Some other enhancements are suggested here:
http://groups.drupal.org/node/120224

There probably should be a new thread opened for this in D8, This should have better mobile support, but not sure it will go back to the user whose machine you were testing on.

Well Blackberry OS 6.0 and up is based on webkit and works fine with this technique. So it's any Blackberry that can't be, or hasn't been upgraded to 6.0.

Snook's suggestion would lead to a 1px element on screen on the BB, that seems like an acceptable compromise.

His suggestion is (just bringing it over here for reference):

.element-invisible {
  position: absolute !important;
  height: 1px; width: 1px; 
  overflow: hidden;
  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px);
}

And ya, 1px seems reasonable.

NOTE: I've posted a D8 followup thread http://drupal.org/node/1158426

Creating a tag to gather up old information about our approach to the .visually-hidden CSS class. We may need to modernize this, so this tag is to help me review the history.