Re: 1100% enlargement

The text portion of my comments in issue 5.
Text Enlargement Is Poorly Understood by the A11y Community

Most accessibility people's experience with text enlargement is geometric
zoom (GZ). Even with sophisticated curve smoothing this is the most
primitive concept of enlargement. It is a geometric operation that is
unrelated to the semantics of written language. GZ is implemented in
operating system’s and browser’s zoom. Screen magnification software
implements GZ as well as possible.

The model for enlarging text that best fits user needs for partial sight is
semantic text resize (STR). The word processor is the most familiar
example. You find a semantic object like normal running text, and you set
its size. Everything magically reflows to reflect your choice. We have at
least two implementations that support this model: word processors and
markup language.

GZ creates two profound negative consequences: loss of the continuity of
text caused by line truncation, and navigation difficulty caused by
bi-directional scrolling (horizontal and vertical). STR solves both
problems, and this enables much larger resize factors without disruption of
reading. (See the comparison below and (Legge, [1]
<https://www.regulations.gov/document?D=ATBCB-2015-0002-0019>)

In my example on enlargement to 1100% [3]
<https://github.com/w3c/low-vision-SC/issues/5>, I illustrate that word
wrapped content where the font size has been increased by 1100%, produces
very readable text on a 22-inch screen. Gordon Legge, author of The
Psychophysics of Reading for Normal and Low Vision, demonstrated a similar
example for 1000% enlargement on a 9.7-inch iPad 3 [1]
<https://www.regulations.gov/document?D=ATBCB-2015-0002-0019>.

At some point, even enlargement with reflowed text fails. You hit a wall
caused by the width of the display medium. At that point you must decide on
a tradeoff between a desired text size and the minimum number of characters
per line that make reading sense. Semantic text resize is not really a
scaling factor problem. It is a problem of word fit.

This was the problem Gordon Legge and I were trying to solve when we came
up with the 1100% scale. We were trying to fit 10 to 15 characters per line
on a screen, and compute a reasonable scaling maximum to fit that character
count. Legge managed to fit 15, 9 point characters on the iPod 3 landscape
screen with a 1000% STR, [1]
<https://www.regulations.gov/document?D=ATBCB-2015-0002-0019>.
Reconstructing my work for 15 characters on a 22-inch screen I developed my
1100% STR example for Issue 5 in the LVTF SC Github [3]
<https://github.com/w3c/low-vision-SC/issues/5>.

Attempting to come up with a zoom maximum was probably an error. I was
trying to force a geometric limit for an operation that was semantic. What
makes semantic sense is a maximum character count per line. That should be
somewhere between 10 and 15 characters per line.

Since, characters per line depends on the font-family, a more practical
measure would probably be EM units per line. Since the EM count and
character count differ I was hesitant to propose an EM or character count
to the A11y community because of the complexity of this difficult argument.
That seems to have caused more confusion than it was worth. My example was
based on an EM count, Legge's was based on a character count for a given
font family. Since EM count is greater than character count we should
probably define our SC in terms of typographic EM units. The SC should be
stated as something like: Documents should support a maximum line length of
10 to 13 EM units per line. For screens of size 22 inch this will support
1100% for most fonts. For small screens the enlargement will be smaller,
but the text layout will be readable. A maximum EM count will give the
maximum semantic text resize possible for a given medium.

I close with a comparison of STR to GZ. The take away is that you have more
readable information with 1200% Semantic Text Resize than you do with 500%
Geometric zoom.
Example 1

Comparing STR to GZ at 1200% Enlargement on a 22-inch monitor.

Below are screen shots of text enlargement by 1200% using text enlargement
and zoom respectively. Screen size is 22-inch.

Starting at the top line the text enlargement with word wrap has a sequence
of ten words in reading order. The entire sequence makes logical sense. The
top line of the zoomed screen shot has only three complete words in reading
order. The rest of the screen is filled with disconnected word sequences.
One can easily understand how a person would think 1200% enlargement was
excessive in an environment only providing zoom. Three words per screen is
not very useful. In our example we have 14 characters of signal, and more
than 50 characters of noise when we use 1200% zoom, a terrible signal to
noise ratio. The text enlargement has 57 characters, 10 complete words in
logical sequence, with no noise. Ironically, the zoomed page has more
characters, but the word wrapped page has more meaning.

The images are taken from my article [2]
<http://nosetothepage.org/Articles/A1.html>, "Because I am not blind",
based on a quote by Sam Genenski inventor of the CCTV for reading.

[image: 1200str]
<https://cloud.githubusercontent.com/assets/8195607/16749126/f1caba28-477c-11e6-9d5e-7418384b99a7.png>
[image: 1200gz]
<https://cloud.githubusercontent.com/assets/8195607/16749135/f9d30b44-477c-11e6-9680-13e558e98610.png>

Figure 1: Fully word wrapped 16px tahoma text enlarged 1200%

Figure 2: The same is text enlarged with zoom. "Few people have", is the
only meaningful sequence starting from the top. This is of marginal use,
and greater enlargement will only harm.
Example 2:

Comparing STR and GZ at 500%

In this example we see why GZ tops out at 500% enlargement. Any larger and
the navigation problem combined with too little visible useful content
makes larger GZ impractical. STR is more usable at 1200% than GZ is at 500%

[image: 400ste]
<https://cloud.githubusercontent.com/assets/8195607/16748962/13d66762-477c-11e6-89d3-c2b2b585975a.png>

Figure 3: This figures shows a meaningful sequence of 69 words, numbers and
abbreviations. Every line follows semantically from its predecessor

[image: 400gz]
<https://cloud.githubusercontent.com/assets/8195607/16749067/97810b12-477c-11e6-8c57-9c44cc34fa59.png>

Figure 4: This image has 9 lines of text. They are semantically disjoint.
If you start at the top, only the first line is useful without scrolling
horizontally to fill in the gaps.

[1] <https://www.regulations.gov/document?D=ATBCB-2015-0002S-0019> Gordon
Legge, Comments to the U. S. Access Board, 2015

[2] <http://nosetothepage.org/Articles/A1.html>"Because I am not blind",
Wayne Dick, 2015

[3] <https://github.com/w3c/low-vision-SC/issues/5> Wayne Dick, An Image of
1100% Text Enlargement, Issue #5
<https://github.com/w3c/low-vision-SC/issues/5> WCAG 1.4.8 item 5 200%,
LVTF SC Git Repository



On Mon, Jul 11, 2016 at 4:13 PM, Wayne Dick <wayneedick@gmail.com> wrote:

> I failed to give a link for Issue 5.
> https://github.com/w3c/low-vision-SC/issues/5 . Also, I'd like to
> apologize for not having text alternatives on my pictures. I don't know how
> to do that in the comments page. The pictures were really hard to get in
> the right place.
>
> On Sun, Jul 10, 2016 at 9:34 AM, Wayne Dick <wayneedick@gmail.com> wrote:
>
>> The size 1100% seems crazy o first glance, but it is very practical for
>> reading. I first thought of getting all logical, but an example is better.
>> Look at WCAG 1.4.8 Issue #5.  I have included a screen shot of 1100%
>> enlargement of 16px on a 22 inch screen. It looks like a reasonable reading
>> interface to me.
>>
>> Take a look. https://github.com/w3c/low-vision-SC/issues/5
>>
>> Wayne
>>
>
>