Re: Font-size in WCAG 2

Jesper Tverskov wrote:
> Most of us would agree that the text of a web page should have a not too
> small initial font-size when the user arrives.

That's a very subjective measure...how would you define "not too small"?

> Most of us would also agree that it should be possible for the user to
> adjust the font-size in the browser, and for that reason a relative unit
> should be used.
> 
> Most of us would opt for percent or EM but since IE does not render EM
> for font-size as it should do in some cases (the smaller sizes get too
> small), it is recommended only to use percent for the time being, or in
> some cases xx-small to xx-large, etc.

Personally, I'd say this issue falls more into the UAAG camp, 
particularly UAAG1.0 Guideline 4
"Ensure that the user can select preferred styles (e.g., colors, size of 
rendered text, and synthesized speech characteristics) from choices 
offered by the user agent. Allow the user to override author-specified 
styles and user agent default styles."

I've heard certain factions argue that pixels are not an absolute 
measure, as they depend on user choices such as screen resolution...but 
I'm not going to touch that debate here.

But I will say that if we start to water down WCAG2.0 (the "main" 
document, not the techniques) by working around current browser 
limitations, we'll end up with exactly the same problem as with 
WCAG1.0's myriad of "until user agents support this...".

> None at all. The importance of a rather big initial font-size and of
> relative font-size is somehow not generic enough to be included in the
> accessibility guidelines proper.

Again, I think because in an ideal (read WAI) world, user agents will be 
conformant with UAAG, and initial font-size and the ability to scale it 
will be a given, as the users will have full control over these aspects 
once content and presentation are separated.

> Since font-size is no longer a problem of HTML, we find nothing about
> the two mentioned problems in "HTML Techniques for WCAG 2.0". We need to
> look in "CSS Techniques for WCAG 2.0".

Aeh...isn't that the point of separating content and presentation? 
Font-size=presentation, hence discussions on presentation as they relate 
to (X)HTML documents are to be found in the CSS section?

 > In "CSS Techniques for WCAG 2.0" we need to look under "8. Fonts", here
 > 8.1 talks about "Specifying fallback fonts", 8.2 is talking about
 > "Specifying font characteristics", first 8.3 is talking about
 > "Specifying font sizes using xx-small to xx-large".
 >
 > Important issues like initial font-size and relative font-size except
 > the incomplete 8.3 are completely forgotten.

What's wrong with "1.1 Using em or percent for properties that need to 
change"?
http://www.w3.org/TR/2004/WD-WCAG20-CSS-TECHS-20040730/#units-that-change

If anything, it would be good if there was some more cross-linking from 
8 to 1, and from main WCAG2.0 guidelines to 1...

> Hopefully the missing issues about font-size, some of the most
> important issues in accessible webdesign, will be included one day.

Yes, I too hope that the techniques documents will be "real 
world/pragmatic". These documents could ideally change more often than 
the core WCAG2.0 document, and be kept up to date with regards to "until 
user agents" caveats.

> The main problem is that the guidelines proper are so generic, that
> almost only computer scientists specializing in accessibility guidelines
> can stomach reading them,

I'm not sure I follow...too generic, so only specialists can stomach them?
The current WCAG2.0, in my humble opinion, does suffer from a slight 
indecision as to how "fluffy" and top level it wants to be. Maybe a 
short executive summary for each point, *before* going into Level 1,2,3, 
would be advantageous.

> and "CSS Techniques for WCAG 2.0" is in the
> same manner written for CSS-specialist.

Again, possibly need for a slightly higher level, non-technical summary 
before specific techniques. But I do feel that the nitty gritty details 
of how to achieve certain aspects of technical compliance *are* complex 
in some areas, and that it is sometimes necessary to use technical 
language. The techniques documents are, in my mind, aimed at the 
implementers who, one would hope, have at least a basic knowledge of the 
technology.

> How will interested users, net editors, decision-makers, and even
> general project managers of web projects ever get to know that some
> important issues concerning font-size are actually part of the
> guidelines if the issues are only listed in a very technical manner
> surrounded by scores of less important issues in a CSS manual?

WCAG2.0 definitely needs a few more higher level explanations, but the 
technical details can't, in my opinion, be presented in any less 
technical way. As I said before, potentially the need for a quick 
non-technical summary of detailed techniques.

Patrick H. Lauke
_____________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com

Received on Monday, 16 August 2004 19:08:52 UTC