'display: none' causes problems for screenreaders

I'm not so firm in screen readers, but can you disable the 'page style view' in your browser? This should fix the problem, because the collapsible page sections are defined in the style sheet.

Unrelated to this bug specifically, I'd like to thank dfserra for checking Drupal and entering an issue on this subject. I'm not sure how many of the users of mysite are using screen readers - but I do believe that Drupal currently does strive to be accessible and should continue to do so.

dfserra - please continue to check Drupal for accessibility and please let the community know what way we can help you do this. I think it would be great to have a set of handbook pages that give guidance to core developers and (perhaps more importantly) theme and module developers on how to best make pages accessible to screen readers. If there is anything I can do, please use my contact form to let me know http://drupal.org/user/36762/contact

I'm not sure what Drupal can do here? We are really being a good citizen as far as I can tell. Perhaps disable javascript in your browser? Then Drupal will show everything expanded.

FYI, 'occult' probably means 'hidden' in this issue.

Not sure if a good approach would be to use the title argument of the fieldset to, when javascript is enabled and it is a collapsible element, include a message of the type "click here to expand/collapse this field set" ?

Maybe that helps screen readers to help their users figure out what to do?

The problem is this line in drupal.css

html.js fieldset.collapsed * {
  display: none;
}

Display: none takes all the elements out of the DOM so a screenreader cannot access them, and no current screenreader can cope with refreshing the DOM tree. A more accessible solution would be something like this:

html.js fieldset.collapsed * {
text-indent: -9999em;
height: 0px;
line-height: 0px;
}

That will provide the save visual effect, but will be accessible to screenreader and other alternative technology users.

Bumping to 4.7.2. This seems worthy of fixing. Could one of the themer-types take a look?

And a more descriptive component/title

vigo's summation of the problem is correct, though I think a slight improvement to the css technique used to collapse the fieldset would be the following.

html.js fieldset.collapsed * {
    position: absolute;
    top: -1000em;
    left: -1000em;
}

I've had issues using text-indent to hide content on several sites before (specifically with IE 5 and 5.5), whereas positioning the content off screen seems to be the "best practice" method for accessibly hiding content.

I want to see this fixed for 4.7.3.

neither #6 nor #9 work for a regular browser (konqueror 3.4).
With the #9 approach, the title on which you click to 'open' the form block disappears together with its content (i.e. there is no block title to click on to open the block).
With #6, the content is still displayed, but pushed to the far right and it looks quite ugly but still useable ;)

I can't think of another solution.

We need to find a solution that works for everybody first, and then ask dfserra to test on a screen reader.
But until then, it's enough to have a regular browser to test and help this issue to move towards the appropriate solution.

This one seems to work for me, using ejort's approach, but replacing html.js fieldset.collapsed * by html.js fieldset.collapsed div.form-item.

Still using ejort's approach. This patch is probably better than the previous one.

http://drupal.org/user/56532/contact dfserra is not accepting emails, and he is probably not following this issue.
Once it is sure that the proposed patch doesn't have any adverse effect for regular browsers, could one site admin contact dfserra directly so that he can test the proposed changes in his screen reader?

Display: none takes all the elements out of the DOM so a screenreader cannot access them, and no current screenreader can cope with refreshing the DOM tree. A more accessible solution would be something like this:

This is not true. Display: none elements stay in the DOM just fine. Otherwise, we would not be able to submit forms with collapsed sections. If a screenreader has problems with this, then it is simply hardcoded to ignore display: none elements. That's all.

Now, by moving fieldset contents off screen rather than hiding them, we do clutter up the page structure with convoluted styles. This problem is only going to get worse in the future.

Given the amount of work we invest in making our Javascript features degrade gracefully, I'm tempted to say that those using a screenreader should turn Javascript off. This is a common piece advice on the net from other JS/Accessibility discussions as well.

There is another option though, a W3 standard called DHTML accessibility, supported by Firefox 1.5. It fits in our project goal to support emerging standards:
http://developer.mozilla.org/en/docs/Accessible_DHTML

