Nose to the Page (3)

Posted on

Nose to the Page

Note: If you have trouble with this blog format try reading this at my site: Tools for Access to Reading.

Tools for Access to Reading

My last blog, “Myths About Low Vision” seems to have caused more confusion than clarity.  Developers, being practical people, wanted to know what to do. I admit my goal was to shake things up some. Now that I’ve gotten you to think about blindness and low vision as distinct disabilities, I should tell you some practical ways to help visual readers with low vision (VR/LV) do what they need most —read with their eyes.

The Fundamental Principle of Visual Access: If you can’t read text, you can’t use it.

Reading is the barrier.  Without reading there is no access.  Here are some accessibility tips that can improve visual reading with low vision.  The normal reader will see no difference, but the reader in VR/LV will be able to transform the text easily.

Nose to the Page Reality

Screen  and Line Density

The average visual reader with low vision gets between 1/4 to 1/16 of the information per screen as compared to normal readers.  Web users with full sight can read between 400 to 500 words per screen effectively.  Visual readers with low vision who need enlargement to read will require between 25 to 125 words per screen.  I call this number thescreen density.  If you have full sight, think about the difference between screen density that you need to read a long document (15+ pages of 12 point text) on your computer, and the screen density you would need to read the same long document on your cell phone.

Screen density is a better measure than font size because it works as well for the enlargements needed by low vision users on a computer, and fully sighted users on a cell phone.  Many factors influence density: spacing (line, letter and word), margin size, font size and font face.  It measures the number of content units one screen delivers.

The Screen Density Principle: Every visual reader should have access to information that provide the screen densities needed for effective perception, and all information must be perceivable using vertical scrolling only.

By using built-in commands on your commercial browser, you should be able to enlarge a document to a density of 100 to 125.  That is a good benchmark.  If a page looks good with screen density of 100 to 125 then it is usually good to go.  If it looks funny at that density, then most of VR/LV will have difficulty reading it.

Compared to audio that delivers one word at a time, a visual screen density of 100 delivers a lot of information in one block. That is why many people with low vision use vision to read, or visual reading synchronized with audio.  Visual reading provides a larger content window than audio.

Another measure I use is the line density.  It is the square root of the screen density.  It measures the number of words (content units) in a line across a page.  If a page is double-column or single column with a screen density 100, then its line density will be the same value 10.  The single column page will average 10 words per line.  The double column page will have 10/2=5 words per column-line.  With four columns you get 2.5 words per column-line.  That is a ridiculously small number of words per column-line.  I recommend using no more that three columns on a page.

If you have a ragged page there may only be a few lines with text across the page.  Just count the number of words in an average line of text and square the result. That is the approximate screen density.  Remember, count all the way across the page if you have multiple columns.

Style Sheets for Testing

Below are some style sheets for testing.  The first style sheet below gives screen density of about 100-125. In terms of spacial management the layout gives a reasonable readable environment for many people in VR/LV. The second style sheet is a comfortable reading environment for fully sighted readers although the columns are a little wide.  Typically dense text uses multi-column format at the same density.  I used the “!important” operator so you can just overlay these style sheets on any web page to see how it looks at the given screen density.

For low density (larger print), adjust font size in the first style sheet.  Just change the constant value 2em on the line, “body > * {font-size: 2em !important;}“, to whatever value you want. The value 4em will give you 25 words per screen approximately.

In the second style sheet I stripped the extra letter spacing because fully sighted readers do not need it.  I also increased the margin a little.  Change the 1em to some fraction for higher density.

@charset “utf-8”;
/* Screen Density 100 to 125 */
* {font-size: inherit !important; 

font-family: “Tahoma” !important;
font-style: normal !important;
font-variant: normal !important;
font-weight: 500 !important;
line-height: 1.3 !important;
letter-spacing: 0.03em !important;
height: auto !important;
}

body {font-size: 17pt !important;

padding: 1.25cm !important;
}

body > * {font-size: 2em !important;
}
/**** End of Screen Density 100 ***/

@charset “utf-8”;
/*** Screen Density 400 to 500 ***/
* {font-size: inherit !important; 

font-family: “Tahoma” !important;
font-style: normal !important;
font-variant: normal !important;
font-weight: 500 !important;
line-height: 1.3 !important;
height: auto !important;
}

body {font-size: 14pt !important;

padding: 1.75cm !important;
}

body > * {font-size: 1em !important;
}
/*** End of Screen Density 400 ***/

These measures are approximations. The style sheets reduce everything to one uniform font size, but they give you a good look at screen and line density.  When in doubt, see how things look at screen density 100 and then use your gut.  Keep the Screen Density Principle in mind.

To try out these and other style sheets you might want to read on how to activate user stylesheets. Just copy the listings above; save them as .css files, and try them.

Difficult Configurations

Bleeding Columns

Problem: Column bleeding occurs when the text from one column overwrites the text in the next column.  This happens frequently when you enlarge text (reduce screen density). Sometimes when you position columns with CSS, your text (especially link-text) will bleed across columns at low screen density. Overlapping text cannot be read. Bleeding is an ugly mess.

