W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Adapting Text: "narrow values" vs "wide values" how to reach consensus (was Can someone explain the therapeutic value of switching to one font family)

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Sat, 15 Apr 2017 13:28:41 -0500
Message-ID: <CAOavpvcGgD6ibLtZSuCSs0QZq9wkfopxbgRMtc5aVW5jqfm1Wg@mail.gmail.com>
To: Wayne Dick <wayneedick@gmail.com>
Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, Alastair Campbell <acampbell@nomensa.com>
Hi Wayne and all,

I am running out of ideas on how to reach consensus on "narrow values"
vs "wide values" spec'd for the bullets in the SC text.

I know you have said that: "people with low vision are so skeptical of
narrow SCs when what we need is flexibility...We know well that
normative language is what becomes law. Putting single point
conformance in an SC is dangerous." [1]

Flexibility and "wide values" are low vision user needs.

The original LVTF font family SC (as well a the color and spacing) had
"wide values". For instance font family initially stated: "The user
can change the font family to any available to the user agent."

That experienced very strong push back.

So in an effort to save the SC, Alastair originated the idea of
overriding to one font family. At first he mentioned using Comic Sans.
Then the LVTF agreed on Verdana. On the March 14, 2017 AG survey [2]
some people disagreed with specifying a particular font so it was
changed to one different font family.

As for rationale Alastair has tried to explain it at least 3 times.

To @mbgower [3]:

<quote>
These values (verdana/black&white/EMs) are intended to provide a
standard baseline, any particular user is likely to choose different
values (especially font & colour).

The point is that this baseline is used to test the layout &
functionality, and if it works then it is robust enough for certain
user-adaptations (up to a point)...
<quote>

On the LVTF list [4],

<quote>
...if it can't be tested true/false from the SC text, it won't meet
the SC criteria. You can flesh things out in the understanding doc,
but the SC needs to be a true/false statement...If my team tests a
page with Verdana and black & white, and another team tests the same
page with "Latin Wide" (or some other very differently sized font) and
purple and green, we will get different results. Not due to
subjectivity, but objectively different results. Given where these SCs
are used (including for lawsuits), I think Gregg is right to say we
need normative testability. If there were some way to state the
requirement without a specific font/color/size value and still have it
be testable, that would be great. But it has to be a content
requirement, not a user-requirement, and that means specific values.
<unquote>


To @awkawk [5]:

<quote>
We started off with not specifying the values, but got feedback about
them being testable on the face of the SC.

I think there is a good argument for specifying the values, otherwise
you'll get different results.

The principle is that if you override the font (with any font), the
issues appear. E.g. font-icons disappear. Same for colours, the act of
changing them at all will highlight most or all issues people would
get from changing them to their preferred colours.
<unquote>

I hope that provides some history.

In addition something to be aware of is that even with Verdana spec'd
in the FPWD, WebAIM has commented [6]:

<quote>
...user overrides of "font family" opens up too many variables for
testing and should thus be removed. What if the font characters in the
user-specified font are significantly disproportionate to the
author-supplied characters in size, shape, etc.? The variations
introduced by font family customization are, we believe, adequately
covered by the manipulation of line, letter, and word spacing. The
only other possibility to ensure consistent testability is to define a
specific font face (e.g., Verdana) which introduces other notable
difficulties.
</quote>

As first stated in this message, I am running out of ideas on how to
reach consensus on "narrow values" vs "wide values" spec'd for the
bullets in the SC text.

Ideas anyone? If not, should we retire the SC?

Kindest Regards,
Laura

[1] https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Feb/0040.html
[2] https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results#xq10
[3]
https://github.com/w3c/wcag21/issues/78#issuecomment-277854075
[4] https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Feb/0034.html
[5] https://github.com/w3c/wcag21/issues/78#issuecomment-286441914
[6] https://github.com/w3c/wcag21/issues/254
On Apr 15, 2017 8:59 AM, "Wayne Dick" <wayneedick@gmail.com> wrote:
>
> How will being able to switch to one font family help? I really don't understand it. What is the justification of this limitation in terms of helping anyone. What family?
>
> Again how does the ability to switch to one color combination help anyone. What color?
>
> Let's pick H.
>
> How do either of these help users pick colors and fonts that lie outside a small list provided by developers?
>
> I can see ruling out ridiculous color combinations that don't have enough contrast for visibility. I can see ruling out fonts with extreme dimensions for the em unit (16px).
>
> Now there are many sites that can handle 200% enlargement and break at 225%.
>
> As stated I cannot see why a developer would not design a sight to enable a change to one different color and one different font. What language prevents that narrow interpretation?
>
> Is that narrow interpretation it?
>
> These SCs just do not make any sense.
Received on Saturday, 15 April 2017 18:29:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:12 UTC