We could make each collapsible fieldset a wai:treeitem, with expandable = true and expanded = true/false based on the .collapsed class. Those using a recent screenreader with support for this can take advantage of JS features. Others have to live without.
http://www.mozilla.org/access/dhtml/tree

Can't we simply add that title attribute suggested in #4 and #5?

Is there any authoritative source (for example W3C) saying this CSS hiding without display: none stuff is actually good?

isn't using visibility: hidden; an option for the usage in our CSS?

must read:
http://css-discuss.incutio.com/?page=ScreenreaderVisibility

I thought we could use something like:
<style type="text/css" media="screen">@import "/misc/drupal-screenreader.css";</style>
but it seems the media type 'screenreader' has not yet been implemented, or only very recently:
http://www.w3.org/TR/2004/WD-css3-reader-20040224/
http://www.webaim.org/discussion/mail_message.php?id=4357

I am surprised.

also relevant:
http://www.accessifyforum.com/viewtopic.php?p=700
http://eleaston.com/bob/screenreader-visibility.html

Thanks for the informative links. It seems their use case is showing extra information, such as skip navigation links, to screen readers only.

I'd like to know what the support for showing the hidden elements once the fieldset label is clicked is in screen readers. It seems like it does work, as suggested by the original description here. If they do, then we already have the same functionality for screen readers as visual browsers.

However, this functionality isn't as obvious without the disclosure arrows seen in visual browsers. Maybe they should be real images with alt text instead of CSS backgrounds. We may want to put in the title as suggested earlier too.

I am not an accessibility expert, so go ahead and tell me if my ideas are wrong.

Drumm: the way I understand it, the problem is not that the collapsible fieldsets don't work, but that there is no notification to blind users what happened after they click a link. They have to step through the document and notice that something new appeared. That's why I was interested in the DHTML accessibility stuff, because lets you assign semantics to DHTML, which a screenreader can use.

Perhaps the best option is to add a title attribute to the collapsible fieldset links which says something like "click to expand this section". I'd much prefer this to image alt text for the arrow (otherwise themes would not be able to modify it through CSS).

I agree that simply using a CSS hack to make all fieldset contents visible to screenreaders is really ugly and really a non-solution: you are simply blasting all the hidden content to impaired users. Usually, blind users have an even bigger problem already sorting the wheat from the chaff.

Plus, CSS hacks such as left: -1000em; tend to only be used for things like sIFR, where you replace normal content with a richer equivalent (and then only at a very small scale).

killes wanted this to be out with 4.7.3, so I'm pushing this to critical so it can get some attention before the 5.0 final release.

There is no time for 5.0 to significantly alter the collapsible fieldsets. But, I think a solution such as "left: -1000em" is not good for Drupal, because we are talking about significant parts of the page here. It could slow down the page a bit to not set them to display: none. It would also complicate the JS code quite a bit.

For now, people with screenreaders can just disable JS in Drupal. They have very little benefit from it. I can't imagine you could even easily use e.g; autocomplete with a screen reader, and all key features (e.g. update.php and upload) work fine without it.

I can't believe this hasn't been fixed within the last YEAR!!!

We can't expect users of screenreaders to disable JS on Drupal sites. There are other sites that don't degrade that gracefully, so JS is needed there to use basic functionality. Instead, we need to elaborate on this!

I mark this critical, even though we don't have a working patch.
Please don't demote this just because it's too late. We are striving to be the most accessible CMS, and this seems to be unacceptable for screenreaders.
In case this is fixed - I can't test it right now - it is fixed. Otherwise this is rigtly another big thing to get fixed before final release.

Sorry.

A couple of articles that I believe haven't been mentioned yet:

http://juicystudio.com/article/screen-readers-display-none.php
http://juicystudio.com/article/making-ajax-work-with-screen-readers.php

Also interesting from the same website:

http://juicystudio.com/article/choosing-an-accessible-cms.php

