Overview

Often when developing a web page, it can make sense to hide specific aspects of the page until a certain action occurs, which causes them to appear. A common example of this is navigation menus, which when navigated to sometimes display child items of the navigation menu in a list. The child elements of the navigation menu are often styled using CSS to be hidden by default, then shown when interacted with by using Javascript. Basic stuff, right? In the following post I’d like to explain the common pitfalls with hidden content and how it interacts with the accessibility tree. No idea what the accessibility tree is? Don’t worry, we’ll cover that too.

The Document Object Model and the Accessibility Tree

The Document Object Model (DOM) is what it says on the tin, a method to gather up information processed in the page source, and provide it in an object model, which can be interacted with and programmatically manipulated. For example, one of the most used commands in Javascript is document.getElementById which directly accesses the DOM to allow the user to reference an element, and with further logic be able to manipulate its attributes, styling and more.

The Accessibility Tree is a subset of the DOM, that mirrors each element included in the DOM, but strips out the unneeded parts which wouldn’t be beneficial for assistive technologies. In short, this is what is presented to assistive technologies who want to digest and interact with a web page.

It is important to understand that how each browser builds its DOM and Accessibility Tree will be different. Also their support for newer markup such as HTML5 and WAI-ARIA might be limited. That is why it is important to test what you plan to implement with various browsers and assistive tech.

Understanding the DOM and Accessibility Tree doesn’t really matter, but being able to identify why something may, or may not be picked by assistive tech does.

Hiding content from the Accessibility Tree with CSS

Using CSS we can hide an element from the page using either display: none;, or visibility: hidden;.

Although other methods of hiding elements with CSS exist, both of the above CSS properties are most commonly used. They have one common problem: both are completely ignored by assistive technologies! Now the fact that they are ignored is not a bad thing, but it does lead to misuse, which in turn creates accessibility problems.

So let’s look at some examples of where it could go wrong.

Hidden form labels

JD Sports have many flaws with their website, but let’s only consider their search field for now.

Example of a labelless search input field, used on the JD Sports website.

Labelless search fields are quite common these days. They can impact accessibility in a few ways, but let’s just consider one: a field without a label. Now for assistive technology this creates a problem as the field will make no sense. For most it will simply be interpreted as an edit field. So to counter this we would add a label for the input field, to explain its purpose to assistive technology.

For purely the label aspect JD Sports do a couple of things wrong:

1. They correctly create a label for the input field, but don’t relate it to the field by using the label for attribute.

Incorrect:

<label>Search site</label>

Correct:

<label for="ID">Search site</label>

2. The input field for the search field also doesn’t have an ID attribute to map the label for to.

Incorrect:

<input name="freeText" type="text" />

Correct:

<input id="search" name="freeText" type="text" />

3. The final nail in the coffin though, and the one that we care about most in the context of this discussion, is their use of display: none on the search label.

I see this a lot! It drives me nutz, because knowingly, or not it defeats the purpose of the accessibility feature they have attempted to add. Of course though, not everyone understands that display: none;, or visibility: hidden; are ignored by assistive tech. In the case of JD Sports though, however had built their site is clearly a bit of a cowboy, who doesn’t really know what they’re doing.

So if you can’t hide it with display: none, or visibility: hidden then what do you do?

Display accessible content off screen

Well you can of course display it off screen, so that it is visually hidden, but can still be picked up by assistive tech. So in the case of JD Sports it would be something like so:

HTML

<label class="hidden" for="search">Search site</label>

CSS

.hidden {
position:absolute;
left:-10000px;}

Now this is my prefered method, but as Jonathan Snook correctly points out in his article hiding content for accessibility, this won’t work cosmetically for right to left languages. If you don’t have to concern yourself with RTL languages, then don’t worry. Otherwise use his suggested solution below:

CSS

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

Hidden navigation menus

Ok simple stuff, right? So what if we go for something a little bigger, like a navigation menu?

