RE: Anything for a possible 2.2?

Hi Wayne,



> Now the normalized Verdana exceeds the size of Times New Roman by 0.05em.



We have text-spacing that requires people test for 0.12em of extra letter spacing, I’m not sure what extra you are trying to add?



People can change fonts now, what is the content-requirement for designers & devs?



For the icon fonts issue we need to get that technique written up & put in front of the group. If there is push-back on that, then we’d have a new SC requirement.



NB: I don’t think it’s a good CSS practice to explicitly set every element with a font-family, you just apply it to html or body and everything under that inherits the font-family unless otherwise specified.



Cheers,



-Alastair



From Wayne:


Post Script:
I have tried this on CJK Languages, Arabic, Vietnamese and Western Languages. All that is needed is to have members from each country to supply a test set of characters. For latin languages the test set is:

!"#$% &'()* +,-./ 01234 56789 :;<=> ?@ABC DEFGH IJKLM NOPQR STUVW XYZ[ ]^_`a bcdef ghijk lmnop qrstu vwxyz {|}~

Best, Wayne


On Fri, Oct 12, 2018 at 11:10 AM Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:
The ability to change font is important. I believe something like this would impact developers very little:
Normalized change of font.
If the user adjusts font size so that the average character width is 0.5em for 1em font-size, then the user may change font to whatever family they choose.

Example: Suppose you choose Verdana width for 1em is 0.576em to replace Times New Roman width for 1em is 4.718. Multiplying the font size of Verdana by  0.8680 = 0.5/0.576 gives 0.8680 em.
The character width is 0.4994em really 0.5. Now the normalized Verdana exceeds the size of Times New Roman by 0.05em. See http://nosetothepage.org/TextAccessibility/FontCompare.html.


To handle icon font problem caution users to avoid the i and span element in font family change. Caution authors to use role="img". For math just have users avoid math like p:not(math p).

For users also caution to avoid the * selector favoring explicit selectors like:

html, body, div, /*span,*/ applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, /*i,*/ center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td{
font-family:"Lucida Sans Unicode", "Lucida Grande", sans-serif;
}
(generated mechnaically)

Access to font is pretty easy.

I am willing to make my font normalization programs open source.

Wayne






On Fri, Oct 12, 2018 at 8:58 AM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Hi Jim (and LVTF),

Pre-TPAC, it would be useful to know if there are any potential SCs you’d consider for a WCAG 2.2?

We haven’t determined whether the group will tackle that yet, but part of the decision would be: Is it useful to do a 2.2?

Looking back, I couldn’t see much in the LVTF ‘defer’ list here:
https://github.com/w3c/wcag21/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3ALVTF+label%3ADefer+


Printing customised text perhaps?

Given the shape of 2.1 now, are there gaps or things to tighten up that can work in the 2.x structure?
Perhaps a couple of additional SCs that tighten up current ones?

If there are others that didn’t make it to a github issue in the first place, now is the time to say so.

I’m not sure who’s attending TPAC, but if there’s a short overview of 1-6 SCs I can run through them which would be very useful for the discussion.

Kind regards,

-Alastair