Here's another interesting question: do most screen readers support the CSS aural media type? I admit that I don't know, but this would be an easy fix with either an aural-media stylesheet, or even a CSS block targeted only at the aural media type in a stylesheet that is otherwise included in all media types by default.

To me this seems crazy, why does a browser be it a screenreader or not , enable JS it can't cope with?

I believe a screen reader is not a "browser", but "something else" installed on the personal computer that is able to assist whatever you do, not just internet related.

http://en.wikipedia.org/wiki/Screen_reader

What the articles I posted before analize the way screen readers behave with the content on the browser, and what can be done to help these things understand what happens, specially when content changes, etc.

I guess this issue is too complex for D6 though.

Steven's approach to include at least partial ARIA support (at that time called "Accessible DHTML") is definitely the most promising.
Valuable information about this can be found on:

• http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Appl...
• http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Appl...
• http://www.w3.org/TR/wai-aria-roadmap/

However, for most of us this is pretty new stuff. So it would be great, if someone with some ARIA experience would speak up and give us an idea how we can implement a subset that does make the JS in Drupal 6 compatible with screenreaders.

Also, it would be cool to get some info, whether the problem still exists (which is to be expected), and whether it has become worse, now that we are having more JS code than we had 18 months ago. A comprehensive D6 usability report for screen readers wouldn't be too bad, if possible with test users that are not too familiar with Drupal. I know this would be a lot of work within some days, but focused interest groups are usually rather easy to mobilize, so maybe this is within reach.

Didn't mean to undo your changes.
However, some kind of explanation, why this is moved to D7 and demoted, would be great.
Bugs are usually not moved to the next major release, but are fixed in subsequent minor releases.
If we don't care about this for one more year, we can forget about our good accessibility reputation IMHO.
I move this back to D6. Now it is no more critical, so it doesn't block the the 6.0 release.

edit: crossed again... was already demoted in #34.

@Pancho - the 7.x was anticipatory that this will not get fixed before 6.x is released, in which case all bug fixes go against HEAD first before being backported (if appropriate).

It is regrettable that this didn't get fixed, but since there is not even the prospect of a acceptable patch, it won't make it for D6.

Another year has almost gone by. Who has the ARIA experience to get the answers that are needed to settle on a patch for D7? I don't, but want to see that this isn't forgotten for another year and another major release.

Nothing is going into any Drupal release until someone creates a patch, it gets reviewed, and it gets marked ready to be committed. If 1/50th of the people complaining that this isn't fixed yet actually put some energy into reading the copious documentation cross-linked here and creating said patch, this probably would've made it into Drupal 4.7.

There are a lot of options displayed in this thread. I've tried to get some more input on the best choice here - http://groups.drupal.org/node/18563

Will work on putting out a patch for Drupal 7 when we have a better sense of the implications of some of these options.

Awesome! Thanks, mgifford! :)

Subscribing—will leave the implementation to mgifford at this stage ;) but want to come back to some of these links...

subscribing
+1 and thanks to mgifford for offering to patch

Presently running into some difficulties with the collapse.js file and how the collapsible field sets are managed. display:none; is used in the code that controls the expansion of the Advanced search as well as all of the editing forms that Drupal uses.

More details of this issue are here:
http://groups.drupal.org/node/18563#comment-64332

There are places where you want a piece of code to be hidden to everyone (screen readers, sighted users and even search engines). However, most of the time it's a matter of just removing the visual clutter from the screen and reducing the number of options that present themselves to sighted users at any one time.

height:0px; or something like that, in combination with overflow:hidden; should be a proper replacement of display:none;

This is a bit of a bigger patch that does need a bit of work. I've posted about it in the accessibility group.

It's a bit bigger because some of the other patches I've been working on for these D7 accessibility enhancements are there: Blank Labels, Search Form, and a theme change.

OpenID isn't working quite right. It uses a similar but not identical accordion tool. It almost looks, but the form to enter the ID isn't displayed.