On the Poundland website, and countless others, they use display:none; to hide the contents of the drop down navigation menus until they are selected. Makes sense you would think. Let’s also assume that your dropdown navigation menu is keyboard accessible. It would still make sense, because when the user focuses on the top level navigation item, the child elements we assume will become unhidden? Wrong! We can’t predict that all users will interact with a web page in the same way. Keyboard navigation may be one choice – another option though might be to scan the page line by line with assistive tech, or use keyboard shortcuts to get where you want in a document before scanning its contents. This scenario wouldn’t work, as the child navigation items would be hidden from assistive techs view, so they would only pick up on the top level navigation items, not the hidden contents.

Example of Poundland hiding content from users of assistive tech, with display:none;.

Again an off left technique would work fine here, which can be toggled using JavaScript to appear back on screen when in focus. The rule of thumb for elements which can be navigated to using the tab key, is to bring them back on screen when focused upon.

There are some scenarios where you may genuinely require an offscreen navigation element which would never appear on screen when in focus. The BBC for example use an accessible skip link, for users to skip the navigation and go straight to content. Their implementation jumps to an off screen navigation link, which is excluded from normal keyboard navigation by setting the elements tabindex attribute to -1 (exclude from tab order), but still focusable by setting focus using JavaScript.

SEO and CSS off screen techniques

Now hiding content off screen for accessibility purposes is all good, but couldn’t that be abused to improve search engine rankings? Of course it could, but thankfully search engines are clever enough to know when someone is abusing this or not. Keyword spamming off screen might downgrade your ranking, and if bad enough remove you from search listings altogether, but providing accessible information and links will not.

Google Webmaster Tools, have an article explaining this in their help sections, titled: Hidden text and links.

Putting display: none;, or visibility:hidden; to good use

So when does it make sense to use display: none;, or visibility: hidden;?

Well most sites in the UK now have a cookie policy message which appears the first time you visit a website. This is now a legal obligation which sites have to make you aware of, they don’t require you to accept it, they just need to present it to you on your first visit.

The Scottish Government has an odd example which admittedly isn’t fully accessible in its current implementation, but makes a good use case for using display:none; (and it does).

Scottish goverment website example of using display:none;.

After you have seen this cookie policy once, you’ll not need to see it again. Likewise for assistive tech, if you’ve read it once, you can effectively ignore it. Making use of display:none; here to hide the entire element that contains the cookie policy, allows assistive tech to effectively never process it again. Next time you visit the site, the div (element) that contains the cookies policy popup will be hidden using display:none;. This means that users of assistive tech do not need to process it again. If they styled it to appear off screen like we’d suggested for the previous examples, then visually normal users wouldn’t have seen it, but assistive tech would have still picked up on it.

Play around with the Scottish Government example and see if you can spot their accessibility mistakes with this cookie control. There is also a blatant lie in regards to cookies. See if you can spot it. No prizes, but I’m keen to see if anyone can spot the mistakes. Using what you’ve learned so far you should be able to.

A checkout process might be another example of when it might make sense to use display: none;. You might require data to be entered into the current step, before being able to progress to the next. So if you didn’t use display:none; here, then you might confuse users of assistive tech who would be able to read steps that visual users can’t, for good reason.

Other problematic CSS

VoiceOver by Apple has accessibility issues when an element’s height or width is set to zero. An element with this style applied will be ignored. Enrique Palazzo as far as I can tell was the first person to identify this issue on a Drupal issue ticket.

Kent County Council at the time of writing introduce this issue for VoiceOver users on their off screen skip links.

Example of Kent councils websites, impacting Voiceover users, with a height and width of zero.

It is easily fixed though by increasing the width and height to 1px.

While we are on the topic of faulty skip links, the UK Government’s Digital Service website hide their skip link with display:none;. Interesting when it is supposed to be a pioneer for government digital content.

Example of the UK goverments Digital Service website, hiding their skip link with display:none;.

