.element-invisible class does not work properly in Chrome and Safari for inline elements. It hides inline element and parent inline element with background image.

For example next html is correct in all browsers except Chrome and Safari. Chrome and Safari show only one image but should two.

<html><head>
<style type="text/css">
  .element-invisible {
    clip: rect(1px, 1px, 1px, 1px);
    position: absolute !important;
  }

  .element-hidden {
    display: none;
  }
  li {
    display: inline;
    margin: 7px;
  }
  a {
    padding-left: 16px;
    background-image: url(data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7);
    background-position: left center;
    background-repeat: no-repeat;
  }
</style>
</head>
<body>

<ul>
<li class="menu-login"><a href="#"><span class="element-invisible">Log in</span></a></li>
<li class="menu-logout"><a href="#"><span class="element-hidden">Log out</span></a></li>
</ul>

</body>

AlexR

D7 Note: See Theming Guide Here: http://drupal.org/update/themes/6/7#element-hidden

This is in response to multiple calls to depreciate this long issue on problems with the CSS - display:none; - http://drupal.org/node/58941

The idea here is to pull out which reference and proceed with a fresher start.

Just to provide some use cases of places where one might want to hide or remove content (or hide it), make it invisible (to sighted users) or just push it off the browser's screen, I've put together this list (please add/comment on the use cases):

All ordered lists (all drupal menu's) should be preceded by an H2 tag for WCAG 2.0 compliance:
http://drupal.org/node/364219

"Skip to main content" should be hidden until it receives focus:
http://drupal.org/node/386462

There's the accordion code that's in the search fields, but also in almost all default forms for content creation. Most of this thread has been addressing this use of display:none but there's also a slightly different set of CSS used to do this in OpenID:
http://drupal.org/node/387592

Sites that want to be WCAG 2.0 compliant will need to change auto-generated "read more" links that have titles hidden:
http://groups.drupal.org/node/17627

Think this is the list of links/issues/problems that I know about that are related to this issue.

We can bring over the appropriate code when we know the use cases we want to apply it to.

Mike

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jeff Burnz’s picture

Issue tags: +Accessibility

Tagging.

annmcmeekin’s picture

I've given this what could possibly be deemed way too much thought over the last few days, going over everything I could think of to see if there was a way to a bullet-proof system-wide approach to hiding and showing content.

I started by coming up with a list of reasons I could think of why anyone would want to hide content. Then I thought about the desired behaviour and thought about and researched the preferred technique for achieving that behaviour (in case I'd missed a ground-breaking new technique). Then I tried putting all that together and see if anything was left over.

Here's what I've got so far. Please feel free to add any use cases I may have missed or chip in with amendments to the suggested CSS/code. I've tried to read all the various threads on these issues and I will hold my hands up to not being completely up to speed with the inner workings of drupal so I may have missed something specific to the way drupal does things.

1. Content is initially hidden from view but becomes visible on focus.

Use case(s): Skip links

Technique: Default link style has it being displayed outside of the viewport. Focus state brings it into view in a predictable position.

Suggested CSS: http://drupal.org/node/386462#comment-1624294

Potential issues: May require theme specific amendments. Could the suggested CSS be made more generic? Would themers know/bother to specify appropriate styles for it if it isn't styled already?

2. Content is hidden from view but is available to screen readers and when CSS is not in use.

Use case(s):

Providing additional section/area headings
Ensuring form fields have labels (e.g., multi-part telephone number fields)
Providing additional information specifically for screen reader users (e.g., expanding links to provide sufficient information when taken out of context).

Technique: Displayed outside of the viewport. Off-top method allows for use in sites which display content Right to Left or Bi-Directional.

Example CSS:

.invisible /* not visible in page but available to screen readers / not to be used for links */ {
  height: 1px;
  overflow: hidden;
  position: absolute;
  top: -9999em;
}

3. Content is temporarily hidden from view but is available on demand

Use case(s):

Nested list navigation menus
Forms with many sections

Suggested CSS:

.collapse .hide {
  display: none;
}

.expand .show {
  display: block;
}

Potential issues: may require additional CSS depending on context.

Ann

Jeff Burnz’s picture

You have certainly put a lot of thought into this, so I will try to answer your questions and suggestions with the same depth of thought. I would first add a caveat; that while I have a strong personal interest in accessibility I am by no means an expert (one day, maybe) but I am an expert in CSS and Drupal theming. So while I don't know all the use cases and pitfalls etc, if one is presented to me I can find the solution.

Ok, some discotera.

1. Content is initially hidden from view but becomes visible on focus.

Its too difficult to build one generic solution for this. The use cases are varied and often unique. For example skip links in Garland demand the sort of technique I presented here http://drupal.org/node/386462#comment-1624294 because of the way the Garland theme is built. There are other situations where you might need a different technique, for example when the position of the focused text is very important, such as like a hover tool-tip-like effect for revealing additional information.

That said, we could provide for generic examples that would work out-of-the-box but require styling adjustments. That is OK—themers have to do this anyway.

In any case we most certainly need to highlight the requirement for styling :focus and not doing :focus {outline: 0;} without additional styles.

2. Content is hidden from view but is available to screen readers

This is most certainly more strait forward. Personally I am testing a non-positioning technique and am yet to run into problems:

.invisible {
  height: 0;
  overflow: hidden;
}

We can provide both positioning technique and non-positioning technique. Again themers may need to make adjustments to their themes but this is par for the course.

3. Content is temporarily hidden from view but is available on demand

Here we mainly rely on jQuery to do the heavy lifting. The way functions such as hide() work is by writing inline style declarations i.e. style="display: none;" to override display: block in the stylesheet. I am rather of the opinion that if we should find problems with the way jQuery is working, we should approach jQuery and seek solutions with them, simply because they themselves are working on making jQuery more accessible.

There are situations were jQuery merely usees addClass to inject a class with styles attached, for example the block configuration page. In empty block regions the message "No blocks in this region" appears. When a block is moved to a region the message is hidden with display: none - the class used to hide this message is:

block.css line 10
  #blocks tr.region-populated { 
  display:none;
}

IMO this is a clear cut case where we can use a generic class instead of the unique region-populated class, although we need to be aware that the semantics change and that could be a point of argument... oh we love to argue:)

annmcmeekin’s picture

Thanks so much for your thoughtful response jmburnz, and forgive me if I ask what might seem like lots of stupid questions, I'm still trying to get my head around everything (or, for that matter, anything) drupal.

Accessibility's my thing, and I've got a bit of game when it comes to CSS but I wouldn't class myself as an expert. I'm hoping that I can learn more about drupal and share what I know along the way to making drupal even more awesome than it undoubtedly is. So if you (and everyone else) are happy to try and find solutions, I'm happy to provide the use-cases and pitfalls.

Anyway, in response to some of the points you've raised...

1. Content is initially hidden from view but becomes visible on focus.

I didn't actually think that there would be a one size fits all CSS solution for this, because it so much depends on the look and feel of the site if you want to avoid that horrible "stuck on at the last minute" eye-poking awfulness which has historically got accessibility it's boring and ugly rap (which I'm on a bit of a mission to try and change, but that's a whole other kettle of fish).

Forgive the stupid questions, but,

1. would it be possible/a total pain to provide a patch which sensitively includes this for at least the core themes (are there many? is patching even possible? am i crazy?), to show how this could be done?
2. what would be the best way of letting themers know that stuff like this needs careful attention?

2. Content is hidden from view but is available to screen readers

Unfortunately, it seems that the non-positioning technique of:

.invisible {
  height: 0;
  overflow: hidden;
}

can cause problems for some screen readers[1] and although it may be something which newer versions of screen readers deal differently with, there are still a whole lot of people who don't, won't or can't upgrade their screen reader (whether because of cost, or features, or learning curve) and so I don't think it's the solution.

From a drupal point of view, what are/were the advantages of that solution versus a positioned solution?

[1] http://webaim.org/techniques/css/invisiblecontent/

3. Content is temporarily hidden from view but is available on demand

I'm happy to go with what jQuery does if that's what's in use at the moment and I agree that it's better to get approach them to make any changes required rather than hack it. I think I assumed that jQuery changed the class name rather than injecting inline styles (which feels a bit hacky, but that might just be me) but so long as it works, I'm fine with it (on the same level as walking with sand in your shoes - it's not a showstopper but it'll niggle you).

