W3C home > Mailing lists > Public > public-low-vision-a11y-tf@w3.org > April 2017

Should we drop the color bullet for now?

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Tue, 25 Apr 2017 08:35:22 -0500
Message-ID: <CAOavpvf1CFSHGLpKUqyRfpNJ1_Ek6RsGUCjgqCiym3itW+oRRw@mail.gmail.com>
To: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>, Wayne Dick <wayneedick@gmail.com>
Hi Wayne and all,

Since we are dropping the font bullet from the Adapting Text SC for
the time being to allow time for more research, I wonder if we should
do the same for the color bullet?

We have no consensus on this current bullet:

* text color and background color to a single different text color and
a single different background color

Other language that allows more colors will very likely get push back.

We could expand Andrew's font note, so the whole thing could read:

<start draft text>
Except for images of text and captions, text styles of the page can be
overridden as follows with no loss of essential content or

* line spacing (leading) to at least 1.5
* letter spacing (tracking) to at least 0.12 em
* word spacing to at least 0.16 em

Editor's note: The Working Group seeks to include changes in text
color, background color, and font-family as part of the SC, but is not
yet able to identify a way to do so that is sufficiently testable.

</end draft text>


Kindest Regards,

On 4/15/17, Wayne Dick <wayneedick@gmail.com> wrote:
>  *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.

Laura L. Carlson

Laura L. Carlson
Received on Tuesday, 25 April 2017 13:35:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 April 2017 14:44:35 UTC