So using CSS to hide elements from the page isn’t a terrible thing to do in regards to accessibility. The main problem is the misuse of it, and being able to understand when it should, or shouldn’t be used.

Problematic JavaScript

Everybody and their mom these days uses JQuery. Why? Well it’s a lot simpler to do things in JQuery than it is in JavaScript.

JQuery has a lot of methods that present accessibility issues if misused:

.hide()
.fadeOut()
.fadeToggle()
.slideToggle()
.slideUp()
.toggle()

Each of these adds display:none; inline to the element, which depending upon the context of its usage, could present accessibility issues. So when using any of these methods, like in our previous CSS examples, it would only makes sense to use them, if the context of there useage doesn’t impact accessibility.

JQuery also gives you a few DOM manipulation techniques, that obviously affect the Accessibility Tree:

.detach()
.remove()

There are others, but these are the two most commonly used. The main difference between the two is that .detach() will allow you to bring the element back into the DOM, .remove() won’t. Again use with caution. In the case of a cookie policy message that is only ever viewed once by the user, either of these might be a good option.

Another problem comes from inaccessible JavaScript methods for adding content:

write()
innerHTML()

The problem with both, is that they don’t interact with the DOM. As such elements added via these methods most likely will be ignored by all assistive tech. So avoid these like the plague!

Build a bear is one of my daughters favourite shops. They commit a double crime, with their flash not enabled warning. Firstly they exclude it from assistive tech as the write() method isn’t interacting with the DOM. Next they write in an image, with no alternative description. So they may as well display nothing, for all the use it provides to assistive technologies.

Example of the Build a bear websites, no flash warning.

Obviously analysing Javascript adds a little more complexity onto your testing efforts. The most obvious way to test this, is to use some assistive technology to interact with the page, and see what is being picked up, or not. Personally I prefer to do some quick tests in developer tools, by inspecting inline and external JavaScript and searching (CTRL + F) for problematic methods, to see what they are doing. This way you can quickly identify where on pages they’ll be used, and test to confirm your suspicions with assistive tech.

Hiding content with HTML

There is a couple of attributes in HTML that can hide content from assistive tech.

Hidden input fields

The first is the input element’s type attribute. If the value of its attribute is set to hidden then obviously the field will be hidden from view. Assistive tech treats it exactly the same by ignoring it.

HTML

<input name="Language" type="hidden" value="English" />

It is actually quite a common technique, that is used on most websites, to store values. Back in the days of caveman development, when entire websites used to be constructed of forms to control layout, you could often see username and passwords being submitted in hidden fields as a form of access control. Thankfully those days are long gone.

So this technique isn’t so bad, depending upon how you use it. It’s pretty hard to mess this one up.

Alt tag

As a general rule of thumb if an image adds descriptive value to the context of a page, then add alternative text for it using the alt attribute. If it is purely for decoration, add the alt attribute but leave it empty.

HTML

<img src="randompicture.png" alt="" width="150" height="10" />

The above randompicture.png image if used purely for decorative purposes, would correctly have a null alt attribute value. Many assistive technologies will choose to ignore the element completely, as with an empty alt description, they assume it is for decorative purposes.

You might also add an image on a button with the type image, or a link anchor with an image inside it.

HTML

<a href="register.aspx">
<img class="overlaybtn" src="register.png" alt="" width="32" height="12" />Register</a>

In the above example you might confuse the need for adding alt text if the image overlaps the anchors link description. As the anchor already has a link description “Register” adding the alt of “Register” again would merely duplicate the content. For most assistive tech, duplicate content would be read twice, sometimes without any context, e.g. image alt: register, register link, might simply be processed as register, register link.

So it’s worthwhile noting that alt attributes with a empty value will be ignored by assistive technologies. Let’s not talk another further about the specifics of alt attributes and how to use them correctly, because that is a topic for another time, and already covered in great detail all over the web.

HTML5 hidden attribute