Is there a list anywhere of the different methods/classnames relating to showing and hiding content within drupal at the moment or is that crazy talk? Is there likely to be differences between themes in how showing/hiding content is handled? Will the world end if it's suggested that some consolidation is attempted?

As for semantic arguments - I haven't had one of those in a while. Just let me get my hard-hat :)

mgifford’s picture

This is a great thread. Seems we're making some real headway on this issue.

Regarding jQuery, wanted to post a link to the accessibility group for jQuery where we should be reporting problems.

I am a bit concerned though that changes to jQuery could take quite a long time to get into a jQuery release and then again even longer to get into Drupal core. Although I'd really like to see jQuery take on a very proactive stance on accessibility (think Dojo is already doing this), I don't think that we can necessarily wait for this.

There are work arounds though like http://evanmeagher.net/2008/03/how-to-use-maintain-accessibility-when-us...

Mike

Jeff Burnz’s picture

1. would it be possible/a total pain to provide a patch which sensitively includes this for at least the core themes (are there many? is patching even possible? am i crazy?), to show how this could be done?

Yes, I will provide the patch for Garland. The only other core theme at the moment is Stark, which has no style (only layout) and utilises Drupals core template files. Stark does not have a Skip link, I will provide a patch for Stark, however my feeling is that we do not hide it by default.

2. what would be the best way of letting themers know that stuff like this needs careful attention?

This was a driving reason behind accessibility handbook pages for themers. I do think that by not hiding the link in Stark we bear light on the subject—we force themers to deal with it, just as they would any other element that needs theming.

I would also like to see tagging for projects, especially themes. As I understand it there will be something like that in the Drupal redesign (the new version of this site), and perhaps we can have validation tags, so themes can stand out if they do not pass this or that validation.

Other than that we have shout it loud and often + provide advice and patches to themers for contrib themes.

I am working on a list of of the different methods/classnames relating to showing and hiding content within drupal right now, its a lot of work and my time is limited.

@mike, well I'm not convinced display: none in the hide() function is a problem (we use the hide() function for collapsible fieldsets). I think its more of where its used and why. We need more testing on this. I understand it could be a problem with OpenID but I have not to that, yet:) When I talk about jQuery and accessibility I more mean support for ARIA and how we can work with the jQuery community and possibly bring some of that innovation into Drupal - check this out - http://www.outstandingelephant.com/jaria/

mgifford’s picture

jARIA looks like a neat plugin. Would be good to bring this back to Drupal for sure. Totally agree that we need more testing, and you and Mohammad76 have done more testing on this than I have. I've been going on docs which may well be outdated. I just had concerns about leaving this to the jQuery community to resolve.

Very interesting to try to generate a list of different CSS approaches to showing/hiding content. Certainly when i was digging around in core for references to display:none (which may not pose any accessibility problems for modern screen readers), there were many more than I had expected to see. http://groups.drupal.org/node/18563#comment-64189

Would be good to fit into the best practices that there are a group of core CSS styles that are used to do this (and that are known to be accessible). A consolidation attempt (particularly a documented consolidation attempt) is a good idea. Thanks again!

I do think it would be good to first add some clean, clear CSS with inline documentation that makes it apparent when and why it might be appropriate. Then we can open up another issue to remove the redundant code.

peterx’s picture

1. Content is initially hidden from view but becomes visible on focus.
That suggests there is something to focus on. If there is something to focus on, we can use the title attribute. Is there a problem with title? If yes then we need a page explaining the problem to theme developers and explaining the alternatives.

If there is nothing to focus on then making something visible does not make sense. Making a skip link suddenly appear at the top of a page does not make sense because the mouse user can easily select the content below the heading. Making a "back to the top" link suddenly appear is pointless because it can be there all the time. Making an arrow suddenly appear on an external link screws up the position of the rest of the text and might as well be there all the time. The few times something useful suddenly appears is when there is a drop down list of choices.

A drop down quick navigation makes sense in a newspaper page where there are several articles and quick links to each article. Screen readers would see the full text up front and the drop down visual alternative would work purely to save space sighted people on a scrunched up iphone (A recent Apple product, not the original Cisco iPhone).

I am scratching to find a use case for surprise content that is not covered by title. Old browsers yes but those older browsers do not work with the CSS or Javascript alternatives.

When notes pop up on pages, the notes invariably hide the text providing the context for the notes. Part of the pop up patter would be to sell the idea of not covering the line before or after the mouse position, another aspect of poptext requiring explanation, documentation, and examples. Are there any good working example Drupal sites out there with poptext other than drop down or drop out menus?

Jeff Burnz’s picture

Pertex.

1) there is no proposal to bring non focusable items into view.

2) Yes it does makes sense to bring a skip link into focus and view—for users who use only the keyboard/tab key for navigation. Think of users who must use rudimentary AT such as a head mounted pointer to tap the keyboard. When the visual designer wants to hide the skip link for design purposes (think Garland as an example), bringing the skip link into focus is an acceptable compromise (ideally skip links should just show by default).

3) Drop down makes little sense. Screen readers use a mixture of techniques such as heading navigation, skip links, all links and now ARIA roles. Where there are several articles or sections on one page they should be marked up with appropriate headings and me thinks landmark role="article". The main point is that document information should be conveyed via semantics, rather than widgets. Granted widgets can be useful, but they should never replace rich semantics because that is what most AT leverage's to provide tools to its users.

You are thinking mouse, well, most disabled users do not use a mouse, but rather the keyboard.

peterx’s picture

Hello jmburnz,
I am having difficulty working out how to explain this part of Web site development to either a Web design student or someone about to sign a contract for a new Web site. Nice intentions fail when the person with the checkbook says "Is there any way you could cut a week off that schedule". A really easy to understand working example is something I can point to.

A working reference example would be nice even if it is manually created and not a totally automatic Drupal feature or not even a Drupal site. We can experiment with the example in the million versions of Internet Explorer, the two million varieties of Mozilla, and try it out with the twenty million arthritics who can only use one finger on each hand.

First I think of visually impaired people, both unsighted and those who need great magnification. The unsighted get text to voice and hear something similar to the Web page without CSS or Javascript. A skip link is a skip link visible or invisible on the screen.

The partially sighted people often use keyboards but still benefit from target prompts to indicate what is available on the page. A non visible skip link would not be easily accessed by people using screen magnifiers.

We use an RSS image to indicate you can click through to an RSS link. Why not use a Skip something to indicate the page has a skip link. We use a north-east arrow to indicate a link to an external site. Why not the same for a content link? The benefits would flow onto everyone who has some sight and wants to know what facilities are on that page.

From a design point, most movable and popin information is a pain because it causes the page to jump around when you make it appear. Are you describing a link that appears in the page and pushes everything else down or something that pops over the existing content?

From a user point of view, when you miss something and have to select it again, you experience pain. Knowing where links are is a real advantage to focus. Using a keyboard and knowing what is ahead helps you avoid skipping past the target.

I have never watched someone use a head pointer. If someone can look at the screen then see their target is the third tap then they should be able put their head down and tap, tap, tap. Making something magically appear after the first tap could lead to someone expecting their target to be the second tap then put their head down and tap, tap, only to miss the magic pop up after the first tap. Surely predictable operation would be even more important when performing any operation is difficult.

How does:
1. Content is initially hidden from view but becomes visible on focus.
square up with:
1) there is no proposal to bring non focusable items into view.
Is it purely for tabbing?

What is focusable when hidden from view?

Is there an example site that works the way you want?

Jeff Burnz’s picture

@mike, being going over your list in the group, can we concur:

fieldset.collapsed
On hold for now, appears to be the expected and desired behaviour
textarea.teaser
Is the expected and desired behaviour + current d7UX proposal to remove the split summary at cursor button
#clean-url.install
Need to test d7, is there an issue here?
#blocks tr.region-populated
Is the expected and desired behaviour, removes unwanted message.
#preview
Is the expected and desired behaviour, removes the color_scheme_form Preview when JS is disabled.
#profile-fields tr.category-populated
Is the expected and desired behaviour, removes unwanted message "No fields in this category...."
#header-region script
No sure about this one, does not seem to affect actual site content?
.hide
Pushbutton now in contrib, issue needs to posted against that theme.

Have we missed any?

Pertex is raising interesting arguments about the use cases for these classes. IMO we have a clear cut use case for Skip links, elsewhere I am not sure.

