Re: Add Font Family back to adaptation

Hi Wayne,

Hi Wayne,

On 6/6/17, Wayne Dick <wayneedick@gmail.com> wrote:
> I would start the bullet with this language.
>
> The user can substituted a font family for the author's font family so long as the the following condition is met.

Does your new research indicate that users can't change font family?

The following are the excerpts from April's "How do we distinguish
between I, l and 1 and 0 and O?" thread:

On 4/27/17, Jim Allan <jimallan@tsbvi.edu> wrote [1]:
> the user can still change the font, because they still have that ability.

On 4/27/17, Wayne Dick <wayneedick@gmail.com> wrote [2] :
> How long will users be able to change font?

On 4/28/17, Alastair Campbell <acampbell@nomensa.com> wrote [3]:
>> How long will users be able to change font?
>
> As long as browsers allow extensions that manipulate the user’s view. I have seen no sign of that changing.

Does your new research indicate that users can't change font family?

Thank you.

Kindest Regards,
Laura

[1] https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Apr/0188.html

[2] https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Apr/0190.html

[3] https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2017Apr/0196.html

On 6/6/17, Wayne Dick <wayneedick@gmail.com> wrote:
> I would start the bullet with this language.
>
> The user can substituted a font family for the author's font family so long
> as the the following condition is met.
>
> There ratio of the user's font family character size and the average
> character size taken over font families in the script for the writing
> system in use does not exceed 1.2.
>
> The average character size for a font family is the width of the Unicode
> language block measured in pixels divided by the number of characters in
> that block.
>
> Note: Unassigned characters will be excluded from the Unicode language
> block as well as any characters that are identified by language experts as
> inessential to the count. The character count will thus equal the size of
> the Unicode block minus the number excluded character codes.
>
> The average character size for font families in a given script is the mean
> average character size taken across a representative sample of font
> families.
>
> Wayne
>
> On Tue, Jun 6, 2017 at 11:30 AM, Wayne Dick <wayneedick@gmail.com> wrote:
>
>> The need is conflict pairs in font families. The most common are: Capital
>> I, Lower case l and the digit 1 (that is actually 3 pairs taken 2 at a
>> time). The other pairs are S (capital 'S') and 5 (digit 5), B (capital
>> 'B')
>> and 8 (digit 8), O (capital 'O') and 0 (the digit zero) and in some
>> script
>> cases Q (upper case Q) and 2 (digit 2).
>>
>> Letter spacing and size are different issues. The capital 'I' and lower
>> 'l' is the worst. Frequently the only difference is a slight difference
>> in
>> height. These pairs do not pose a huge problem in text, but outline
>> numbers
>> and passwords are a different situation.
>>
>> Use case: You forget your password and get a temporary password on your
>> mobile phone.You are forced to copy the password by hand to your
>> computer,
>> and if you cannot distinguish one of these pairs, then you are in serious
>> trouble.
>>
>> Wayne
>>
>> On Tue, Jun 6, 2017 at 9:19 AM, Alastair Campbell <acampbell@nomensa.com>
>> wrote:
>>
>>> Hi Wayne,
>>>
>>>
>>>
>>> For what purpose? I thought the point was that we assume people can
>>> over-ride fonts, therefore we cover that need with sizing?
>>>
>>>
>>>
>>> Having looked at the distribution of font-sizes, do we need to increase
>>> the spacing aspects of the current bullets?
>>>
>>>
>>>
>>> Note that there is a balance: Layouts can take a certain amount of
>>> buffer
>>> before they look odd in regular use. If we push past that point (my
>>> feeling
>>> is around 10-15% increase) then it will be either rejected by the design
>>> &
>>> dev community, or moved into a personalisation SC.
>>>
>>>
>>>
>>> Going past that point means a more significant override, so either
>>> discarding the author-styles (like Linearise assumes), or adding
>>> alternative layouts with personalisation. In either of those cases, it
>>> would move out of the text-adaptation SC anyway.
>>>
>>>
>>>
>>> I’m more concerned with colour which isn’t covered yet, does anyone have
>>> further ideas on including that?
>>>
>>>
>>>
>>> -Alastair
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Wayne Dick <wayneedick@gmail.com>
>>> *Date: *Tuesday, 6 June 2017 at 16:50
>>> *To: *LVTF - low-vision-a11y <public-low-vision-a11y-tf@w3.org>
>>> *Subject: *Add Font Family back to adaptation
>>> *Resent-From: *LVTF - low-vision-a11y <public-low-vision-a11y-tf@w3.org>
>>> *Resent-Date: *Tuesday, 6 June 2017 at 16:51
>>>
>>>
>>>
>>> It is time to put font family back into Adapting Text. Steve has
>>> addressed the icon substitution issue well. Namely add failure to mark
>>> icon
>>> fonts to 1.3.1. I have looked at the distribution of font face sizes.
>>> Within each writing system:
>>>
>>>    1. Identify a mean character size within the script for that system.
>>>    2. Compute the ratio R of average character size by family to mean
>>>    character size over all families in a representative sample.
>>>    3. Using language experts, establish boundaries that make sense close
>>>    to 1 standard deviation from the mean.
>>>
>>> Note: Mean +/- 1.2 should do based on the physiology of the human eye.
>>>
>>>
>>>
>>> Wayne

-- 
Laura L. Carlson

Received on Tuesday, 6 June 2017 19:42:48 UTC