HTML5 brought us a new attribute called hidden, which when used hides the element it has been applied to from view.

As far as I could tell, all current browsers that support this attribute, simply apply a style of display:none; to the element. So effectively when used this will be ignored by screen readers, so use with care. As we have already discussed with the CSS technique, sometimes it is useful to use display:none; and other times it can impact accessibility.

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

<a tabindex="-1" href="#maincontent">Skip to content</a>

Hiding content from the Accessibility Tree with WAI-ARIA

WAI-ARIA introduces a couple of ways to hide content from assistive technologies.

The aria-hidden attribute

Sometimes it might make sense to hide visual content from assistive technologies. To do this we make use of the aria-hidden attribute. If you are displaying duplicate content because it fits with the design, rather than having the content interpreted twice by a users of assistive tech, you can hide the most sensible instance using aria-hidden.

HTML

<img src="decorative.png" alt="" aria-hidden="true" />

In the above example HTML it might even make sense to use aria-hidden to make sure decorative images are not read out by assistive technology. Although some assistive tech will ignore images with empty alt tags, not all will, so doubling up with aria-hidden=”true” helps our chances. I say chance, because support in both assistive technologies and browsers is a bit lacking.

Presentation role

The presentation role, is used to convey that an element is used for presentational purposes only. As such, these elements would provide no benefit to users of assistive technologies and should therefore be ignored.

HTML

<img src="decorative.png" alt="" aria-hidden="true" role="presentation" />

Again using the same example as used in the aria-hidden example, specifying an element with the presentation role, further increases our chances of it being ignored by assistive tech, but still having it remain visually on screen.

Specification example use cases:
1. An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
1. An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
2. An element used as an additional markup “hook” for CSS; or
3. A layout table and/or any of its associated rows, cells, etc.

So useful, but again lacking real support from browsers and assistive technologies.

Summary

So I hope you are now more aware of how elements can be intentionally, or unintentionally hidden from assistive technologies. There is a lot to consider, but the most important aspect, is to consider the context of the element/container in question before deciding if the technique is correct, or not.

Thanks for reading.

Summary

Often when a site is designed, developers will set the outline for navigation elements to none, or zero.  Effectively this means that when you try to navigate a website using a keyboard, visually you will have no idea where you are on the page which most often than not forces user to use a mouse.  This is fine until a user becomes dependent upon the keyboard for navigation – such users, who cannot use a mouse suddenly become severely impacted by the pages inability to highlight what they are currently navigating through.  Of course it’s not just an accessibility flaw, some people just like to use the keyboard to quickly navigate items.

Example of a link outline appearing when the user navigates links using their keyboard.

Why do people remove it?

Some people just hate the sight of a link outline.  Much like how visited links are often styled to be the same colour as non visited links to the detriment of accessibility and usability, simply to appease a design – the good old link outline can often suffer the same fate.

Interactive elements controlled using Javascript and styled for example as oversized fancy call to actions are often the first to suffer, as 99% of the time these controls are just link anchors styled and controlled using JavaScript to appear all fancy and interactive.   If the developer hasn’t already removed the link outline, you can guarantee that when someone sees the outline around their beautiful call to action, a complaint that it doesn’t look very nice will follow.   The outline will likely later be removed, without a suitable keyboard accessible alternative put in place.

Applying and removing link outlines

Outline can be applied using the CSS :focus selector on a targeted HTML element like below:

a:focus { outline: 1px dotted; }
selector:pseudo-class { propery:value; }

This declaration essentially says that for all link anchors (a tags) when they have focus, apply the property outline with a width of 1px, dotted.

a:focus { outline: 0; }

The above will have the reverse effect, by removing the link outline for all anchors.  This now impacts keyboard accessibility.

So what if I still don’t want to apply a link outline?

Not setting an outline is fine, as long as you can provide an alternative style for it.  The main objective is to provide keyboard accessibility here, so as long as you have a suitable alternative accessibility will not be impacted.