annmcmeekin’s picture

peterx,

Hopefully I can answer some of the queries you raised in your posts...

That suggests there is something to focus on. If there is something to focus on, we can use the title attribute. Is there a problem with title? If yes then we need a page explaining the problem to theme developers and explaining the alternatives.

The problem with the title attribute is twofold. Firstly, and most importantly, it is unavailable to those who do not use a mouse or other device which allows :hover behaviour. This includes, now, the iPhone and other similar mobile devices. Secondly, misuse of the title attribute seriously degrades the user exprience for those whose access technology which reads out every title attribute by default (in some cases, this default behaviour cannot be turned off). As a result it can't be used for information that is important and its use should really be kept to a minimum.

I am having difficulty working out how to explain this part of Web site development to either a Web design student or someone about to sign a contract for a new Web site.

The explanation for skip links is easy and their inclusion is easily justifiable.

People who have motor difficulties and/or use keyboard only and don't have the benefit of additional (and often expensive) accessibility software can and do find it anywhere on a scale from tedious to painful to navigate sites with large numbers of links.

This group of people includes, but is not limited to: people with a specific medical condition which prevents them from using a mouse or other pointing device (such as those with a sight problem who use screen reader software), older users (a group that is increasing in size as the population ages) and those who don't count themselves as having a disability but have various repetitive strain injuries, or simply those with a temporary injury or illness.

As someone with a medical condition which intermittently affects my ability to use a mouse, I become intensely frustrated when trying to use a number of sites I use on a daily basis because of the lack of a skip link, so this isn't some hypothesis pulled out of thin air. At the time I was finding it painful to use both the keyboard and the mouse, but marginally less painful to use the keyboard. However, the amount of tabbing around I had to do had a direct impact on how long I was able to spend at the computer before I had to rest. More skip links would have enabled me to spend longer at the computer and get more done.

Nice intentions fail when the person with the checkbook says "Is there any way you could cut a week off that schedule".

Placing a skip link at the top of a page (preferably visible all the time, but as a compromise as the first or second link on a page and becoming visible on focus) which allows users to leapfrog over the (often numerous) navigation links and reduce the number of keypresses required to access links in the body, sidebar or end of the primary navigation is the work of moments and provides such a massive boost to the user experience for those who need it that I can't honestly think of a justification to leave it out.

There are many things which could (and most probably should) be cut (or postponed for a later iteration) when a client asks for a reduction in schedule, but this wouldn't be anywhere near the top of any kind of list that immediately springs to mind. If you need to justify its inclusion further to said client, here are a few reasons:

  1. It takes seconds to implement so isn't costing you anything or hampering the ability to implement anything else
  2. It makes you look like you've considered accessibility even if you haven't that much, giving you a PR boost
  3. It makes life easier for a broader group of users than you'd expect

A really easy to understand working example is something I can point to.

http://events.carsonified.com/
http://molly.com/

First I think of visually impaired people, both unsighted and those who need great magnification. The unsighted get text to voice and hear something similar to the Web page without CSS or Javascript. A skip link is a skip link visible or invisible on the screen.

The user group which benefits most from skip links is not those who are using screen readers - they have all manner of groovy tools which allow them to hop, skip and jump all over the place. Between lists of links and headers and hotkeys to move between headings and form fields to name just a few - they're pretty well taken care of.

That doesn't mean to say that a skip link is entirely useless for this user group - some of them might use it to quickly jump themselves to the main content if they haven't entirely gotten to grips with their technology yet (it's a pretty steep learning curve).

The partially sighted people often use keyboards but still benefit from target prompts to indicate what is available on the page. A non visible skip link would not be easily accessed by people using screen magnifiers.

This is true, and that's why I always recommend a visible skip link but will accept a skip link that appears first or second (after the logo) in the tab order and appears in a logical place (top left or across the entire top of the screen) so that those using screen magnifiers will see it. Of course, screen magnification software typically scrolls to focus on the area where the focus has landed, so if it was in a less obvious place, they would more than likely get to see it anyway.

Why not use a Skip something to indicate the page has a skip link. We use a north-east arrow to indicate a link to an external site. Why not the same for a content link? The benefits would flow onto everyone who has some sight and wants to know what facilities are on that page.

A visible skip icon would be awesome, but it'd have to be very carefully chosen to make sure it's meaning was clearly imparted to the end user, and (of course) given appropriate alt text.

Using arrows is good, but I don't think the web has arrived entirely at a consensus on the meaning and placement of arrows. To my mind (and in my experience) a north-east arrow indicates a new window and an east arrow indicates an external site, but not everyone implements it that way.

Maybe a south-east arrow would work as a skip link? Who knows. It might be worth trying though.

From a design point, most movable and popin information is a pain because it causes the page to jump around when you make it appear. Are you describing a link that appears in the page and pushes everything else down or something that pops over the existing content?

Of course, content that moves or blocks content is a pain, but the approaches I recommend for skip links are ones where it appears in a blank area (such as above a logo) or somewhere that doesn't impact or overlap other content (such as the molly.com example given above).

From a user point of view, when you miss something and have to select it again, you experience pain. Knowing where links are is a real advantage to focus. Using a keyboard and knowing what is ahead helps you avoid skipping past the target.

I totally agree that knowing where links are is fundamental to a good user experience, which is why the use of skip links that appear on focus need to be implemented so that they appear somewhere obvious and attract the users attention sufficiently without being offensive.

I have never watched someone use a head pointer. If someone can look at the screen then see their target is the third tap then they should be able put their head down and tap, tap, tap. Making something magically appear after the first tap could lead to someone expecting their target to be the second tap then put their head down and tap, tap, only to miss the magic pop up after the first tap. Surely predictable operation would be even more important when performing any operation is difficult.

The user experience for this type of user will depend on their range of motion and setup. A switch system user may have a system that allows them to "tab" around various options on a virtual keyboard if they have very little ability to move their head. In that instance, having the skip link appear with the first tab is a perfectly acceptable user experience in that they can see it appear and then in two tabs get to the body of the website. If the user has a range of motion and is using a kind of motion controlled virtual mouse, they may not use the skip link because they may be able just to lean forward and tap the link they require.

How does:
1. Content is initially hidden from view but becomes visible on focus.
square up with:
1) there is no proposal to bring non focusable items into view.
Is it purely for tabbing?

What is focusable when hidden from view?

The only use-case for content being initially hidden from view but becoming visible on focus is skip links. It shouldn't be used for anything else.

Jeff Burnz’s picture

I'd just like to add that one of my close friends uses a head pointer. I have spent many hours with her, observing the everyday difficulties she has with surfing the web. I can tell you its slow, almost painfully slow, for her to get around. The notion that one can "tap tap tap" is not reality for her. Tab order is impossible to predict and she must keep a sharp eye on where the focus is. Only on sites she knows really well can she get around with any speed, consequently she uses the same sites a lot, ie those with good accessibility gets repeat traffic, something not to be lost in your pitch.

Jeez, I remembered I posted this way back when I first joined D.O - http://drupal.org/node/67778, what pain we went through adapting an existing system to her needs back then...

veeliam’s picture

annmcmeekin,

That's a fairly awesome response (#12) to peterx's questions. I've been battling with the proper words to explain to developers to stop using a 1px blank image with alternative text that says "skip to content".

I hope you don't mind if I add some of your explanations that a mechanism be to bypass blocks of content that are repeated on multiple Web pages are not just for screenreaders but to sighted keyboard users, a group that arguably needs skip links more than blind users, to my repertoire.

It's great to read accessibility conversations here that are expanding the idea of for who the audience is when we're talking about making Drupal, or any CMS, accessible.

peterx’s picture

Yes, thanks to annmcmeekin.

Your mention of PR reminded me of the triple bottom line justification. Social responsibility is valuable free publicity. Once a corporation can fake social responsibility, they get free publicity. In today's world, even Gordon Gekko would trade a few seconds of work for a mention in the media under corporate social responsibility.

Added to that, if the link is built in the theme, the few seconds work is only once for the whole site. Plus I build many themes as subthemes of other themes, removing the few seconds of work i the other theme already has the link.

This next bit probably should be moved to a separate forum topic. Refering to your examples, carsonified uses:
<a class="skip" href="#mainContent">Skip to content &raquo;</a>
Molly uses:

<a href="http://molly.com/" accesskey="1" id="logo"><img src="http://molly.com/images/logo_lores.png" alt="Molly.com" width="105" height="140" /></a>
<a href="#content" title="skip to the content" accesskey="2" id="skipper">skip to the content</a>

Is accesskey used only when there are multiple skip links? Is there a logical sequence? In the Molly case, I though the skip to content would make more sense if it were ahead of the logo but the access key might change that. Is there some sort of standard that key 1 is always the home key and key 2 the content? A standard list would make sense for common high priority items.

1 home
2 content
3 search
4 espresso
5 drupal.org
6 d-theme.com
7 pizza

Jeff Burnz’s picture

The implementation of accesskey (by the various browsers & OS combinations) is so wrought with issues they should probably not be used at all. Skip link should come first.

In any case accesskey is not the topic of this thread.

Everett Zufelt’s picture

Glad to see that this discussion is taking place. I am fully in support of some base classes for visually hiding content be made available in core.

1. Content is initially hidden from view but becomes visible on focus.

I really don't see a use case for this functionality. Any actionable element displayed visually should be presented visually when the page loads, or require a non-passive action to bring it into view. I do not consider tabbing to a focusable element to be a non-passive action.

Having not experienced this functionality myself, I wonder how a user is to realize that these elements have come into focus, they would need to be placed predominantly within the theme.

2. Content is hidden from view but is available to screen readers and when CSS is not in use.

http://webaim.org/techniques/css/invisiblecontent/ explains that some screen-readers do not handle "height:0; overflow:hidden;" well. Unfortunately the article gives no examples. Testing with three modern screen-readers, (Voiceover, JAWS and NVDA) this class successfully hides content visually, while displaying it to a screen-reader. Can more examples and clarification be given on the pros and cons of using this vs. the absolute offscreen positioning solution? These are really the only two options and one will need to be chosen over the other.

3. Content is temporarily hidden from view but is available on demand

I agree that "display:none;" is the best method to attain this result, this will successfully hide content from a screen-reader, and reveal it again when requested.

Everett Zufelt’s picture

3. Content is temporarily hidden from view but is available on demand

I tested the JQuery hide and show functionality with three screen-readers and assistance from Fluid Project. The page was a simple div and link (to toggle the hide / show status of the div). Using JQuery 1.3.2 here are our results.

1. OS X 10.5.7 with Safari 4 and Voiceover: works as expected

2. Windows XP, Firefox 3.5 and NVDA 0.6p3.2: works as expected

3. Windows XP, Firefox 3.5 and JAWS 10.0.1154: hide works as expected, reveal requires a refresh of the virtual buffer.

I would say that this is an upstream problem, which I will make sure is reported to JQuery, however, it may be useful to come up with a Drupal solution to bridge the gap between now and when the solution finds its way into JQuery and then into Drupal.

Note: JAWS, as a screen-reader, has overwhelming market share significantly greater than 50% of screen-reader users use JAWS.

Jeff Burnz’s picture

Excellent work Everett Zufelt, especially identifying the issue with Jaws and jQuery, we should probably start a new issue and mark that as critical, since code freeze is coming closer everyday.

1. Content is initially hidden from view but becomes visible on focus.

I really don't see a use case for this functionality. Any actionable element displayed visually should be presented visually when the page loads, or require a non-passive action to bring it into view. I do not consider tabbing to a focusable element to be a non-passive action.

The single use case I use this for is skip navigation links, when the designer does not want to show the link or links by default, they can show when the user tabs onto them. Granted this is less than ideal, since many sighted users can make use of skip links and they really need them showing by default. However many clients insist on hiding the links ("do we need that, cant we remove it, I didn't pay for that did I? etc etc").

I don't really understand what you mean by "non-passive action", I would think that means a user taking an active action, ie doing something such as navigating the page, thus surely tabbing is a user action?

Everett Zufelt’s picture

Having done some more testing I found that JQuery hide and show work correctly with JAWS 6 and IE 6. I have heard from a reliable source that JAWS 10 has a bug that requires the buffer to be refreshed when an element goes from display:none to display:block. I don't think that we should develop against bugs in assistive technology, so for now I'd say we accept JQuery hide / show as a reasonable solution.

@jmburnz

For a keyboard only user tabbing through a sight is as active of a process as scrolling with a mouse wheel, which I don't consider to be an "active" enough interaction to warrant something appearing out of nowhere. Nevertheless, if there is a demand and the options are no skip links, or skip links that only show up on focus, then we should go with the later.

Everett Zufelt’s picture

I have now tested style="height:0; overflow:hidden;" successfully with: JAWS 6, JAWS 10, NVDA 0.6p3.2, VoiceOver 10.5.7, Orca 2.22.2 and SAToGo (http://satogo.com/). Unless someone can identify a reason to not use this style then I would like to roll a patch as soon as I can, as many other accessibility issues are dependent on this issue being resolved.

I recommend that the class be named hidden-visually, or hidden-for-screenreader .

Would this class need to be applied to all core themes, or is there a core stylesheet depended upon by all core themes?

Everett Zufelt’s picture

Status: Active » Needs review
FileSize
529 bytes

I have defined two styles in modules/system/system.css

.hidden-all {
display: none;
}

.hidden-for-screen-readers {
height: 0;
overflow: hidden;
}

I checked with two people on irc://irc.freenode.net/#jquery who confirmed that jquery show() and hide() do not modify the visibility property.

If we can get this patch tested and committed it will go a long way to allowing us to work on some other dependent accessibility issues.

mgifford’s picture

Looks great!

dmclark’s picture

+1

Jeff Burnz’s picture

Not a big fan of the class naming. For example there are other ways and means for hiding content for screen readers, such as using text-indent (image replacement) and I can think of a number of other reasons for using height:0, overflow. hidden; so it has wider application.

Thinknig

.remove {
display:none;
}

For example is using jQuery you could add class remove, and toggle classes with .show

.hidden {
height: 0;
overflow: hidden;
}

.hidden because this is hidden for everyone, not just screen reader users, no one wili see the content on screen. Could be paried with a .reveal class for focus/hover events.

Everett Zufelt’s picture

::Sorry for the major edit::

1. I think that the class names are meaningful as they are. .remove and .hidden are a little ambiguous, what is the difference.

2. Although there may be other ways to hide content for screen-reader users the class .hidden-for-screenreaders is a way that is effective for all text containers.

3. I don't think that show-only-on-focus can be accomplished in system.css. I can create a class that "hides" and "shows on focus" but themers are going to want more granular control to the show on focus functionality.

Also, display: none; will not work for the show on focus. if the element is display: none then it is not focusable, at least by screen-reader users, and thus cannot receive focus to be show. This means using positioning or height: 0; to hide the element, and therefore requires knowledge of how to reverse these properties when showing the element.

Jeff Burnz’s picture

Hmmm, there's a pretty big difference actually, based on the declarations:

visibility: hidden hides the element, but it still takes up space in the layout (its still there, just hiding).
display: none removes the element completely from the document.

.hidden-all is wrong because its not hiding, rather its "removed" from the document.

I'm not debating using display:none for focusable elements, what I'm talking about is using jQuery to add_class or to toggles classes - this is a pretty standard thing to do in Drupal themes and modules, and probably out of context in this thread, but as someone who uses jQuery a lot in themes I would not like to use .hidden-all for display none, I want to use a more simple class like .remove.

Lastly, I am not asking for a show-on-focus type class to be added to Drupal core, I was just making a point that I could do if I wanted to.

LOL, I did lots of edits also, had a few beers with dinner, got a bit of a blurry head, not used to it, a non-drinker here:)

Everett Zufelt’s picture

@jmburnz

Also, consider .invisible in place of .hidden

.remove {
display: none;
}

element is removed from the document

.hidden {
height: 0;
overflow: hidden;
}

Visually hides, but is available to screen-readers

.show-on-focus {
visibility: hidden;
}

default state for elements only shown on focus, takes up space, but is not visible

.show-on-focus:focus {
visibility: visible;
}

State of elements only shown on focus when element receives focus

Do these sound like good class names and definitions for modules/system/system.css ?

peterx’s picture

I like extensive descriptions as in #29. Please include them in the CSS.

/* Classes to hide content for specific uses:  */
/* Visually hides, but is available to screen-readers */
.show-on-focus {
visibility: hidden;
}
/* default state for elements only shown on focus, takes up space, but is not visible */
.show-on-focus:focus {
visibility: visible;
}