I also just noticed that the Submit / Preview buttons tend to float up in the edit pages in Firefox. I had assumed that this would work just as well in the advanced search as it does in other areas of the site. Apparently this touches on other areas too.

However, it is much more accessible with these enhancements. I do need some help in nailing down and testing this a bit more though. The collapsible fields are used more extensively than they were back in 2006 (from my recollection).

Please test out this patch and provide feedback & enhancements.

I've filed a new patch (with issues specifically with openid) here - http://drupal.org/node/387592

I've revised the earlier patch I included here and removed the the section for openid (as well as label, search & more accessible lists through proper use of headers)

Mike

Few related issues that are using offscreen css here:
http://drupal.org/node/364629

I'm wondering now if it would be useful to have offline css for block & non-block elements.

Lots of different solutions, but which is the most flexible and standards compliant?

Ok, yes, I am confused by this message result as are others - http://drupal.org/node/371309

I went to check out the test results - http://testing.drupal.org/pifr/file/1/display_none_plus3.patch

All were positive. However I still get "Result Failed: Failed to install HEAD."

I don't see what's wrong with the patch - http://drupal.org/files/issues/display_none_plus3.patch

I've applied others without problem. Is it with the bot or my code?

I think I remember reading somewhere that JavaScript patches can fail testing when there are otherwise no problems.

Dave

- block.css:
+ /* hiding & removing for screen readers */
Wrong description: You are not "removing" anything, you are just hiding it.
Comments should start with a Capital

- color.css
+/* hiding & removing for screen readers */
Same here...

- profile.css:
Same here...

- system.css:
+/* display: inline; - removed */
Then, remove it from your files so it does not appear in the patch...

+/* Temporarily remove content, but make visible to screen readers */
+.offscreen {
+ position: absolute;
+ left: -999em;
+ width: 1em;
+ overflow: hidden;
+}
+
You are not removing anything, only hiding it.
You are adding a CSS-class .offscreen here, but where is this being used? It is not a standard drupal class AFAIK, and your patch is not making use of it..

Every comment you added in your CSS isn't starting with a Capital, which is a good habit of doing. We do this everywhere else.

Furthermore, nice patch!

Good point on clarifying the CSS comments & the proper use of comments in Drupal. I think these are more clear:

/* Hide content for all users through css */

/* Hide content for sighted users, while leaving it visible to screen readers, ie. collapsible fields */

Given the number of times that display: none; is used (legitimately), I think there's some room for consolidation of the CSS.

I'm actually promoting this solution now (rather than left: -999em; as I'd really rather not introduce more problems for bidirectional sites):

+/* Hide content for sighted users, while leaving it visible to screen readers, ie. collapsible fields */
+ .offscreen, .invisible {
+ height:0px; overflow: hidden;
+}

However there are a great number of places we'd like to use it here:
http://drupal.org/node/364629

There are a lot of issues that are tied to having a proper way to deal things like expandable fields. This would also help with things like:
http://drupal.org/node/364219

Mike

Again:
-system.css:
- display: inline;
+/* display: inline; - removed */
Remove that line, as it is commented out and has absolutely no additional value to keep it commented in the CSS-file;

+/* Hide content for sighted users, while leaving it visible to screen readers, ie. collapsible fields */
+ .offscreen, .invisible {
+ height:0px; overflow: hidden;
+}

Do this:
+/* Hide content for sighted users, while leaving it visible to screen readers, ie. collapsible fields */
+ .offscreen, .invisible {
+ height: 0;
+ overflow: hidden;
+}

No matter if the '0' is in em, px, or whatever. it keeps being zero, and is handled like that. The px, em, whatever-part is unneccesary.
We have the habit of preceding every CSS-property within a class/id with 2 spaces. keep this consistent please.

please update your patch, and i'll review it again.. this needs fixing asap, so we can build upon this.

hello.