Rather than using a link outline, perhaps changing the text colour when the link is in focus would be a suitable alternative.

Example of outline removed with the text colour change replacing it when the link is in focus..

This can be easily achieved with a little tweak to your CSS:

a { text-decoration: none;}

a:focus { outline: 0; text-decoration: underline; color: red;}

So now we are essentially telling anchors which don’t have focus to not underline their text (text decoration = none).  Anchors with focus now also have their outline removed and instead have their text underlined and in red.  Very simple and design wise and probably an improvement for visual indication of an item in focus.

As long as you maintain a good colour contrast for alternative styles when you choose to not use outline for elements in focus and keep a decent level of consistency in terms of colour choices, then accessibility should not be impacted.

Is that it?

As long as you ensure that all interactive and navigation elements on a page have a focus effect applied for keyboard navigation then you should be fine.  A good rule of thumb to use for this would be checking if anything with a hover (mouse over) effect, also has an equivalent keyboard accessible focus effect.  Manual inspection would still be required though, to make sure nothing was missed that didn’t have either a hover or focus effect.

Compatibility issues with older browsers

Now is probably a good point to highlight the issues that will arise with solely relying upon the CSS :focus selector to apply highlighting for items in focus.  On older versions of Internet Explorer (IE), the :focus selector wasn’t supported, so to get around this we use another selector :active.  Active will allow you to style currently active elements on IE6 and 7, but for IE7 it will only work on anchor elements (links).

If you don’t want to be limited in IE7 to anchors, you can make use of a JavaScript library called IE7-js (actually a series of library’s for IE7-9), which will allow you to make use of the: active selector on other elements just by loading the library via a conditional statement in your document.  If you want to go one step further and don’t need to support IE6, you can ignore :active and gain support for the :focus selector in IE7 by including IE8.js in your conditional statement.

How do I test for this?

The simplest test would be to check page navigation with the keyboards tab key, to check if an outline or alternative style is applied around the element in focus.  If it doesn’t, then this means a style has not been considered for keyboard navigation.

Another quick test would be to open developer tools (F12 on most browsers) while viewing the web page and inspecting the sites style-sheets.   A good rule of thumb here, is that any declaration that has :hover set on a selector, should also have both :focus and :active equivalents.

Example of a good declaration, which includes :active and :focus for keyboard navigation styles.

Sometimes though, poor markup implementations affect your ability to target elements for styling. This usually occurs when non standard markup is used for interactive elements in combination with JavaScript event handlers such as onclick to provide some form of interactivity e.g. onclick="window.open('http://www.someurl.com')" (on selection, open in a new browser window this URL). So it is always important to go over navigation elements with a fine comb to weed out anything you may have missed.

The last test is actually an oddity which is rarely done.  Sometimes HTML elements on a page which would not normally be included in the keyboard navigation cycle are forced to be included by assigning the tabindex attribute.  There may be a good reason for doing so, but I’ve yet to see one.  Normally depending upon how your stylesheet has been configure for elements, these items would be excluded from keyboard accessible visual indicators such a outline.  Unless you can justify a good reason for them to be included in the tabindex, I would normally suggest removing them.  Every browser worth testing these days automatically indexes HTML elements which should be included in the tab order, so taking over its control to include non standard elements often impacts accessibility, so be careful.

Thanks for reading.

Summary

In the following article we will look at the impact of not maintaining a logically document structure and misusing Cascading Style Sheets (CSS) to visually present it as correct.  We will look into why people would want to do this, how to identify the problem and how to resolve it.

Understanding the document structure

HTML by its nature allows you to build up a website logically, to form some sort of sensible structure.  This allows the reader of a website to digest it as it was intended to be read.

With the introduction of CSS the presentation, or graphical representation of a website, is separated from the code (mark-up) which structures and allows a site to function correctly.  While this clear separation between code and visuals is extremely useful, it presents problems in itself.  One of these major issues is the misuse of CSS to position elements on a page, far out-with their actual location in the document structure.