Do Doxygen style comments work in CSS? Perhaps the comments could include links back to this discussion. When Drupal squishes CSS into one file, the squish could filter out the comments.

Everett Zufelt’s picture

1. I just tested style="visibility: hidden;" with JAWS 10.0.1154 and this property hides elements from screen-readers as well. So, it looks like we'll have to omit this from module/system/system.css, even though I would have liked to have it as a system wide class. Using display: none and visibility: hidden, are both non-functional ways to hide skip to content links from view, as they won't work for screen-reader users, and any other solution (resizing to 0 or moving off screen) require the themer to make a decision about where to position the link on focus.

2. I would like to recommend that the class names in comment 29 be changed to:

.removed renamed to .hidden (hidden for all and is inline with the JQuery hide() function).

.hidden renamed to .invisible (which is a more semantic meaning and does not conflict with a more common understanding about what hidden means in CSS).

What do people think?

Everett Zufelt’s picture

here is a patch using .hidden and .invisible as described in comment 29 and renamed in comment 31

Everett Zufelt’s picture

FileSize
510 bytes

patch

Everett Zufelt’s picture

@peterx

I'm not sure what the comment guidelines are for system.css. Looking back at the file I should have perhaps provided a comment like:

/* classes to hide information */

But, comments that appear in system.css now do not appear to be very verbose. If we can get some testing of this patch and agreement on class names I can reroll the patch with comments.

Jeff Burnz’s picture

@peterx

Do Doxygen style comments work in CSS?

Currently they do not, however Drupal CSS coding standards follow the "proposed" standard which follows Doxygen conventions (CSSdoc syntax.), I do it in all my CSS files in the belief that one day they will work. I think we should do it for all core as well.

Those classes look great to me, nice +1

Everett Zufelt’s picture

FileSize
571 bytes

Rerolled patch with a beginning comment:

/*
** Classes for hiding and making elements invisible
*/

If this patch passes review and gets committed we can update the themeing guide to explain the purpose and use of the classes.

Everett Zufelt’s picture

Status: Needs review » Reviewed & tested by the community

We appear to have agreement on class names and style properties now. Once we get this committed we can add documentation to the Temeing Manual.

sun’s picture

Status: Reviewed & tested by the community » Needs work

Nice. A few issues though.

+/*
+** Classes for hiding and making elements invisible
+*/

Please use proper CSSDoc syntax, e.g.

+/**
+ * Classes for hiding and making elements invisible
+ */

I know the rest of the file doesn't adhere to that as well, but that does not mean we have to introduce new, bad code.

+.hidden {
+display: none;
+}
+.invisible {
+height: 0;
+overflow: hidden;
+}

Missing indentation for styles.

Everett Zufelt’s picture

Status: Needs work » Needs review
FileSize
573 bytes

I believe that this patch addresses all recommendations in #38.

Everett Zufelt’s picture

FileSize
574 bytes

fixed spelling in comments.

Everett Zufelt’s picture

Status: Needs review » Reviewed & tested by the community

Looks like we have agreement on the styles, class names and have comments and spacing correct.

sun’s picture

Thanks! yes, looks much better now!

@Everett Zufelt: Usually, no one marks his own patch as "RTBC" (reviewed & tested by the community). As the name of this status suggests, it is always done by someone else. ;)

The only possible issue I can see with those two generic CSS class names is that an arbitrary module might want to integrate a third-party library (such as an wysiwyg editor) or even simply imports content from another system, where one of those classes had a completely different meaning. In both cases, user interface or content elements will vanish mysteriously. And, we cannot alter these classes later on, because many themes/modules/sites will depend on them. However, using a prefix for them might as well be strange... Because I only fear, but don't have concrete examples, I leave the status.

Everett Zufelt’s picture

@sun

Thanks for the review and additional information. I am quite a novice to the way things work around here.

It is a valid point about class name collision. I for one cannot think of a different way to do this. Unless, we use .hidden-element and .invisible-element; or, .element-hidden and .element-invisible .

Everett Zufelt’s picture

Status: Reviewed & tested by the community » Needs work

Two suggested namespaces and class renaming:

1. .visibility-hidden and .visibility-invisible

2. .visibility-hidden-all and .visibility-hidden-viewport

Owen Barton’s picture

.visibility-invisible I think is fine.

.visibility-hidden I think does not make sense to me because the whole point of display:none (which is missed by many CSS developers) is that it goes beyond just visibility and actually removes the element from the document flow. Since jQuery already uses .hidden I think we should be safe enough to use this directly. If there are conflicts we should be hitting them all over the place already.

I also think that both of these need much more documentation, describing exactly what they do, and in what context they should be used (ideally with examples, such as in the issue description).

On the call we discussed how adding a :focus to .visibility-invisible that makes it visible again is difficult because you don't know what height to set it back to, however I was thinking that if we set a height: auto that should be sufficient for many cases, and of course if needed your could override with a more specific class with :focus to set a more specific value.

Jeff Burnz’s picture

Heads up - http://drupal.org/node/506824#comment-1860318

.remove is used in Ubercart's cart for the remove item checkbox.

Everett Zufelt’s picture

@Owen

Agreed that there needs to be documentation with examples for any system classes.

I have been thinking for a long time about this and really can come up with no better class namespace than .visibility- I'm not sure if .hidden can work, as I believe that it is typical to place classes within namespaces, but I am happy to role a patch with each and see if we can get one acepted.

As for :focus, I think we should roll the first patch without this, and role a second patch for this.

New proposed classes:

/**
 * Classes to hide content from all users, and to make hidden content available to screen-users only.
 */
.visibility-hidden { // will role the patch with only .hidden as well
  display: none;
}
.visibility-invisible {
  height: 0;
  overflow: hidden;
}
Jeff Burnz’s picture

I have to throw a spanner in there and object to these class names, I just don't think we should be naming classes after properties and values, because its instantly confusing and is definite wtf moment.

But, if we were to go this route why not have:

.display-none {display: none;}
.overflow-hidden {height: 0;overflow: hidden;}

That makes a lot more sense to me than a confusing mix of properties and values as selectors that bear little resemblance to their actual properties and values, but I still don't like it.

After a lot of thought, I still think it should be .remove and .hidden.

And again - hidden is wrong for display none, it is not hidden; display: none removes it from the dom, its not hiding at all, for all intensive purposes it no longer exists, because its been *removed*.

Everett Zufelt’s picture

@jmburnz

I am completely content with your recommendations for .remove and .hidden. Obviously each will need to have documentation about its use, which I am happy to provide.

If these collide with any contributed projects they can make their own changes, as they will need to do for a number of changes in d7 core.

I have rolled a patch for each of three of the class naming conventions above:

issue-473396-remove.hidden.patch: .remove and .hidden.

issue-473396-hidden.visibility-invisible.patch: .hidden and visibility-invisible.

issue-473396-visibility-hidden.visibility-invisible.patch: visibility-hidden and visibility-invisible.

I'd love to get some +1s on these so that we can come to a consensus and set this issue RTBC.

Everett Zufelt’s picture

My +1 is for .remove and .hidden

sun’s picture

Repeating myself from #42: .remove and .hidden are very ambiguous CSS class names. Whenever anything (a module, a third-party library, syndicated content from third-party web-sites, imported content from other systems, client-side editor *buttons* to "remove" HTML styles or make HTML elements "hidden", etc.) happens to use these classes, the styles will be applied and page content is mysteriously gone.

mgifford’s picture

sun, we need examples of what you would agree to. There are a number of other accessibility issues that are waiting on having this functionality. This concern has been discussed actively for years. I've personally been trying to find a solution for this now for the last 6 months.

Sounds like from your critique that you'd have no problem with this patch - http://drupal.org/files/issues/issue-473396-visibility-hidden.visibility...

If that's the case, give this your +1 and let's move on to the other issues that depend on this functionality. If not, provide a better example that isn't ambiguous and let's work together to get this into core at last!

Mike

sun’s picture

There are two options:

1) Use a prefix that is (rather) unique to Drupal, e.g. "system-hidden" + "system-removed" or "drupal-hidden" + "drupal-removed" (I'm opposed to 'remove' btw, because it does not describe a state)

2) Use an obscure, long class name, like the suggested "visibility-hidden" + "visibility-invisible" and pray that no other library/module/system conflicts with them.

That said, the proposal of #48 is also likely to work:

