Cascading Style Sheets

Cascading Style Sheets (CSS) have been suggested as a solution for hiding long description indicators or long description content. This suggestion:

Violates Search Engine Guidelines

Search engines do not seem to leave any room for text that is hidden (or off screen) for good reasons like long descriptions.

Google's guideline on hidden text states:

If you do find hidden text or links on your site, either remove them or, if they are relevant for your site's visitors, make them easily viewable. If your site has been removed from our search results ... Once you've made your changes and are confident that your site no longer violates our guidelines, submit your site for reconsideration..

The penalty for a site using hidden text may be removed from the Google index, and will not appear in search results pages.

Yahoo!'s search engine has a similar content quality guideline:

...examples of the types of content that Yahoo! does not want included...The use of text or links that are hidden from the user...

Long descriptions that utilize the longdesc attribute have no such search engine penalties imposed. longdesc is a simple link.

Needless Complexity, Page Weight, and Inconsistency

Requiring authors to use CSS to hide the indicator when longdesc already does this natively, not only adds needless complexity, page weight, and inconsistency, it also is error prone and disenfranchises authors of limited skill set.

Different CSS techniques for hiding have very different results. Elements styled with "display:none" or "visibility:hidden" are not included in the accessibility tree. They are always hidden from screen readers and browsers. [McCathieNevile 2012 test case]

However, other declarations for hiding such as "left: -9999px; top: -9999px;" is rendered to screen reader users just as any other currently visually visible element on the screen is but it is stripped of all interactivity and semantic structure.

The Association of American Publishers (AAP) has attested that piecemeal, workarounds for not forcing a visual encumbrance creates complexity, inconsistency, and unreliability. In particular they point out that hiding long description link text visually,

would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.

CSS rules such as img{border:0;} for a long description link on an image is a needless, circuitous kludge. Older native HTML syntax is simple. Requiring CSS would add page weight and slow pages. Authors have voiced these facts. For instance, on October 13, 2011, Barry Kintner beseeched the HTML working group:

Please do not drop recognition of older (simpler) HTML vocabulary. I find far too many people are over-using CSS etc - not really knowing or understanding the needs of the visitor...

Hiding long description indicators and link text with CSS adds needless complexity and is error prone. The potential for confusion is rife.

Even authors versed in CSS have problems hiding long description indicators with CSS in a manner that is accessible. The declaration display:none is hidden from screen readers. Not many authors know that fact. They use it to hide long description link text and it does not work for their target audience. For instance, Snowdon Award Scheme, and Zew have mistakenly used display:none for long description link text indicators. However, this common mistake was mitigated in these three examples because they also used longdesc, which works.

Another example of an inaccessible CSS technique is using visibility:hidden. This declaration should not be used for content that is to be read by screen readers because it hides content from them. As Marco Zehe recently stated,

Elements styled with "display:none" or "visibility:hidden" are always hidden from screen readers as well. This is true for screen readers on Windows like NVDA or JAWS, and has been so for at least the last ~7 years. Orca on Linux, VoiceOver on OS X and iOS also adhere to this rule. JAWS has consistently supported this since version 7, which was released in 2005. All other screen readers I know do this right, too, and have been for ages. Why this rumor that one can provide extra content to screen readers via elements styled with "display:none" keeps sticking around, I have no clue. It is definitely wrong! Screen readers completely ignore elements styled with "display:none" or "visibility:hidden;" .

Daegu Metropolitan Office of Education is an example of an organization mistakenly using this technique. Fortunately they also used longdesc, which does work.

The Paciello Group recently illuminated various techniques to hide content. They detail the correct technique to hide interactive (focusable) content from visible display with CSS, but still have it in the tab order. As stated,

Focusable content should only be hidden from visible display if the focusable element becomes visible when it receives focus:

Example code:

a.offscreen
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}
 
a.offscreen:focus 
{position:relative; 
left:0px; 
width:auto; 
height:auto; 
overflow:auto; 
}

This technique is required to correctly hide long descriptions that contain interactivity and semantic structure. The two sister sites Statistics Canada and Statistique Canada are examples of an organization that incorrectly use positioning off screen position: absolute; top: -100px without a focus technique for interactive semantic content. Fortunately they also used longdesc, which preserves all interactivity and semantic structure.

Hiding long description indicators and link text with CSS would especially place an undue burden on authors of limited skill set. They will not know how to use CSS let alone know which techniques may be accessible and which definitely are not. With longdesc this is not an issue because it is natively free from a visual encumbrance.

If HTML5 obsoletes longdesc and authors hide long description indicators/link text with CSS, many will use the wrong techniques. Requiring the use of CSS when longdesc is already natively free from a visual encumbrance reinvents the wheel. It is an inefficient, inelegant , and clumsy "hack" that not only adds needless complexity, confusion, page weight, and inconsistency, it also is error prone and disenfranchises authors of limited skill set. All told, it would result in less accessible content.

Structure is Stripped From Any Hidden Content Referenced by ARIA

As explained, structured markup facilitates critical functionality.

Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,

...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.

Even though it can point to structured content such as headings, lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal encourages user agents to expose the full semantics of hidden elements to assistive technology, as implemented aria-describedby/hidden is limited in its ability to process structured content. Accessibility APIs that aria-describedby maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who cannot use a mouse. Sighted keyboard users need to know where their focus is so they do not become disoriented. Focused items need to be visible.

Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.

This means that most assistive technology treats aria-describedby target content as though it does not have any mark-up. It is treated as a string. Structure is stripped. A user's reading keys will not work. Users are not able to interact with the content.

As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby to point to a hidden link would be futile because a user would not be able to to navigate to and activate the link:

When the author does not desire the entire descriptive text to be located on the main page, aria-describedby can also be used to point to a link to another page.

  <div id="figuretitle"> Figure 1-1: Entity Relationship Diagram showing EMP and DEPT</div>
   <img src="foo" aria-labelledby="figuretitle" aria-describedby="link1">
   <a href="descriptionLocation.html" id="link1">
    Description of Figure 1-1: Entity Relationship Diagram showing EMP and DEPT</a>
  </div>

It is not good practice to use the above pattern when the describing elemen - the <a> tag with @id='link1'- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.

None of this is a problem with longdesc. Longdesc supports structured content. Reading keys and links work.

No Evidence of Improvement

No evidence has been presented that using Cascading Style Sheets (CSS) to hide long description indicators or long description content produces more accessible content for long descriptions or that more authors would use it correctly.