first let me thank everybody for their time insuring that this issue, and other related accessibility issues were fixed. however, I am not too sure that we have a problem here anymore. the issue was that 'display: none' causes problems for screenreaders, right? I am a user of most of those screen readers and rely on them for things ranging from browsing the net to developing sites using drupal. collapsable fields are a blessing to my experience because they really lessen the clutter in the pages. when they were first introduced I had a trouble with them because I didn't know that these are links, once clicked, the related section would get expanded. the original issue was posted 3 years ago, when screen readers were not as advanced as they are today. additionally we didn't hear from the poster since July 2006. I would be happy to test with my screen readers if there were a problem, but the way I see it is that collapsable fields have come to surve us quite well.

any thoughts?

It's not a problem with the conception of collapsible fields in principal, but practice. We haven't been arguing to eliminate the expandable fields, just to replace display:none; which is a problem for many screen readers from what I have been told repeatedly. Newer screen readers may not have a problem with it if they are configured properly, but this is the first time I've heard that this might be an option.

There are a number of threads in the accessibility group that address this - http://groups.drupal.org/node/18563

I've also set up a D7 sandbox with the alternate I am proposing - http://drupal7.dev.openconcept.ca/

Expandable fields do work here. They just don't use display:none;

Mike

Thanks again for your attention here.

All good points. I am turning this back to needs review rather than by design. Think there's enough evidence that this is an outstanding bug that has several ways to address, but is still an issue.

Hope this is sufficient.

mgifford, I visited the sandbox site but I cant find the proposed alternative, I'd like to check it out as I am working on the fieldset issue as well. Cheers.

setting status

Easiest example is - http://drupal7.dev.openconcept.ca/search

But you can also sign up for an account to see it used in other content creation forms. I've just given you admin access.

Mike

Thanks mike, looks good and is basically the same approach. Only thing is the display: none on the submit buttons need dealing with.

Is there a separate issue for this or is this the right place to follow along?

There are a bunch of accessibility issues with D7 identified here - http://drupal.org/node/364629

But don't know about this issue with the form buttons.

Also not sure if it is better to attach it here or set up a new issue for it. Generally I think smaller patches have a better chance getting accepted as they are easier to review.

Mike

hi.

the site at http://drupal7.dev.openconcept.ca/search is a very good example to illustrate why I am afraid that whatever approach is taken to address this issue might bring more harm than good. I remember one of the drupalers saying that "blind people already have hard time distinguishing between the wheat and the cloth" because what he says accurately describes the situation. I prefer to read less on my way to find the relevant section of the page. in the example above I am forced to read all the fields in the advanced search form. in the standard way I will only find a link labled "advanced form" which will expand the form if clicked.

the point is on our way to solving the problem we may produce more clutter, something blind people already have hard time fighting.

First, I am not blind. However I have been relentlessly testing with various techniques and using Jaws and NVDA and, after many hours of testing, I have to say that, for the collapsible fieldset issue, I agree with mohammed76. Its simply far better if display:none is used. Its "hides" clutter from the screen reader.

I'm all for establishing a standard set of hide/remove classes, and we certainly need some more review of the various places where Drupal uses display:none to be sure that is, or is not the desired behaviour.

I'm not blind either. I use the Firefox Fangs module to emulate Jaws.

Collapsible fieldsets are used to help de-clutter the screen for sure, and with a screen reader it is even more important to ensure that what is presented to the user is as clear and concise as possible. However, it is also removing functionality. Nobody using a screen reader can access the advanced search functionality of any Drupal site because of the use of display:none; Now, most of the time the default search is sufficient, but there are a number of times where you may want to restrict a search to a particular content type.

It's also much bigger than just the search page. Collapsible fieldsets are used throughout the admin interface and simply removing a users ability to access these makes their ability to edit/add to the content of a Drupal site much less powerful. A blind person cannot at the moment effectively add content to a Drupal site.

Totally in favour of having one or even more than one approach to hiding content and educating developers and designers about when to use these central CSS classes. I think that it should be tied to modules/system/system.css and I've recommended a number of changes in the above patch. The most central part of it is here though:

/*
** Accessible Hiding/Offscreen  
*/

/* Hide content for all users through css */
.hide {
  display: none;
  visibility: hidden;
}

/* Hide content for sighted users, while leaving it visible to screen readers, ie. collapsible fields */
.offscreen, .invisible {
  height:0; 
  overflow: hidden; 
}

Now I've used height:0; overflow: hidden;

Just for clarification, the thoughts on height:0px; overflow: hidden;

Came from these discussions:
http://drupal.org/node/386462#comment-1306896
http://groups.drupal.org/node/18563#comment-67796

It's not the popular approach, most folks tend to go for -
http://groups.drupal.org/node/20584

v (William Lawrence) prefers using one of these, depending on the context:
text-indent: -9999em;
position: absolute; left: -1000em;

I'm not opposed to introducing a couple of CSS classes to provide different ways to hide different types of text, but it does need to be clearly outlined why you would want to use each different type.

If we don't provide an alternate way to access the functionality via screen reader it isn't acceptable not to show it. The person (dfserra) who started this thread on April 15, 2006 wanted access to information that was hidden from them and I don't see why it's been so difficult to provide them with access.

Mike

hello.

Mike just made 2 big statements that are plain wrong:

"Nobody using a screen reader can
access the advanced search functionality of any Drupal site". totally wrong. I used it all the time on drupal.org when it was available, and I use it on mnay drupal powered sites successfully with either jaws or NVDA.

"A blind person cannot at the moment effectively add content to
a Drupal site."

I also don't know how you came up with such a fact. I have been administering drupal websites since the days of 4.7 all with the aid of my screen readers.

I would like to emphasise again, that anything that makes the clutter less is far more appreciated as the web becomes more and more complex.

and second the original post was made very long ago when screen readers were not as advanced as they are today.

get yourself a copy of NVDA and test for yourself.

Mike, with all due respect:

Nobody using a screen reader can access the advanced search functionality of any Drupal site because of the use of display:none;

.

Is actually not right, I can access the Advanced search feature of a Drupal site without any issue at all, in fact NVDA does a fine job of telling me the Advanced Search legend link is a link and synthesising all the features, lables and so on in a very clear a precise way.