3) Use class names equaling the actual CSS styles, i.e. "display-none" + "visibility-hidden".

The latter will probably work, because any other thing that also implements/uses these class names most likely uses them for the very same purpose. Also, they are self-descriptive, so developers and themers do not have to look them up to find out which to use.

All that being said, I'd vote +1 for 3), resp. the proposal in #48.

Jeff Burnz’s picture

@Sun, yes, agree we need a pseudo name space, Everett Zufelt suggested using *element* way back somewhere in this thread or another one which didnt get much feedback I recall but I thought was quite good:

.element-remove {}
.element-hidden {}

I quite like this, it would allow me to use that name space in contrib, eg I could use .element-inline, .element-block and so on.

annmcmeekin’s picture

+1 for .element-remove and .element-hidden

(although my inner grammarian suggests that .element-hide would be a wee bit better)

sun’s picture

It may be an important fact that - even after looking at the patch, and even after scanning and scrolling over the code snippets in this issue 40 minutes ago - I cannot remember a) those "visibility-*" class names, b) I can't recall the difference between the two, and most importantly c) I don't know what either class does.

Likewise, although I can remember "element-hidden" and "element-remove", I have no idea what they do and what the difference is - so I'll either have to look it up, or simply not use them.

That's a major DX issue.

Contrary to that, I am able to recall "display-none" and "visibility-hidden", and it is relatively clear to me what each of them is supposed to do, and probably, when I'm supposed to use which. (though the latter should be clarified and explained a bit more in the CSSDoc)

annmcmeekin’s picture

Forgive me, but in my experience (and perhaps part of the reason for this issue being an issue) designers and developers, for the most part, aren't using display-none, visibility-hidden and other techniques for hiding and selectively hiding content appropriately.

I'm also a little concerned that using visibility-hidden as a class name implies that it uses visibility: hidden in its properties, which it doesn't.

On your point about not using them if you can't figure out what they mean and don't want to look it up - I'm not sure how much more explicit than .element-remove and .element-hide the class names can be made to improve understanding, especially when read in conjunction with the properties.

Would it help if there was a brief description in a comment in the CSS?

For example:

.element-remove /* hides content from all users */ {
display: none;
}

.element-hide /* hides content visually, but keeps it available for screen reader users */ {
height: 0;
overflow: hidden;
}

This would then be backed up by documentation in appropriate places giving the rationale.

Everett Zufelt’s picture

I really don't think that using the style attributes themselves (display-none) is the best idea, it gives the developer less knowledge of the purpose of the class than a more descriptive, all be it ambiguous name.

I like the suggestion of:

.element-remove and .element-hide, but would be equally happy with .element-hide and .element-invisible, obviously there would need to be documentation for each, and I agree with Anne that a brief description in system.css would also help.

peterx’s picture

On documentation using one of the examples:

.element-remove /* hides content from all users */ {
display: none;
}

Could be in the form:

.element-remove /* hides content from all users http://drupal.org/node/388372 */ {
display: none;
}
Jeff Burnz’s picture

While I tend to agree with Sun that the proposals in #48 are easy to remember I prefer the name spacing of .element-[], so its +1 from me for:

.element-remove {}
.element-hide {}

sun’s picture

ok, then please go ahead with .element-*

However, we should really use adjectives here, because those classes describe a certain state that is applied to elements ("hidden"). A verb of the form "hide" gives the assumption that a JavaScript behavior is supposed to pick those elements up to apply a certain behavior on them. That's the difference in using adjectives to describe state and using verbs to trigger an intended state.

So, lacking a better proposal, .element-hidden + .element-invisible seem to be the best choice.

You can use CSSDoc to document these classes. However, please do not document the obvious (which was proposed with hides content from all users above). Comments should explain the hows and whys instead, not the trivial. We expect people reading CSS code to understand the basics of CSS, just like we expect PHP coders to understand PHP. The comments should answer the reader's question: Why and when (under which circumstances) would I want to use this class?

Additionally, the CSSDoc for each class name should make the difference to the other clear, because both remove elements from the visible output. Developers and themers usually are no accessibility experts, so we need to teach them a bit here.

Lastly, links to further online documentation should only be included in case there is a massive documentation page about the usage of these classes, which cannot be shortcut into one or two sentences.

For example:

/**
 * Hide elements from all users.
 *
 * To be used for elements that should not be.... [one sentence; wrapping at 80
 * chars, if required].
 */
.element-invisible {
  display: none;
}

/**
 * Hide elements visually, but keep them visible for screen-readers.
 *
 * Used for elements that.... [one sentence; wrapping at 80 chars, if required].
 */
.element-hidden {
  height: 0;
  overflow: hidden;
}

If this cannot be explained in one short sentence, then link to the d.o handbook page about this stuff:

/**
 * Hide elements from all users.
 *
 * @see http://drupal.org/node/123456
 */
.element-invisible {
  display: none;
}

/**
 * Hide elements visually, but keep them visible for screen-readers.
 *
 * @see http://drupal.org/node/123456
 */
.element-hidden {
  height: 0;
  overflow: hidden;
}
Jeff Burnz’s picture

Does it for me, lets wrap this up, get some eyes on it and move on ;)

Everett Zufelt’s picture

So happy for all of the contributions over the past day or so.

Just want to clarify that we are thinking of

.element-hidden {
display: none;
}
.element-invisible {
height: 0;
overflow: hidden;
}

Or do I have that backward?

Everett Zufelt’s picture

Created two patches, please let me know what naming is preferred:
}
+/**
+ * Hide elements from all users.
+ *
+ * To be used for elements that should not be displayed to any users.
+ */
+.element-hidden {
+ display: none;
+}
+/**
+ * Hide elements visually, but keep them available for screen-readers.
+ *
+ * Used for elements that provide textual representations of visual concepts to screen-reader users.
+ */
+.element-invisible {
+ height: 0;
+ overflow: hidden;
+}

The only difference between the two patches is switching hidden and invisible for the two classes.

mgifford’s picture

I really prefer - http://drupal.org/files/issues/issue-473396-hidden-invisible.patch

This will be be easier for people to adapt as it's more consistent with how Drupal 6 does it now.

.element-hidden {
display: none;
}

Everett Zufelt’s picture

annmcmeekin’s picture

I'll add my +1 if the comment for .element-invisible can be changed from

"Used for elements that provide textual representations of visual concepts to screen-reader users."

to

"Used for information required for screen-reader users to understand/use the site where visual display is undesirable. Information provided in this manner should be kept concise, to avoid unnecessary burden on the user."

Because the information provided isn't always a textual representation of a visual concept, and I think it could confuse developers because it sounds like it should only be used for image alternatives/longdesc type stuff, which might make them think they can't use it in cases where it'd be appropriate. I also think that there's a tendency towards shoving all manner of patronising instruction into screen reader only text and this might just cut that off at the pass.

I'm happy to write up a bit of expanded documentation about the what and when of using this technique in documentation if someone can point me to where would be most appropriate for this info to live.

Cliff’s picture

+1

Impressive! Great work, everyone!

Everett Zufelt’s picture

Updated patch with @annmcmeekin suggested comments from 67.

sun’s picture

@@ -564,3 +564,22 @@ div.password-suggestions ul {
   visibility: hidden;
 }
