Re: 1100% enlargement

This is in response to Scott primarily.

I think we are actually talking about the same thing, but you are not
taking the LVTF transformations as a whole into account. When we include,
linearization and element level customization, 1100% enlargement if you
want it is accessible at the browser level.

I doubt the LVTF is proposing full screen only. What we do want is display
of the block elements in linear format. One should be able to view that as
wide or narrow as needed. For text we say that the user can choose the line
length. LVTF has settled on that. Linearized display enables unlimited
enlargement with reflow. Without content that can display in a linear
format, one cannot write AT that resizes text with reflow as large as is
needed.

I did not address tables or images because we were talking about text
resizing. However, tables could be handled like this. We require that every
table cell containing text is no wider than the width of text columns
determined by the user. You may need to scroll horizontally to go from cell
to cell in the same row, but no cell will be wider than a line of text you
can read. Table text will always word wrap within cells.

Every standard browser could support the user’s required text resize within
this context. It would require appropriate extensions that support style
profiles for users. You don’t use zoom. You prescribe the text size element
by element. In this environment users could enlarge as far as they desired.

There should be no size limit. The user should just be able to customize at
the element level to obtain the best font size that fits on the screen or
viewport of the user's choice. For practical reasons the line length will
rarely get smaller than 15 characters per line. You will also see few pages
with less than 3 lines per page. So the dimensions of the viewport will
limit the practical font size. Again, users can choose the tradeoff between
font size and viewport information density.

A user who requires a narrower viewport will pay for that choice in font
size. Each person will find the best balance. But, for many users 1100%
will be most practical when supported with full word wrap and hyphenation.
Remember low vision includes the severe range (20/200 to 20/400), and many
of those people read visually and need extreme enlargement.  Right now AT
doesn't provide that as a practical option because the current price of
extremely large font size is horizontal scrolling. However, HTML with CSS
and/or JavaScript can do it now for content that linearizes. Once content
is constructed to support linearized display of block items, such
extensions will be possible.

The contribution of responsive web design is to prove linearization is
possible on complex active sites. The fact that current authors erect
barriers to this access is a problem of authorship. Content can do it.
Linearization is possible with full functionality. With that quality of
content, font size that fits the user need is more possible inside the user
agent than it is with the current AT.


Sincerely, Wayne





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

> 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
>>>
>>
>>
>