Dealing with User Text Enlargement for Accessibility

To make layouts work right when people use the Text Size option on the View menu in IE (or the Text Zoom option in Netscape) to enlarge their text size, don't panic, but do be aware it can get complicated. We optimized the file 3-column-float-based-page.html and called the new file 3-column-float-based-page-2.html, and it deals with this issue better than the 3-column-float-based-page.html file. You may compare the revamped file with the original if desired and see if you can guess what the changes were and why we chose them, or wait until you run into our discussion of it a few paragraphs hence. Note: in order to try out text expansion in IE you (as well as vision-challenged site visitors) need to go to the Internet Options option on the Tools menu, press the Accessibilty button, and check the ignore font sizes specified on Web page box.

Anyway, here's what you'll need to know to deal with this issue: Many people say that if we use relative font sizes like em units or percents, text enlargement problems mostly disappear, while using pixels (like most site designers seem to) is absolute, and these same people say pixel use prevents text size increase when a person uses their Text Size option. Such people cite all the problems that the pixel units cause. They say that points are even worse than pixels. Others swear by pixels and cite all the problems that the relative units cause. We side with this latter group since so many people design with pixels that the browser makers are accomodating people with accessibility needs by making the enlarge text for accessibility feature work in spite of pixel units being used for text size. When some people say that using pixels won't let text get bigger when a person uses their Text Size option and "there is normally no workaround for this," they're incorrect: all the visually challenged person needs to do is to go to IE's Internet Options option on the Tools menu, press the Accessibilty button, and check the ignore font sizes specified on Web page box, as we've already pointed out. And with Netscape7 the Text Zoom works without complications.

Note that there are experts siding with pixels and others siding with ems for general website design as well as for the text-enlargement accessibility issue. But more interesting is the way books mostly either ignore the subject or say design with ems and there will be no problems. This turns out to be not quite true, although we can't fault anyone for using them: it seems totally appropriate to do so, but it's not problem-free. E.g., when you try to specify text size that's smaller than the user's default size, ems will put your well-designed website in a world of hurt, as many designers have learned, to their dismay. Some have said upgrade to IE6 and many problems in this area will go away. It's worth a try. But right off the bat relative units can bite you in the butt: if your body tag text is set to 90% with CSS and CSS rules you've made also put the p tag at 90%, the paragraph text will be displayed at 90% x 90% or 81% due to parent-to-child inheritance. You see where this type of thing can lead? Author Jeffrey Zeldman swears by pixels as the best all-around performer, but admits that the older browsers will make text enlargement nearly impossible if you use pixels. But since special needs people can update to IE5.5 or 6 or NN7 for free anytime they please, if they're seriously concerned with text enlarging, they'll ask their dealers or get on a user group and soon find the simple, free solutions to dealing with the pixel-loving world. So this turns out not to be much of an issue after all.

Now, let's look at what we did to the 3-column-float-based-page.html file to make it work better: When you maximize text, the top paragraph of the middle column overlaps the bottom paragraph. We changed the left column to be absolutely positioned. The left property value of 79.5% that is used in the right column places it correctly on the page in the revamped file, while in the original we used the left margin property of 79.5% in the right column. But we changed the center column to be in the normal flow (a very popular idea), so the two center column paragraphs flow (the bottom one scoots down) and expand rather than overlap when the text is enlarged. If it isn't obvious, this should lead you to the conclusion that column paragraphs vertical to one another should be static (normal flow), and not fixed or absolute, to avoid overlap potentials.

So margin-based layout isn't as effective as keeping positioning static (normal flow) in the center and absolute elsewhere, especially where text expansion for accessibility is concerned. This method seems to help footers behave well too. We commented out the 28 break tags we'd needed in the original file for the purpose of insuring no footer-and-column collisions. The revamped file didn't need this. Breaks are used in general to insure that footer collisions won't happen when the longest column happens to be absolute rather than static, so the footer can't be pushed down via flow by the shorter static column until it's too late—the absolute column is all over the footer like a bad suit. On another note, remember to use relative column widths so that higher resolution monitors get wider columns than lower resolution ones.

Finally, let's look at one of the worst problems of all to solve: div width increase when enlarged text is chosen. It normally won't happen on wider columns. It's a narrow column curse. Normal div enlarging happens downwards when text size is enlarged. But let's say you have a really long file name or some JavaScript code you're displaying in a relatively narrow column. Or let's say you use a line of underline characters rather than a horizontal line or div border as a column item separater. Your goose is cooked, if you're using a narrow column, since it will widen the column until it overlaps its neighbors when you test text enlarging. Here are your options:

• shorten words, file names, JavaScript codes
• add spaces wherever possible so you get the word wrap you're seeking, since browsers' inability to find a space to stop the line with is the problem
• use a narrower font
• don't use underlines, periods, hyphens, Bill Gates' net worth, etc. as div box dividers unless you make them short and centered
• space columns farther apart
• avoid colored divs so at least then one can still tell what the words are in spite of overlap
• create a JavaScript routine that uses a different CSS style sheet after detecting a text-enlarging person (How? You tell us—we're all ears.)
• put a link at the top of problem pages that lets accessibility-challenged visitors select a specially prepared version of the page