+/**
+ * Hide elements from all users.
...
+}
+/**

Please add a newline between the last code and CSSDoc blocks.

@@ -564,3 +564,22 @@ div.password-suggestions ul {
+ * To be used for elements that should not be displayed to any users.

I think it should be "...to any user" (singular).

Otherwise, this looks good to go.

This review is powered by Dreditor.

Everett Zufelt’s picture

Updated patch from comment 69 with suggestions in comment 70.

1. added new line between last code and new css doc blocks.

2. Fixed pluralization error

These two classes provide functionality to hide elements for all users, and to make elements invisible to all users, but available to screen-reader users.

sun’s picture

Status: Needs review » Reviewed & tested by the community
Cliff’s picture

+1. +10 if I could!

Cliff

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Wow! Very impressive team work, folks! :D

The element- prefix should help save us from namespace conflicts with other modules/projects, and I totally agree with annmcmeekin in #57 that naming these classes around the display properties that CSS developers so frequently get absolutely wrong is the wrong way to go. So this approach makes sense to me.

I am *not* a CSS developer (just know enough to be dangerous), so I still need a couple of things before this is RTBC from my view:

.element-invisible has very nice documentation that explains to me exactly why I would want to use it, and what the guidelines are around putting stuff in there. I'm missing this from .element-hidden. I feel like there's a lot of really great best practices stuff that's in this issue and is not captured in the documentation for posterity. Let's add a similar couple of sentences there.

And finally, I totally do NOT want to open the name bikeshed argument yet again, but there is no discernable difference between the words "hidden" and "invisible" to me as a non-CSS person. I'm hoping the documentation will help clear that up, but I noticed in #28 jmburnz points out that "display: none removes the element completely from the document." and that does make sense to me. So.. just asking, would .element-removed vs. .element-hidden be an acceptable balance? Or is this one of those "No, silly webchick, this will totally make sense to its intended audience so pipe down and go sit in your fancy PHP corner" because I'm totally fine with that if that's the case.

JohnAlbin’s picture

Status: Needs work » Reviewed & tested by the community

Man, I really should follow the accessibility tag more often. :-)

JohnAlbin’s picture

Status: Reviewed & tested by the community » Needs work

whoops. cross-posted.

Everett Zufelt’s picture

@webchick

I don't think that we will ever come up with class names that are completely simple to understand, because of the complicated nature of this issue. My argument against using remove and for using hidden is two fold:

1. Nothing is being removed by setting a element to display: none. The element is still certainly part of the DOM.

2. JQuery uses the hide() and show() functions to toggle an elements CSS display: attribute between none and block, so using hide is inline with JQuery.

As for invisible, this is a little ambiguous, the way that it makes sense to me is that if something is hidden it can't be found (by anyone), but if something is invisible it cannot be seen, but is still present. Maybe that only makes sense to me, but I feel that we have a reasonable amount of agreement on these names and without another suggestion I think they are both appropriate with proper documentation.

On the documentation note, I will work on some wording for .element-hidden and will reroll the patch.

Thanks

Everett Zufelt’s picture

Rerolled patch with additional documentation for .element-hidden as per @webchick's comment 74.

+/**
+ * Hide elements from all users.
+ *
+ * Used for elements that should not be immediately displayed to any user. An
+ * example may be a collapsable fieldset, that will be expanded by an action
+ * from a user. The effect of this class can be toggled with the JQuery show()
+ * and hide() functions.
+ */

Everett Zufelt’s picture

Status: Needs work » Needs review
webchick’s picture

I think that with the documentation, this might be clear enough now to help abate any confusion. I'll let this sit for a few hours until I get up tomorrow and see if anyone else has any bright ideas, otherwise will likely commit this patch.

JohnAlbin’s picture

Status: Needs review » Needs work

Hmm… I do see an issue with the CSS, though. An invisible element could still affect positioning of adjacent elements with the proposed CSS.

If, for example, we put .element-invisible on a block's title, the title's block margin will still affect the positioning of the text below and above it. Block titles use h2 and that usually means a top and bottom margin of 1em. So, its not invisible to the pixel-perfect designers wanting it to be truly invisible.

The easy way out of this is to add a position: absolute; to .element-invisible. That takes the element out of the normal flow of the document without making it inaccessible to text-based web browsers.

Also, why did we decide that we should ignore http://webaim.org/techniques/css/invisiblecontent/ ? Ann in comment #4 mentions the problems with height: 0; overflow: hidden;, but I don't see any response to her point.

Unfortunately, it seems that the non-positioning technique of:

.invisible {
  height: 0;
  overflow: hidden;
}

can cause problems for some screen readers[1] and although it may be something which newer versions of screen readers deal differently with, there are still a whole lot of people who don't, won't or can't upgrade their screen reader (whether because of cost, or features, or learning curve) and so I don't think it's the solution.

I see Everett (in #22) tested a bunch of the newer screen readers: JAWS 6 (released in 2005), JAWS 10, NVDA 0.6p3.2, VoiceOver 10.5.7, Orca 2.22.2 and SAToGo.

But webaim.org hasn't commented on the technique the patches are using. See this March 5, 2009 blog post: http://webaim.org/blog/hiding-content-for-screen-readers/

Jeff Burnz’s picture

Status: Needs work » Needs review

What I mean is, that when I use display: none; as far as the browser is concerned, with no other rules to tell it otherwise, the element is removed - yes it's still in the markup and I should have used the term "formatting structure" rather than dom:

"This value causes an element to not appear in the formatting structure (i.e., in visual media the element generates no boxes and has no effect on layout). Descendant elements do not generate any boxes either; the element and its content are removed from the formatting structure entirely." http://www.w3.org/TR/CSS2/visuren.html#display-prop

hidden implies the box is generated and just hiding (i.e. visibility: hidden) which is confusing for me, and I bet a lot of other CSS'ers.

So webchick, no, its not a silly question, for me its is confusing because "hidden" goes against how I read the spec, i.e. how I can understand what properties and values to use in my CSS.

I +1 this earlier so we can get on with it since its dragging out, late changes are fine imo also, time is running out though :)

Everett Zufelt’s picture

@jmburnz, @webchick

I am happy to rename the classes to .element-removed and .element-hidden. Although I would argue, again, that hidden is in line with the JQuery hide() function and the type of "hiding" that {height: 0; overflow: hidden;} performs is not the same as {visibility: hidden;}.

@JohnAlbin

1. I can reroll with {position: absolute;}, thanks for pointing that out.

2. No examples or evidence have been provided of any screen-reader that does not recognize elements styled with {height: 0; overflow: hidden;}.

3. There was some concern raised in g.d.o or an earlier issue, I do not have the reference at the moment, that moving elements offscreen may cause a trailing dotted outline if a focusable element is within the "invisible" element. The only other concern then would be providing a invisibility class for the standard stylesheet and another for the RTL stylesheet so that the content can be pushed off to the right side of the screen for RTL languages.

Conclusion
I am happy to reroll the patch with whatever reasonable recommendations can make it into core. But, there are only four weeks remaining and there are a number of other patches dependent on this fix.

Jeff Burnz’s picture

@JohnAlbin - I use position:absolute method (all properties default to auto) because of the reasons stated.

Everett Zufelt’s picture

Created a new patch following @JohnAlbin's recommendation in comment 81.