@mohammed76, do you have the ability to install a Drupal 7 site to play around with it? I'd be mighty curious what Vertical Tabs patch has done to our accessibility on node forms. Based on your statements here, I fear that we might've inadvertently made it worse. :(

@webchick, yes, I do. I will do this in a minute and report back my findings. I think you want me to test how editing and posting forms has become? like specifying path, edit publishing options, etc?

@webchick - the problem with the new vertical tabs is the tab order is all fecked up. The screen reader has no problem with the links and form elements its just the navigation of it is crazy. I should have reported this earlier, my bad, but I wanted to at least get some sort of patch ready to improve the tab order.

Just test it for yourself by tabbing through (no focus styles either...), you will see it jumps from tab to tab, instead of from tab to form element within a tab, you have to tab all the way through, then back out, down, through, back out etc etc, its very unintuitive and real PITA.

@mohammed76: Yes, that's it exactly. Thank you SO much! Also, please report whatever you find to a separate issue (cross-linked from here) so we can get to work on fixing it without starting 70+ replies in. :)

@jmburnz: Well, that's at least something relatively easy to fix (or so I think... ;))

@Webchick, done. http://drupal.org/node/467296

@jmburnz your discription of the difficulty is accurate.

however, the biggest accessibility threat that needs to be addressed before d7 is imho http://drupal.org/node/448292

mohammed76 - I could very well be way wrong on this. In which case I apologize. I've been using Fangs and am a Mac user so NVDA isn't easy for me to replicate exactly. Orca is another option for Linux which would likely be easier. Never the less, it's not the same as running older versions of Jaws from what I hear.

Given the state of documentation on the web about display:none (which is largely what I have been basing my comments on), I do think we do need to remove it where possible.

Going on references like:
http://www.w3.org/TR/WCAG20-GENERAL/C7.html

"Note that the technique does not use visibility:hidden or display:none properties, since these can have the unintentional effect of hiding the text from assistive technology in addition to preventing on-screen display."

Seems like it is worth eliminating the use of it where we can. However, maybe the browsers have advanced more than the documentation.

Mike

Thanks jmburnz. You and mohammed76 have done more testing on this with screen-readers than I have. I've been leaning on the documentation and what I've heard from a few users.

I would like NVDA to be the default screen reader because it is open source, and it may work better than Jaws does, which would be terrific! I do wonder though if we're going to run into the same issue we do with IE. We all know Firefox is a better browser, it is slowly gaining market share, but a significant number of folks are still using the buggy non-standards compliant browser that came with their OS.

Mind you D7 isn't really going to be used by many production sites till the fall of 2010 I expect, so this may not be a big concern.

I think that there is agreement about putting in an off-screen option however, and adding it to modules/system/system.css

I've proposed these:

.remove {
display: none;
visibility: hidden;
}
.invisible {
height:0;
overflow: hidden;
}
.offscreen {
position: absolute;
left: -999em;
width: 1em;
overflow: hidden;
}

I also didn’t set up a .hide class, but it would be the same as the .remove class.

hello Mike.

I very much appreciate the effort you put into the accessibility of Drupal. it's just that experience proves documentation to be wrong. you seem to be ok with this, of course. all we want to say, is that we want to insure that we don't want to end up making the system less usable than before, like if we make the screen more cluttered. However, feel free to nudge me if something needs testing by an actual user of screen readers, and together we will insure that this never happens.

I suggest that we commit the off-screen classes to system.css right away. Meanwhile, we can proceed with these valuable conversations about when they should or should not be applied.

The classes are important to have in system.css so that all core developers, themers, and module developers can make use of these techniques when appropriate. There are lots of cases where we want these styles in core so that as a community we can make a conscious choice between 'display: none' and off-screen in each case. We can begin to write guidelines and theming documentation about which techniques are most appropriate in different scenarios.

Thanks to mohammed76 and everyone who is contributing this knowledge.

temporarily critical, until initial patch has been committed.

Looks good to me!

Can we identify a list of use cases for these classes, places in the D7 CSS where these would be useful and/or replace current implementations. If this already exists can someone point me in the right direction, thanks.

I am not against these changes being committed per se. However, I think it is important to understand what is being achieved here, which is now much more of an edge case than when the OP was created over three years ago. The original post was in essence asking for a change in Drupal's CSS to compensate for a flaw in the screen readers of the time i.e. that they didn't handle display:none correctly when it was used on collapsed fieldsets. However, recent posts have confirmed that this is now a non-issue—screen readers now handle this correctly. Furthermore, it would be a major regression to apply the proposed patch to currently collapsed fieldsets, because it would mean that they would every time be read out in full to people using screen readers, regardless of whether they actually wished to review the hidden content. For the same reason that we use display:none for fully sighted users (to reduce initial information overload when approaching the page) we of course want display:none to likewise apply to screen reader users... in fact, more so since information overload is a more prominent concern when accessing websites in this way.

So with screen readers now working as they should (compared to 2006), the only use case for the proposed modification would appear to be when we have extra information that we wish to present only to people using screen readers, that is always hidden from other users. This might, for instance, be additional explanatory text or extra navigation shortcuts. However, as far as I am aware there is minimal content of this nature in Drupal at present, and the content that is there (e.g. the "Skip to Navigation" link) is also presumably working correctly or there would be an issue about it. Has anyone looked at how that is already being achieved?

So I want to gently suggest this raises the possible question as to whether the current patch is actually required at all. It seems a pity that so much work has been put into this if it were to all be for nothing, but unfortunately I think that perhaps too much focus was given to a solution without ongoing clarification of what the original issue was and whether it actually still existed. Just my 2c. And I could be wrong. But I think the possibility needs to be considered this time.

Friendly :)

