Accessibility & Usability

The Web Content Accessibilty Guidelines 2.0 April 30th Candidate Recommendation defines large text in
this glossary entry.

If you are designing your own site, you can just play-it-safe and treat everything as small-scale text unless it is very large and bold. But if you are advising clients on whether they need to make corrections to a pre-existing site, you really need to know if something is large-scale text or not. This is because large-scale text has less-strict contrast requirements in the new WCAG guidelines.

Below, I use css and points to define some text as 14 point bold and some text as 18 point not bold. These are the two minimum sizes for text to be considered large-scale by the definition mentioned. This text seems to stay that size regardless of the screen resolution used. The numeral 1 shown in 18 point text is one fourth inch high, if a ruler is held up to the screen.

• 14 point bold
• 18 point

On devices where there are 72 pixels in an inch, this should be the same as 14 pixels bold and 18 pixels. But we can't count on screens being like that. On my screen, a div sized to be 72 pixels is smaller than a div sized as 1 inch. The one inch div measures one inch if I hold up a ruler to the screen. I believe the items sized with points and inches will be same when a ruler is held up to the screen for all screens where the software involved is working correctly. However, items sized in pixels and ems will vary.

Below I've placed three div boxes on the screen. One is sized using pixels to 72 pixels. The next is sized to 96 pixels. The third is sized using inches to 1 inch. From what I've seen so far, the 1 inch box stays the same size across screens. The 72 pixel and 96 pixel boxes vary.

To match the box experiment, on this particular screen, which is 96 dpi like many modern screens, fonts sized with pixels are smaller than those sized with points. I expect the fonts sized with pixels to vary screen to screen while the points should remain the same, if the software is operating correctly. Below some text is shown sized with pixels. On my screen, it is smaller than text sized with points.

• 14 pixels bold
• 18 pixels

Now, if I use software, like the Windows XP Operating system, to increase dpi from 92 pixels to 120 pixels, the software can't really do anything about the size of pixels on my screen. So it simply makes inches larger. In other words, it now draws inches using 120 pixels. When I hold a ruler up to the 1 inch div, it is actually 1.25 inches. Similarly any inch-based measurements, like points, are drawn with 25% more pixels as well and become larger. However, any measurements based on pixels stays the same size as before I used software to change the dpi. This is because the hardware pixels are still the same size. The 96 pixel div still measures 1 inch if I hold my ruler up to the screen, because the screen is still a 96 dpi screen.

Points should work the same way as a point should be 1/72 of an inch. To make this easier to test, I'll create a 72 point font below:

Measuring from the top of the 7 to the bottom of the p in the 72 point text, is is -about- 1.25 inches when dpi is set to 120 using software on a 96 dpi monitor - actually a bit smaller, which might be because of the particulars of the font style.

However, if we use hardware to increase the dpi, we'll get the opposite effect: instead of inch-based measurements changing and pixel-based measurements staying the same, we'll see inch-based measurements staying the same and pixel-based measurements changing. This seems to me, more like the real definition of dpi. There are physically more dots in an inch, so the pixels are actually smaller, so items sized using pixels are also smaller. Items sized based on inches stay the same, because calculations are made to achieve a specific real-world length.

Finally, I should mention using software to change screen resolution. In this case, at least on my current set up, everything is changed in proportion. For example, I changed the resolution to a low 800 X 600 and everything increased in size. But the inch-length div and 96 pixel-length div remained the same size, reflecting the underlying 96 dpi. The software simulated both inches and pixels as larger.

96 dpi appears to the most common screen resolution these days. I checked a Mac OS X laptop, a Windows XP desktop, and a Windows Vista Ultra Mobile PC. All used 96 dpi. And the guidelines' definition of large scale text includes, "This success criterion is based on common pixel sizes available today." So, it appears, you can do the math based on 96 dpi or you can make sure that you are using 96 dpi and then compare the font in question a font that is set to be 14 point bold or 18 point not bold. If you are using 96 dpi, a div set to 1-inch should be the same size as a div set to 96 pixels. If your screen resolution is set to the optimum resolution for your monitor, then that will actually measure 1 inch if you hold a ruler up the screen, but that doesn't really matter.

So, sizing in pixels at 96 dpi, "at least 18 point or 14 point bold" is at least (18 times 1.25, rounded up to nearest pixel) 23 pixels or (14 times 1.25, rounded up to nearest pixel) 18 pixels bold.

Many "accessible" web sites don't zoom well.

Zoom without horizontal scrolling is important for accessibility and for mobilization.

Screens getting smaller is the same, after all, as contents of the screens getting larger. It is all about the size of the content increasing in proportion to the size of the screen.

Ideally, without changing user perferences, without special tools, without custom style sheets, Web sites could be zoomed using standard browser features.

Who can make use of this?

• People at home viewing the Web from the sofa, through a computer, or a through a game console such as Nintendo's Wii (See what it is like to surf on the Wii.)
• People in corporations surfing for information together using a computer with a projector
• People with low vision using a standard or large computer monitor
• People with very high resolution monitors, which make default text sizes very small
• People who work on the Web for long hours and wish to avoid the potentially harmful effects of hours of close-reading (This may or may not be a benefit for you . . . Consult your eye doctor.)
• People viewing the Web on small devices with small screens

How to try this today

Combining Voice Control & Zoom

Could this be a primary Web-viewing senerio in a couple years?

How I made this site zoomable

• Size fonts using ems instead of pixels (It's not as bad as it seems at first! You can use pieces of ems, such as 4.02em. To get any size you need.
• Make sure that the basic visual appeal of the site is created through elements that expand through css.
• Size container elements using ems as well. This way their size increases when the text size increases. Percents don't work as well because percents are percents of the container element or of the screen, which may not increase as the text size increase.
• Create a layout where the elements stack. For example, even though layout tables will stretch and shrink, they won't stack. This means that eventually, as the screen gets smaller, or as the text gets larger, the table will require left/right scrolling. In contrast, the menu at the top of this page, changes formation as the text gets smaller relative to the window size. The menu items are stored in divs with float: left; to cause them to line up from left to right. If the entire page can stack into a thin column, the page will zoom well and will work well on mobile devices.
• Define break-points for long words using wbr tags, as was done for the large heading at the top of this page. wbr is deprecated and perhaps one day we can use zero-width spaces instead. However, as of right now, wbr appears to work in the major browsers. Once zero width spaces are support to the extent that they work, we'll have to check and see how screen readers handle those word . . . here's to hoping they don't read the words as thought there's a space. Here's a chart of screen reader tests I've done so far for wbr:

  Reader	wbr ok?
  IBM HPR 3.04	No
  JAWs 7.0	Yes

• If you can't set up your layout to become a single a column as the window shrinks, make sure that options like Firefox's View > Page Style > No Style work to create the single column. ----list of these options ---- The main issues I see with this optin is that users might not know it exists and often design elements are lost. Ideally, Web pages would maintain visual appeal as they transform for different users.
• Another fall-back option is to provide a style sheet through a link that allows a single column. The user could select this, or JavaScript could be used to analyse when it is needed. (I plan to write an example js for this . . . )