Font issues brain dump.

I think the real issue to understand is the user need we are trying to solve here. It seems to me that there are two possible cases - either the user has difficulty seeing anything which is too small, or the user has a specific difficulty with text shapes, but is otherwise fine with images etc. From my perusal of the open font issues, it seems to be the former case we are addressing.

If the second problem is a genuine issue, which I have my doubts about, then I think life is a lot more complex. I do understand a bit about CSS and layout, and in general simply increasing the font size of text in isolation is unlikely to work well unless the designer has explicitly taken this into account, and defining an SC to make them do so is problematic. Beyond a certain point legibility is actually decreased by just increasing font size. The whole design needs to take the resizing into account.

It is logically impossible to simply increase font size without increasing the container size, and still expect the content to fit. The HTML/CSS model is for the preferred direction of expansion to be in the block progression direction (we should avoid the use of horizontal or vertical as they are not international); but for any kind of complex layout, i.e. the 90+ percentile of the web today, and because HTML/CSS is not required to do hyphenation, font resizing is in general going to cause block overflow in the inline progression direction - thus any absolute ban on 'horizontal' scrolling must be avoided, and any 'should' in this regard is untestable.

If the designer has built a so called 'liquid' layout, then he may have anticipated a certain amount of block reflow; but there are limits to which even this is going to be practical, plus it is very hard to create a genuinely flexible layout, and still be appealing to the original client.

What is actually needed is a requirement to provide a set of stylesheets for scaled display, and have the 'make font bigger' menu option select between such stylesheets; but currently there are no metrics for the designer to base such layout sizes on, and the browsers don't do this.

Scaling, if it cannot adequately be corrected by personal optical devices, is in my opinion best solved by enlarging the entire display image. Although this may involve more scrolling, it is more likely in general to remain comprehensible to readers, and is easy to deploy by authors.

Scaling the display (and having big displays) will be increasingly the mechanism in the future, as OS's move to a general flexible graphics model: MacOS has already done this, it is in Vista, and I believe many of the Linux visual shell's such as enlightenment do it too. Of course there will remain limitations when graphics and text are supplied in low-res pixel based forms and we can give an SC on this; but in general I don't think reflow is a technique we can require web designers to worry about at this point - but rather assume scaling being built into future OS's and browsers
(it may be a possible UA requirement to set an arbitrary canvas size, independant of device pixels).

What the SC for web authors should focus on is size flexibility for all content:

 a) always using scalable fonts and providing adequate pixel resolutions for raster images,

and

b) never specifying lengths in physical units, but rather in units relative to the container size (despite what one reviewer thinks, a pixel is not a relative unit in CSS since relative means to a container), or defining containers in terms of 'em's of the current font.

Note that font size is only one specific length, and a truly fluid design needs to change all lengths. So in fact physical measures are actually pretty meaningless. A pixel is only well defined at the display surface, and so designers should not be using them unless they know what that display surface is (which they can't in general).

A designer using a physical measure is not really a user agent issue, a point and an inch are well defined physical lengths, for the UA to remap them should be an error - IE is actually being well behaved in this regard (It is CSS which is broken). But because in actual fact the user agent in general (at least on non closed devices) has no way of accurately determining how many pixels or other display area there are in a real inch or point, they resort to some guesses [The bogus wording regarding 'subtended angle' in the CSS specification is wishful thinking].

As for font selection, since the web currently does not have a reliable way to install fonts at the client end; no truly adaptable content should in fact specify any specific font. That specifying a specific font kind of works is due to the prevalance of a relatively few OS/browser combinations. So here we might also state an SC to avoid using specific fonts.

On other legibility issues, again writing an SC to cover this is akin to saying "use simple language". The web is too much of a marketing engine for such an SC to carry much weight, and its pretty much untestable.


Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
  mob +44 7977 455002
  office +44 117 9719730

From: Loretta Guarino Reid [mailto:lguarino@adobe.com]
Sent: 13 November 2006 13:45
To: Sean Hayes
Subject: FW: Fonts

Hi, Sean,

Are you on the Team B mailing list yet? So far, the silence from Team B has been deafening. <grin>

I'd particularly like to see if you and Gez can help work out a specific proposal, since you both seem particularly sensitive to the author responsibility vs the user agent responsibility.

Loretta
------ Forwarded Message
From: Loretta Guarino Reid <lguarino@adobe.com>
Date: Thu, 9 Nov 2006 16:31:59 -0800
To: <public-wcag-teamb@w3.org>
Cc: Andi Snow-Weaver <andisnow@us.ibm.com>, Becky Gibson <Becky_Gibson@notesdev.ibm.com>
Conversation: Fonts
Subject: Fonts
Resent-From: <public-wcag-teamb@w3.org>
Resent-Date: Fri, 10 Nov 2006 00:33:29 +0000


Folks,

The Font proposals are back to us, to hammer out more satisfactory proposals or decide that we aren't going to propose any new SC on this topic. I'd really like to be able to wrap this up, one way or the other, next week. The comments on the current proposals can be found at

http://www.w3.org/2002/09/wbs/35422/2006-11-07f2frnd2/results#xfontl2 <http://www.w3.org/2002/09/wbs/35422/2006-11-07f2frnd2/results#xfontl2>   and

http://www.w3.org/2002/09/wbs/35422/2006-11-07f2frnd2/results#xfontl3 <http://www.w3.org/2002/09/wbs/35422/2006-11-07f2frnd2/results#xfontl3> . Comments in the database can be found by searching for the FONT sort item.

The current proposals for the L2 SC include:

-       A mechanism is available to change the scale of visually rendered text content.

-       Visually rendered text can be scaled without obscuring other text or diagrams.

-       Visually rendered text can be scaled.

-       Visually rendered text can be scaled at least XXX%

The current proposals for the L3 SC include:

-       When the scale of visually rendered text is changed, content is reflowed in a way that does not require the user to scroll horizontally.

-       When the scale of visually rendered text is changed, content is reflowed.

-       When the scale of visually rendered text is increased up to XXX%, content is reflowed in a way that does not require the user to scroll horizontally.

There were concerns raised about

-       the exact set of sufficient techniques for these proposed SC,

-       whether relying on the user agent functionality was a suitable technique,

-       whether non-HTML technology can satisfy these SC,

-       whether there are suitable techniques to support this type of behavior for all content,

-       the role of zoom,

-       whether there should be a limit on how much scaling it is reasonable to support,

-       whether it is too easy for any content to fail the L3 success criterion.

-       whether this SC would apply to text in images, captions, subtitles, etc.

How shall we proceed? Can I ask each team member to send their choice (including none) for the two SC by the end of the day Friday? Try to provide some justification for your choice. This will let us think about the issues (and possibly discuss them on the list) before our meeting on Tuesday.

Thanks, Loretta

Loretta Guarino Reid

lguarino@adobe.com

Adobe Systems, Acrobat Engineering




------ End of Forwarded Message



Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
  mob +44 7977 455002
  office +44 117 9719730

Received on Monday, 13 November 2006 18:14:55 UTC