125–150 is the high end of screen density for most people who need enlargement.  A person may start in the morning on the high end with 125–150 screen density. By 10:00AM this drops to 100, and by the end of the day screen density can be down to 50 or less. Bleeding at low density blocks access.

Solution: You may want to use a multi-column format at high screen density, but as the user enlarges text with normal browser commands the screen should modify automatically to  one-column format. Layout tables cannot provide this access

Use “em” measures for column-containers.  Set up your layout to fit normal sizes perfectly. You use float to position your column-containers, and a tricky container tree for precision.  As text grows the page transforms to one column.  The user never needs horizontal scrolling.  A person can read just as well with a screen density range running from 400 to 25 words per screen.  The Screen Density Principle can be met for everyone.  (Exception: IE will only support screen density of 100–125 and higher.)  See the 2-to-1 example I have developed.

The structure outline of the webpage should look like this:

<body>
<div> 

<div> [Column 1 contents] </div>
<div>
<div> [Column 2 Contents] </div>
<div> [white space] </div>

</div>

We style the page as follows.  Column1 floats left.  Column2 floats right. Column2Content floats left and Pad floats right.  By adjusting the sizes of Column1Column2Content and Pad with “em” measures we can make the columns look just the way we want in normal mode.  As the page enlarges, Column2 gets too big and stops floating right.  The page becomes one column. If we do not have two boxes in Column2 the contents will all go right.  As we have done itColumn2Content will be forced to the left boundary of Column2. The Pad sits to the right, and makes up the right padding of Column2.  By varying the size of Column2Content and Pad we can push Column2Content as close toColumn1 as we want.

To add another column just change Pad to Column3.  Give Column3 the same structure as Column2.  This can be extended as far as you like.  Unlike, multi-column layout tables or multi-columns with fixed column positions and widths, this structure enables as many columns as you like for the full sighted user, and then reduces to one column with lower screen density.  The  Screen Density Principle is supported for everyone.

Layout Table Overflow

I never use the term “good layout table”. It is an oxymoron.  Layout tables are an automatic violation of the principle of separating presentation from content, semantic markup.  There are not so bad layout tables.

Problem: Layout tables are not evil, but they can make serious trouble for VR/LV.  One gross and terrible configuration is the multi-column layout tables with one long-horizontal cell across the top and / or the bottom. It will almost always force horizontal scrolling at screen density 100 or less.

Solution: Observe the following example: Layout Table Examples .  In this example we use the attributes and values:table-layout="fixed" and visibility="hidden".

Horizontal Navigation Bars as Layout Tables

Problem: Without a doubt the most terrible thing that can happen to a visual reader who needs enlargement is a horizontal navigation bar in layout table format. If there is a region of text connected to the navigation bar it will elongate as long as the navigation bar elongates.  This usually blasts off the right edge of the screen with minimal enlargement and requires horizontal scrolling for a text region that is connected to the navigation bar.  If we set thetable-layout="fixed" and visibility="hidden", the resulting navigation bar is barely usable, because it gives you too many truncated links that are cut too much.

Solution: If you want your text region and navigation connected in a table, you must make an inline-list within a single cell at the top.  See the following Navigation Bar examples: The code in the list example looks like:

<table >… 

<tr> <td> 

<ul> 

<li> … link 1 </li>

<li> … link n </li>

</ul>

</td><tr>
<tr><td>
… text region …
</td><tr>…

</table>

So long as the unordered list is given “display: inline;” the “table-layout: fixed” setting. the items  containing will wrap gracefully.  Normal readers won’t know what you did, and visual readers with low vision will be able to use (ctl-+ or cmd-+) to enlarge text.

Killer Margins

Problem: If you set your margins to an “em” scale, then when you increase font size, the margins get bigger too. Very quickly, you get a skinny column of very large print surrounded by giant margins.

Solution: Don’t use “em” units for margins or padding.  Instead, use pixels or even fixed measures like inches or centimeters for margins and padding.  Do use “em” on elements containing text like <p>, <li>, etc.  Your normal users won’t know anything changed and your users who need enlargement will see nice wide lines of large print with reasonable margins.

Squished Lines, Clipped Lists

Problem: When you use fixed measurement units for text regions then parts of letters are shaved off.  Sometimes the letters just fit, but there is no line spacing.  Fixed measurement units are measurements that do not change with enlargement like: inches, centimeters or pixels,

Solution: When squashing and clipping occurs at screen density of 100, check your line heights, and element heights.  Usually you find a fixed value that will not allow a larger letter size. To use the stylesheet above for testing, comment out the “line-height: 1.3 !important;” statement.  Check for fixed unit measures in Firebug.  Sometimes JavaScript inserts fixed units.

Take Away

Do not stop using text alternatives or keyboard access just because people in VR/LV do not use them. Keep using semantic markup.  Do everything you did before, but also consider how things look at screen density 100.  Can you read the page reasonably?  Does your page meet the Screen Density Principle at screen density 100 or even less?  Would you like to interact with your page at screen density 100

Finally, do not code in accommodations.  Large text buttons are just silly. Just structure your website so it can be modified visually without a lot of change. 100 screen density is good because most bad structures break at that screen density.  It is a benchmark, not an accommodation.

1 thought on “Nose to the Page (3)”

Leave a Reply

Your email address will not be published. Required fields are marked *