1. Replaced style for .element-invisible with the following from WebAIM ( http://webaim.org/blog/hiding-content-for-screen-readers/ ).

+  position: absolute;
+  left: -10000px;
+  top: auto;
+  width: 1px;
+  height: 1px;
+  overflow: hidden;

2. Added .element-invisible to modules/system/system-rtl.css using {left: 10000px;}.

This will need to be tested with focusable elements in LTR and RTL configurations to ensure that there are no visual anomalies.

Unfortunately I will not be able to assist with visual testing as I cannot see any anomalies that may appear.

annmcmeekin’s picture

Content can be moved off-top to avoid any issues with RTL content as in the example code I offered in #2.

Focusable elements MUST NOT be moved out of the viewport. This is a very serious issue for keyboard only and voice recognition users who can see the screen. If focusable elements are moved out of the viewport, the focus still goes to them, but with no visual indication, which can leave keyboard only users disorientated because the focus disappears and may not appear again for several tab presses, or in a different place. For voice recognition users, if they speak the content of the "invisible" link, the link will be selected, again with no visual indication which will be disorientating.

Perhaps the phrase "Must not be used for focusable elements." can be added to the comment of .element-invisible to resolve this.

Everett Zufelt’s picture

@annmcmeekin

1. Looking at the WebAIM article at http://webaim.org/blog/hiding-content-for-screen-readers/ it is recommended to not hide content above the viewport as * if * there is a focusable element it may scroll the page to the top of the viewport on focus.

2. Agree 100% about the not hiding focusable elements, but we need to make sure that if someone does hide a focusable element that it causes no visual anomalies.

3. Will update doc for .element-invisible as you have suggested once we agree upon either the offscreen or height: 0 approach.

annmcmeekin’s picture

Everett,

I know that WebAIM recommends not hiding content above the viewport because it makes it scroll but to be honest, I'm really uncomfortable about styling stuff so that it makes it ok if people push focusable elements offscreen.

If there is no obvious downside to implementing something that is bad practice, where does the motivation to change the behaviour come from?

Maybe "Must not be used for focusable elements." needs to be expanded to "Must not be used for focusable elements as this causes issues for keyboard only or voice recognition users." so that people understand there's a good reason for not doing it.

Otherwise, all we're doing is resolving an issue for one group of users (screen reader users) and potentially replacing it with a different issue for another group of users (keyboard/voice recognition users) and I'm really not fine with that.

sun’s picture

The RTL styles are not needed, and actually, I think they are wrong, because the browser will render a horizontal scrollbar this way. AFAIK, RTL defines the text direction, not the DOM layout direction, so element rendering still happens from left to right. That said, annmcmeekin's approach of using top: instead of left: would solve this issue safely, so ideally we go with that.

Everett's reasoning for going with .element-hidden, because developers already know jQuery's .hide() (which technically does the same) makes absolutely sense.

webchick’s picture

Everett's reasoning for going with .element-hidden, because developers already know jQuery's .hide() (which technically does the same) makes absolutely sense.

Hm. But yet I think it makes equal sense (if not even moreso; not sure of the cross-over rate here between CSS/JS devs) that CSS developer would expect element-hidden to be the one that does overflow: hidden.

However, knowing now that "removed" isn't really accurate of what display: none does, I don't think it any longer makes sense to swap the names. We'll have to hope the docs are sufficient.

Sounds like Ann still has some feedback in #88 that needs addressing.

Everett Zufelt’s picture

@annmcmeekin @webchick

Able to reroll this any way the community likes. We need to decide on a philosophy on the offscreen focusable elements.

1. Make sure that if a focusable element is hidden with .element-invisible that it causes no visual anomalies.

2. Assume that people will read, understand and implement the docs and implement a style that may cause visual anomalies.

I have no preference.

mgifford’s picture

The patch in #85 should deal nicely with BIDI (LTR & RTL sites). Thanks for bundling this up again Ethan. +1

This issue queue has been very active as have related threads on g.d.o. I'm not convinced that there are going to be big differences between an application one way or another. Nobody has yet to demonstrate to me that one is clearly better. In reviewing other sites on this issue it is much more common to shove the content left (in a left to right site) than anything else. I've seen almost nothing on accessibility in a right to left environment. This might be the easiest one for folks to embrace.

The important thing though is to get an acceptable name space defined and in core so that a number of related patches can be re-written to move content off screen. If someone has a strong preference one way or another it can then be easily overwritten in the theme layer.

Everett Zufelt’s picture

For what it's worth, I asked Jared Smith (WebAIM) over Twitter if he could provide examples of screen-readers that would have a problem with "height: 0; overflow: hidden;"

His response was: " I don't know exactly (and don't care enough to install ancient JAWS), but we're talking quite a few years/versions ago." ( http://twitter.com/jared_w_smith/status/3112522912 ).

sun’s picture

@annmcmeekin: Looks like your feedback blocks this issue from getting in. Any news or amendments?

JohnAlbin’s picture

I feel more comfortable ignoring http://webaim.org/blog/hiding-content-for-screen-readers/ now that I know Jared can't even remember which screen-readers couldn't deal with height: 0; overflow: hidden.

So lets go with

height: 0;
overflow: hidden;
position: absolute;

And also expand the comments to include the language Ann uses in #88 above.

Everett Zufelt’s picture

+1 for the recommendation in comment #95. I definitely think the focusable elements warning needs to be clear. I am quite comfortable with using this style as there is no evidence of any screen-reader for which it won't work.

webchick’s picture

OK, fine by me. :)

Everett Zufelt’s picture

Rerolled patch from comment #78 with suggestions in #88 (warning against using .element-invisible for focusable elements) and #95
(adding position: absolute).

+/**
+ * Hide elements from all users.
+ *
+ * Used for elements that should not be immediately displayed to any user. An
+ * example may be a collapsable fieldset, that will be expanded by an action
+ * from a user. The effect of this class can be toggled with the JQuery show()
+ * and hide() functions.
+ */
+.element-hidden {
+ display: none;
+}
+
+/**
+ * Hide elements visually, but keep them available for screen-readers.
+ *
+ * Used for information required for screen-reader users to understand and use
+ * the site where visual display is undesirable. Information provided in this
+ * manner should be kept concise, to avoid unnecessary burden on the user. Must
+ * not be used for focusable elements as this causes issues for keyboard only
+ * or voice recognition users.
+ */
+.element-invisible {
+ height: 0;
+ overflow: hidden;
+ position: absolute;
+}

JohnAlbin’s picture

Status: Needs review » Reviewed & tested by the community

Go to go! :-)

sun’s picture

+++ modules/system/system.css	6 Aug 2009 07:58:04 -0000
@@ -565,3 +565,30 @@ div.password-suggestions ul {
+ * Used for elements that should not be immediately displayed to any user. An
+ * example may be a collapsable fieldset, that will be expanded by an action
+ * from a user. The effect of this class can be toggled with the JQuery show()

s/collapsable/collapsible/

s/that/which/

Sorry, but I do not understand what "will be expanded by an action from a user" means...?

s/JQuery/jQuery/

24 days to code freeze. Better review yourself.

JohnAlbin’s picture

Re-rolled with sun's changes. I changed “An example may be a collapsable fieldset, that will be expanded by an action from a user.” to “An example would be a collapsible fieldset that will be expanded with a click from a user.”

I also added “(such as links and form elements)” to help describe the somewhat jargon-y term “focusable elements”.

I made no changes to the CSS, so am leaving at RTBC.

webchick’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs documentation

Awesome work, folks! Committed to HEAD! :)

Please make a note of this in the 6.x => 7.x theme upgrade guide.

Everett Zufelt’s picture

Who can I speak to about adding documentation to the 6.x => 7.x theme upgrade guide? Looks like I don't have the ability to edit pages.

Everett Zufelt’s picture

Suggested documentation. We can add more explanation if required, but I think that is pretty clear. Having he two explained together will help to highlight the difference in functionality.

New classes available to hide content in an accessible manner

Two new system classes have been added to be used for the purpose of hiding elements, .element-hidden and .element-invisible. Each class serves its own unique purpose

.element-hidden - the role of this class is to hide elements from all users. This class should be used for elements which should not be immediately displayed to any user. An example would be a collapsible fieldset that will be expanded with a click from a user. The effect of this class can be toggled with the jQuery show() and hide() functions.

.element-invisible - The role of this class is to hide elements visually, but keep them available for screen-readers. This class should be used for information required for screen-reader users to understand and use the site where visual display is undesirable. Information provided in this manner should be kept concise, to avoid unnecessary burden on the user. This class must not be used for focusable elements (such as links and form elements) as this causes issues for keyboard only or voice recognition users.

JohnAlbin’s picture

Status: Needs work » Fixed
annmcmeekin’s picture

Awesome.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

effulgentsia’s picture

I have not yet read this whole thread, and I'm hoping not to (it's quite a lot of material), but I'd like to ask for help on #639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes from the people here (some of the people here have already been helping out on that, thank you!).

What should the scope of that issue be, given where we are in the D7 cycle? I think a point of agreement there is that despite all the great brain power that went into this issue, it doesn't seem to be used for the "skip links" link, making it all too likely that someone developing a custom theme will do something that results in that link being inaccessible. Jeff Burnz opened the issue as one in which to create a theme setting to toggle between using the "element-invisible" class for that link or not, making it easy to build a theme where either full visibility of that link or full invisibility of that link could be achieved. I have some concerns with the latest patch there, starting with #639460-24: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes, but my biggest concern at this point is that the solution that we as a community decided was best for both Garland and Seven is to have "invisible initially, visible on focus", and it doesn't seem there's any way, even with that patch, for a theme to make that work except by copying some pretty arcane CSS magic from Garland's or Seven's style.css file.

Anyway, that's enough background for now, the rest can be read on that issue. If anyone here can offer some guidance, it would be much appreciated. If that entire issue needs to be bumped to D8, so be it, but unless I'm missing something, it seems like what we have currently in HEAD will lead to lots of themes implementing something wrong with respect to #skip_link (like display:none) and break accessibility. If you care about that, please comment on that issue. Thanks!

mgifford’s picture

I posted a follow-up for D8 #1158426: Generalized CSS Classes for Focus, Invisible & Hidden - Accessibility Enhancement - I don't see a way of considering this issue for every major release. That being said, I'm hoping we can get much more efficient about how we do it.

mgifford’s picture

Issue summary: View changes

adding link to theming guide

raal’s picture

Issue summary: View changes

.element-invisible class does not work properly in Chrome and Safari for inline elements