A typical site may be structured in the following order, which when navigated by an assistive technology such as a screen reader, should read in a similar order left to right, top to bottom.

How a typical web site is structured.

So in the above example we would expect assistive technology such as a screen reader to read out the logo, then the main nav items, followed by the search, local nav and then onto the main site content.    This all makes perfect sense, but sometimes developers will chop and change elements in the structure of the document, using CSS to absolute position elements wherever they want them to be.  Visually the site will look the same, but as the structure doesn’t flow logically, users who are dependent upon keyboard navigation will be affected.

Consider that a HTML page at the highest level would be structured as such:

<html …>

<head>….

</head>

<body>….

</body>

</html>

In the body of the page we might have a series of div elements which section up the structure of the document, like below:

1. top
2. search
3. localnav
4. maincontent
5. rightblocks
6. footer

How it can go wrong

If the div “search” was moved to the bottom of the structure, but positioned using CSS to still appear at the top of the page, any assistive technology that then attempts to digest that page would have to navigate through the entire document to locate the search field.  That user may be one hundred or so elements deep into the page before he finds what he is looking for.  If you positioned your site search at the very bottom of your page visually people would find it completely unusable (if they ever found it), so why should keyboard accessibility be any different?

A solution to one problem, introduces another

Why would people do this in the first place?

Good question!

One reason is that some sites like to optimise themselves to meet Search Engine Optimisation (SEO) targets.  If for example you stripped everything above the main content area out (logo, nav and search) and placed it at the bottom of the document structure, from an SEO point of view the crawler would go straight to keyword rich and highly weighted elements, such as your header 1 page title and page article content.  The theory is that the first items a crawler see’s gain more SEO weighting, and the further into your document structure it goes, the less value keywords will have.  So for SEO, you can see why some people would want to do this without necessarily thinking about the negative impact it may have on other user groups.

Another reason is actually a flawed accessibility improvement.  Often without thinking it through properly, the top section of a page (logo, nav and search) will be stripped out and placed at the bottom of the document structure.  The thought would be that this would save users of assistive technologies time by taking them straight to the content and by passing some countless number of links each time they access a page and want to view its main content.  If this is done for every page it would save them a lot of time by going direct to that pages content.  Obviously though this is a flawed concept, as users would then be left confused as to how they navigate the site, or execute site searches since they are no longer present where they would expect them to be, at the top of the documents structure.  If both pieces of functionality are 100 key presses away, then you’ve probably lost them as a user and they’ll go elsewhere for their information.

There are two very powerful accessible solutions to take people directly to content without having to chop and change the location of code.  HTML Skip links are one and ARIA navigation landmarks are another.  I will discuss these techniques in more details in later articles.

So how do you test for this?

Probably the quickest way to test if your web pages document structure  is correct, would be to open your browsers developer tool kit (usually F12) and inspect the mark-up manually – not everyone is comfortable in doing this though.

The easiest way to test the reading order of the document structure is to disable CSS on your browser.  After doing this you will be able to see if the page follows the same flow as you’d expect, or if items like the main navigation have been relocated to elsewhere in the document structure.

Easier still the WAVE toolbar gives you the option to highlight where something is in the document structure at the click of a button, to identify any issues by intelligently placing a numbering system next to HTML elements which can be navigated by the user:

Using the WAVE toolbar to help identifying page components location in the document structure.

Conclusion

Playing around with your document structure can have dangerous negative side effects, which depending upon the extent of changes made, can dramatically reduce the accessibility of your website.  Obviously this should be avoided at all costs.

Developing a document structure strategy for your web pages can proactively avoid such issues and from the consistency it brings throughout your pages/templates, it will help you easily introduce further accessibility improvements such as ARIA Landmarks and skip navigation links.  It also helps speed up the initial production of markup and CSS, while also making them easier to maintain going forward.

Be nice with your HTML and thanks for reading.