Tutorial: Progress bar
One of the most often heard gripes about accessibility is that it supposedly forces developers to build ugly websites. This is not true, but to get some of the pretty stuff clients and users want, we do need to change our thinking on some subjects. One of those is how we utilize visual effects and graphics. There is a true conflict of interests inherent to accessibility and usability here; for non-sighted users graphs are almost entirely useless while for users with disorders relating to their comprehension of written text – such as dyslexia- a visual representation of complex data is very helpful. In this three-part series of articles, I will delve into the visual representation of data, starting with the most common; the progress bar. I will show some tricks and techniques, and explain how to –as best as is possible- alleviate the problems users with no or limited sight inevitably will have with these otherwise very useful site features.
Accessibility made simple
Accessibility at times seems to be a serious ball-and-chain proposition for designers and developers alike. The very nature of the WCAG guidelines is one of restrictions and imperatives. Although I sometimes disagree with them, I do hold the WCAG guidelines to be authoritative. But reading through them they do read as if you should give up two-thirds of your toolbox. In this series of articles I intend to provide simple and pragmatic approaches to using most of your toolbox without sacrificing unreasonable levels of accessibility. Accessibility is not the goal of design; it is a tool to do better design. Some of my tricks do bend or even break the rules, as far as I am concerned this is quite OK, if you provide a reasonable alternative for those with limited access. Where appropriate I will also provide tips on how to do that.
The progress bar
Providing the user feedback regarding what the interface is doing, the status, is often a requirement for accessibility and usability. If not, it is still strongly recommended by experts. A progress bar is therefore a useful feature when your interface gets to be busy sometimes and needs the user to wait. Many interfaces, such as the Windows and MacOS operating systems will provide an alternative cursor with a spinning hourglass or something in a similar vein to notify the user that the machine is busy. While definitely a good thing, it is not enough because it does not convey to the user how long the wait is going to be.
Non-sighted users
Non-sighted users are not helped by, for them often arcane and abstract, concepts as ‘a tall yellow bar‘. Get the graphs out of their way by placing images in the background rather than in the flow of the document and so on. But be wary of totally hiding information from non-sighted users. Be aware that non-sighted users may still share information with sighted users, so knowing information is there is usually a good thing. Rather than totally hiding information, it is usually best to provide an alternative. For a graph, which represents 30% of something, this could quite simply be a label saying “30% of …”
The case
When a website presents a progress bar or graphs, these are usually presented using non-accessible techniques such as (static) images or Flash. Some statistics packages provide text alternatives using regular keyboard characters. While this eliminates some of the accessibility issues associated with graphics it isn’t necessarily helpful for non-sighted users and usually quite limited visually, not improving matters for the rest of us. Bear in mind that many non-sighted users live in a world of no picture whatsoever. Asking them to visualize a set of bar graphs by having a series of #-es read to them in a graph-like configuration is akin to asking someone to visualize the smell of music. So we are stuck with providing an alternative, and since we are we might as well focus on improving the usability of graphs for the rest of the world.
The problem with images
- Non-sighted people can’t see them; many visually impaired people can’t see them well enough. Especially text in images is a major issue.
- Images are considerably larger in terms of kilobytes than plain text; this means they lengthen loading times considerably. For users with slow connections such as people living in rural areas where satellite or dialup connections are the only options, people with a limited budget or using mobile devices this is a major stumbling block.
- Images can easily get in the way of the way the eye moves over text. Reading from a screen is a lot more tiring than from paper as it is, each time you make the user’s eye ‘jump’ left or right to catch up with the text you are adding to this burden.
The advantages of visual representation
- Complex data can be presented ‘at a glance’, drastically improving usability for, for example, users with dyslexia or other issues relating to reading ability.
- A visual representation of highly transitory information, such as the progress of a download or running process can drastically improve the usefulness of such information.
A few tricks and techniques
This tutorial hinges almost as much on bringing the above information to your attention as it does on actually showing you how to do things. The techniques described below are therefore only some examples of a wide gamut of options, please feel free to explore, experiment and be creative.
A progress bar
Assuming you are somehow feeding progress data into your site, this is one way you can then utilize it.
Place a DIV where you want your progress bar to be. Make it as high and as wide as your layout dictates. Take up as much space as you can spare and try to make it at least 18 pixels high to accommodate users with some, but limited, sight.
Inside this DIV, place a second DIV. Give it a useful starting value for width above zero. Then rewrite your HTML dynamically to change the width value of your DIV. The height can be set using pixel values or whatever else works for you, the width, usually will need to be set in percentage values.
Be sure to differentiate between the two in as many ways as possible, take care of contrast and line style. Some users need high contrast, others will have colour disabled or have a form of colour-blindness. I used black versus grey, and dotted versus a solid line. As a base, this should do to ensure most users are able to differentiate between your foreground and background.
A very basic bar with no graphics
The code:
<div style="height: 18px; width: 200px; border: dotted 1px gray">
<div style="height: 18px; width: 30%; border: solid 1px black;"> </div>
</div>
But we were trying to make attractive graphs, so this puppy needs some more work. So far I have used in-line CSS to make my point. This defeats the purpose of CSS; separating styling from content. I am working from the assumption that this technique is to be used with some sort of page rewriting, and rewriting external style sheets as well as HTML is both risky and without added benefit. However; you really should separate as much of your styling from your content as you can, so from here on out, all extra styling goes where it belongs again.
A cuter puppy
For starters, we have the infamous box-model issues between browsers. There are several ways to deal with them, including hacks that involve writing separate styles for different browsers. Personally, I don’t like those. People choose a browser based on personal preference, albeit a small part; the way it handles the rendering of HTML and CSS is part of this. The web is not print. Therefore I prefer a solution that will gracefully adapt to how the browser renders it.
So, we add one more DIV to provide a restraining block for our progress bar. This makes placement within your layout easier. Having done that, there is no longer any need to place the two progress-bar DIVs inside each other to force them to overlap, but instead we can use absolute positioning and z-index.
The code:
<div class="container">
<div class="full"> </div>
<div class="indicator" style="width: 30%;"> </div>
</div>
The CSS:
.container {
position: absolute;
width: 200px;
height: 18px;
margin: 0;
padding: 0;
.full {
position: absolute;
left: 0;
top: 0;
border: dotted 2px gray;
width: 100%;
height: 18px;
z-index: 10;
}
.indicator {
position: absolute;
left: 0;
top: 0;
border: solid 2px black;margin: 0;
height: 18px;
z-index: 20;
}
I use 10 and 20 for z-index while obviously 1 and 2 would do, this is a habit I picked up when as a kid I taught myself programming in GW-BASIC, it gives me room to later add an intermediate layer, should I want to. Other than that this is pretty straightforward. We are basically doing exactly the same as before but because we are now using absolute positioning within a container DIV, we have greater control over our boxes and, more importantly, are no longer bothered by box model issues across browsers; after all, no matter how the browser treats the box, it will treat both the same, and they are both exactly on top of each other, both positioned at exactly zero pixels from the top and zero pixels from the left of the container. No more lines sticking out where we do not want them, therefore, and should we want to position our progress bar inside a more elaborate layout, we only have to worry about positioning the container.
Not done yet
Before we pretty up this progress bar, we should spend a bit more time thinking about accessibility. We’ve got pretty decent contrast for those who need it. But how about those who turn off styling altogether, use a screen reader or don’t display CSS borders and colours?
Well, we provide them with an alternative, obviously. This, at least is simple: We add the progress percentage written out.
The code:
<div class="container">
<div class="full">
</div>
<div class="indicator" style="width: 30%;">
<p>30%</div></div>
The CSS:
.full {position: absolute;
left: 0;
top: 0;
border: dotted 2px gray;
width: 100%;
height: 18px;
z-index: 10;
}.indicator {
position: absolute;
left: 0;
top: 0;
border: solid 2px black;
margin: 0;height: 18px;
z-index: 20;
}.indicator > p {
font-family: "lucida sans", verdana, arial, sans-serif;
font-size: 14px;
line-height: 18px;
margin: 0;
padding: 0;
}
My choice of font is really only based on personal preference although it is recommended to use a sans-serif font for use on electronic screens, and a serif one for print. I like Lucida sans, but I provide Verdana as next alternative because it was tested (by a slim margin) as the most readable. Then I provide Arial as second alternative because it appears to be most widely available, and finally of course, I specify a generic ‘sans serif’ just in case none of those fonts are on the user’s computer.
Now it’s also clear why I said to make the boxes at least 18 pixels high. The WCAG states that between 14 and 18 pixels are the minimum sizes for ‘large print’. Since the percentage is a very short bit of text which sits on it’s own without many detractors around it I figured 14 pixels would be acceptable, then I set the line-height to 18 pixels to more or less centre the text vertically. Beyond that I am leaving the text alone; you do not want to interfere too much with what the user has specified for text display, the user knows best what is or isn’t comfortable for him/her.
Spicing it up
Now we get to do the bit most designers like best; add some pizzazz. We could settle for a foreground and background colour, and frankly; often you should. But some fun should be allowed now and then… all accessibility and no play… And this is a good time to let the ‘Sliding doors’ trick out for air. (http://www.alistapart.com/articles/slidingdoors/) In a simplified form, at least. Do check out the full tutorial, it’s quite good.
First for the simple bit, a background for the main bar: since we know the dimensions of this element, that’s an easy one.
Adding a background
The code:
Actually hasn't changed.
The CSS:
.full {
position: absolute;
left: 0;top: 0;
border: dotted 1px gray;
background: url(progress-bar-bg1.jpg) no-repeat top right;
width: 100%;
height: 18px;
z-index: 10;
}
As you can see, I merely added a background to the main box. Since this image is purely decorative I advocate as must-do to place them through the CSS background attribute so as to keep the number of irrelevant images in the flow limited. Remember that screen readers will announce the presence of each and every image they encounter. This gets annoying really fast.
Now for the slider: we do not actually know its dimensions at any given moment. It is after all, a slider. So here we use a sliding door: in a nutshell, we chop the image in two bits and allow them to slide over each other giving the impression of a large image which scales with the slider. For a full tutorial, use the link I provided above.
"Sliding doors" background for the indicator
The code:
Still hasn't changed.
The CSS:
.indicator {
position: absolute;
left: 0;
top: 0;
border: solid 1px black;
background: white url(progress-bar-bg2.jpg) no-repeat top left;
margin: 0;
height: 18px;
z-index: 20;
}
.indicator > p {font-family: "lucida sans", verdana, arial, sans-serif;
background: url(progress-bar-bg3.jpg) no-repeat top right;
font-size: 14px;
line-height: 18px;
margin: 0;
padding: 0;
}
Since both the DIV and the P residing in it are block elements, and of the same dimensions, it is fairly safe to use them for our sliding doors. Obviously, more trickery may be needed if you up the complexity of your code. Quite simply, I added the left side of the background image to the DIV and the right side to the P. Using CSS background again. When doing this; mind the contrast! I am merely providing examples here, so its all pretty non-spectacular, but I’m sure you can come up with something stunning.
One last consideration
If you are going to be reloading your page a lot to feed it the new percentages, consider putting your progress bar in an I-frame and reloading only that part. Reloading large pages almost always introduces flicker. Flicker looks bad, but can also in rare cases induce seizures with people who have certain types of epilepsy. Automatically reloading pages also become pretty much unusable for a wide range of users.
Yet to come:
- Part 2: Using the trick from “get your images out of the way” and expanding it to provide users with limited sight an enlarged view.
- Part 3: Attractive and accessible bar graphs.
Happy web-building!
For another take at basically this same trick but with a snazzy animated effect, check out: http://cssglobe.com/post/1468/pure-css-animated-progress-bar
1 Comment
Pingback by Portfolio David Dylan Jessurun — September 15, 2009 @ 4:26 pm
[...] tutorial picks up where ‘Attractive graphs part 1: A progress bar’ leaves [...]