[public-low-vision-a11y-tf] <none>

 *Adaptation of Text: *

Right now, AGWG does not have enough quantitative information to formulate
a success criterion regarding text adaptation that is sufficient to satisfy
the:

1.  Needs of people with low vision and

2.  Requirements of WCAG 2.1 success criteria

This problem can be solved but careful quantitative analysis is needed
before we can proceed. This requires a smaller group. I suggest freezing
all SC language development now and returning the SC to LVTF for
reformulation. The LVTF has enough feedback to reformulate this criterion
in a form that meets the needs of the target population and is tractable
for authors and testers.

The basic problem is to:

1.  Provide the widest possible range of typographic choice to support
legibility of text, and

2.  Create a framework that authors can implement and test.
*Example (Font Family)*

A construct like, “Users can pick any font family” is too wide for
implementers. A construct like, “Users can pick one of 10 font families
from the following list … ,” is probably too limiting for users.

This can be addressed statistically. We need to study the distributions of
actual font dimensions within the set of font families. Namely, if we fix
font size to 16 pixels then how do the following parameters vary across
font families:  height, width, ascending stroke size and descending stroke
size? With a clear understanding of these distributions we could identify
outliers that are in wide use or appear to be applicable for a specific
user need. These outliers would be very wide, high or have extreme
ascending or descending strokes.
*Solving the User Need Problem*

The W3C could maintain a list of permissible font families for changes.
This could be a long list, maybe 500 font families.  This would provide
adequate choice. As part of WCAG Techniques update, this list could be
updated with new fonts as typographers create them.
*Solving the Implementer and Tester Problem:*

The primary issue for implementers is fitting an unplanned font family into
a non-responsive design.

The font metric distribution could be maintained as part of the permissible
font families list.  A small set of outlier fonts could be identified and
all the author would need to do is test against this list of outliers.  For
this we probably need only four exemplars.  That is: the author tests the
widest, highest, and most extreme ascending and descending strokes. This
would do what we wanted to do with Verdana alone at the beginning. It would
provide a true or false test of whether the font change will disrupt layout.

Once we establish the font size metric distribution, we can make very exact
sets of choices and testable limits. We may make a choice to set limits to
the extreme metrics. The difference between what we are doing now is that
we will know the actual dimensions of the data space.
*Other Limits*

 Our discussion lists have identified several limits imposed by web
platforms, technologies and practices. These include:

1.  Partial or no support from platforms and / or technologies

2.  Limited semantics necessary to support choice. Examples: Identification
of Icon fonts. If we change all font families to one target, icons will
disappear. Fonts used for special purposes as in variables from science,
technology, engineering and mathematics would be changed without MathML
markup. For example, the symbol font for epsilon zero, in physics could
change to e0. That would change the meaning. Another example could be the
use of Arial-Black for Matrix names, *M*n,m. The symbol Mn,m would denote
the (n, m) entry in *M*n,m. These latter examples would be discipline
specific font conventions.

3.  Programming practices that limit the ability to change font family.  This
can be as simple as using “important” in line or as complex runtime font
substitutions by third party vendors. These will need to be collected and
identified within techniques.
*Conclusions*

I think we have gotten as much feedback as we need to construct the SC our
users need with enough limitation to enable testability and implementer
tractability.  There will be gaps in the current platforms, technologies
and programming practices that we may not be able to address now, however
we can address then and use them to construct reasonable procedures for
authors and testers.