Should we drop the color bullet for now?

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

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

Thoughts?

Kindest Regards,
Laura


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