Although, this I suppose is fairly compelling—and these are after all small changes:

The classes are important to have in system.css so that all core developers, themers, and module developers can make use of these techniques when appropriate. There are lots of cases where we want these styles in core so that as a community we can make a conscious choice between 'display: none' and off-screen in each case. We can begin to write guidelines and theming documentation about which techniques are most appropriate in different scenarios.

I would just worry that making off-screen a visible option for instance (pun slightly intended) might increase the possibility that it is used inappropriately, and thus inadvertently causes screen-reader problems.

If these classes are being implemented specifically for accessibility reasons, why not use CSS class names that describe the intended result, rather than the particular implementation. Thus "hidden" is good and should be kept (applies across modalities and is also widely used in the design community) but I would drop "invisible" and "offscreen" in favour of "screenreader-only" or similar.

(Note: my long period before posting my edit of this means that jmburnz's post below was actually before my last two paragraphs re "hidden" etc... just in case it makes more sense of the chronology.)

@dbabbage - well yeah, I think we really need more testing and feedback on the whole collapsible fieldsets issue, however I have done some pretty extensive tests with Jaws and NVDA and it certainly makes sense to me to keep the status quo (display: none).

The current patch proposes adding a few new classes to Drupal - .remove, .invisible and .offscreen. I am currently going through all of D7's code to root out where these might make sense to be used, if they can be used and any other possible use cases that might crop up. Its certainly not a simple matter of replacing display: none as this would create some serious usability issues.

There are no Skip to content type links in any core D7 themes. Today I wrote a skip link implementation for Acquia Marina which was modified and committed almost immediately (its basically a core theme for Acquia Drupal). I have a similar imlementation for Garland almost ready to burn as well. For the default page.tpl.php I am of the pretty firm opinion that we should show the link in and not hide it by default, but offer some simple methods to do so.

Frankly this thread is gone way off track and should probably be deprecated in favour of a few new issues that have sprung forth from it.

@alexanderpas - setting back to normal, afaikt we haven't even established a strong use case for these classes and while a good idea there's no point adding classes to system.css unless there's something that is going to use them. We may just as well work though each situation one by one and build the best solution on a case by case basis, such as by modifying an existing selector.

I think we need to move this feature request for new classes in core to a new issue, this thread is so long now.

Ah, probably the skip to navigation link I was referring to is just in the Zen base theme then. (Note it is "Skip to navigation" not "Skip to content" because in a properly arranged HTML page the content comes first, the navigation comes at the end, and then you use CSS to display the content more prominently... for reasons of good accessibility of course.)

@dbabbage thank you. this is what I was trying to say over and over. let's identify use cases and test the current state with current screen readers. I have access to all of them, so I am more than ready to help. just nudge me when something needs testing.

@jmburnz, the "skip to content" or "skip to navigation" feature is very useful indeed. I wish you provided issue numbers. yet, this is really getting OT big time. thanks all for the good efforts.

because in a properly arranged HTML page the content comes first, the navigation comes at the end, and then you use CSS to display the content more prominently... for reasons of good accessibility of course.

In some cases, I'd agree with you, but it's not always the case that navigation should come at the end of the page.

For example, in some types of sites - shopping, to take the first example that springs to mind - the user is more likely to want to search or navigate first, rather than read the home page which is different default behaviour from a blog or a news site where they might want to read content first, then navigate to other content.

Page structure and order should be decided by the content and the expected/desired default user behaviour, and any accessibility features or enhancements should be based on that, taking into account any specific needs. With good structure and careful use of alternatives where necessary, it should be easy for any user to get at what they want, however they want to get there.

Forcing content into a set structure/order might actually lead to a lesser user experience for everyone, and nobody wants that.

There have been a few requests for this, so I've closed this issue and opened up a new one here - http://drupal.org/node/473396

Hope this fresh start will allow us to move forward on a solution.

Mike