Initial Accessibility Review

I have checked the entire theme and all text elements are sized using em units with following exception:

body {
  line-height: 1.5;
  font-size: 12px;
  font-family: "Arial", sans-serif;
  word-wrap: break-word;
}

I realize that this actually causes all text to be sized relatively to 12px, but what other alternatives do we have? If I set it to 100% (or not set it at all) then a lot of people will be reporting bugs about fonts being too large - users are generally not aware of the browser settings and stick to default 16px value.

I fail to see what's the point of setting body font size using relative units if it's not 1em or 100%. Garland is setting body font size to 76%, Seven to 0.8em - if it's done in order to allow users to scale fonts under IE6 then it should be moved to ie6.css as it's an ugly hack that explicitly says: take font size prefered by user and make it smaller.

I think that the best solution for contrib theme would be to provide custom theme setting that allows the site owner to choose base font size from following values: 10px / 11px / 12px / 13px / 14px / 15px / 16px / 100%

- a bigger base font size (14px, 15px, 16px) would be preferable for sites written in some non-latin scripts (traditional Chinese?),
- 100% could make sense on websites aimed at mobile browsers or disabled users
- and 12px/13px should be just fine for everyone else

For core theme I would propose to leave hard-coded body font size as it is (12px) and overwrite it in ie6.css with some relative value.

Color contrast issues are caused mainly by orange color which is used for hovered links.

75% = 12px in every major browser in use today.

Given that we cannot know what features the user agent will support its best to give a relative unit, which is why relative units are recommended for accessibility.

@Jeff Burnz this is true as long as the user has not changed the default font size in browser preferences. In my case 75% will result in 10px fonts which I find hard to read.

While setting body font size to something around 75% is so widely practiced on the web, I find it to be an outdated and unreliable technique that should stay in ie6.css.

Here is how some big name websites are sizing fionts:

• Google.com - no base font size (=100%), everything else scaled relatively
• Mozilla.org - base font size set to 100%, everything else scaled with fixed units
• Apple.com - hard coded base font size set to 12px, everything else sized with fixed units as well
• Opera.com - hard coded base font size set to 12px, everything else sized relatively to base

Well if big sites are not using relative units, it is their thing.
If Drupal wants to meet Accessibility Guidelines, the current rules for font sizes are very clear: do not use pixel sizes.

If somebody changes the default font size in Browser preferences - well that is exactly what the thing is for: people are able to change their base font size. If they make it smaller, you can be sure they want it to be smaller.

Also my vote for 75%.

@eigentor
Both solutions (body font size set to 75% or hard-coded to 12px with everything else scaled relatively) should meet WCAG 2.0 as sufficient techniques. But none of them will meet this advisory technique:

Advisory Techniques for 1.4.4 - Resize text
(...)
- Avoiding scaling font sizes smaller than the user-agent default (future link). Note: The author won't actually know the font size, but should avoid percentage scaling that results in less than 100%
(...)

Some related articles on that issue:

• W3C tips
• http://www.xs4all.nl/~sbpoley/webmatters/fontsize.html
• http://informationarchitects.jp/100e2r/

O.K. now here the accessibility specialitsts are asked.
Don't know if adhering to WCAG 2.0 level AA http://drupal.org/node/769692 means we can use pixel size for the base font or not. This is Everett Zufelt's and Cliffs Terrain...

Not being allowed to scale the font smaller than 100% to me is a typical scenario where accessibility goes over the top, as you cannot do design anymore. There might be some people who do this, but sure they do not do design or adapt all the rest to it.

Both solutions (body font size set to 75% or hard-coded to 12px with everything else scaled relatively) should meet WCAG 2.0 as sufficient techniques.

Totally, however the odd thing about using 12px hard coded is that you will need to reset the font-size to 100% (or 1em etc) or other (less/more) for every html element, which seems redundant when you can just set 75% on the body. We can never know what markup a module will generate, say for example Views often just have DIV and SPAN elements and no paragraph elements or other more semantic elements, so DIV & SPAN will need 100%. That seems a bit weird IMO.

I don't see why you would want to do this, in both cases pixel values are inherited:
- if I set body font size to 75%, then browser reads font size preferred by user (in most cases 16px) and calculates pixel value from it (0.75 x 16px = 12px). Calculated pixel value is inherited by all elements descendant to body (you can check it with Firebug under "Computed" tab)
- if I set body font size to 12px, then the same thing happens - the pixel value is inherited by all body descendants, we are just omitting the calculation step.

And btw, it would be wise to set base font-size on html element instead of body as it would allow third-party modules to use the new rem unit. Rem is just like em, but it's relative to top level element (html) instead of the nearest ancestor, thus eliminating common issues when dealing with several levels of nested elements.

From WCAG 2.0:

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

Since some of the browsers supported by Drupal do not allow for resizing of text that is defined with non-relative sizes then we cannot have text sizes set to non-relative sizes and meet WCAG 2.0 AA.

A couple of related comments:

1. How other sites do something is not a good argument for a practice unless it is verifiable that those sites do it correctly.

2. Although there may be sites whose user base is primarily disabled, there is likely no site where a disabled user is not possibly going to be part of the user base.

IE6 is the only browser I can think of that would prevent users from resizing text if body font-size is fixed. That's why I was proposing to add body { font-size: 0.75em; } to ie6.css.

@jarek

I personally am not comfortable with a non-relative font-size in a core theme, it sets a bad example. However, if you test in the Drupal supported browsers and the theme meets the success criteria as described in comment #11 then I say it's a pass. WCAG is technology agnostic and the sufficient techniques provided are examples, not requirements.

Well at the moment theme fails the basic requirements for core themes http://drupal.org/node/769692

So, if the theme does get included in core, we can just change it later so it complies.

For Drupal 8 and the different browser landscape then it might be another story.
But for now the situation is quite clear: the px size must be replaced with a relative value.

We had the discussion before http://drupal.org/node/668280 and there was consensus to not use px sizes.

@Jarek while you may have a point, this is mainly about consensus and keeping consistency throughout core. The theme does not really lose anything if the base font is in relative size, and as you state, the outcome is the same.

Making a core theme is very different from doing contrib. One needs to make more tradeoffs and compromises, and comply to standards, even if one does not fully agree.
But hey - the fame of having a theme included in a CMS that is donwloaded by the millions should far outweigh that :)

Ok, I'll set it to 75% if it's going help me push it into core, but I'm still not convinced that this technique is better :P

@mgifford: could you do another review? Lots of things should have changed since the last one...

Mike, would you agree those are not big fails - especially the stuff around or over 450, I'd hate to see us forced into high contrast only designs and color schemes - eg 490 is just 10 from a AA pass, although we could provide at least one very high contrast color scheme per core theme, not a bad idea?

The icon alt text needs fixing, need to check this in core and see whats going on there also.

Setting the font-size within the body to #px is wrong. The IE uo to 7 don't deal with such values as expected.
The font size shall be set to % for body.
WCAG 2.0 tell that the font-size for large textes shall be the browser default. This mean for most browser/OS/Hardware 16px.
The 16 px value is possibly related to serif fonts. If we consider that sans-serif fonts are a little bit higher as the serif fonts we may set font-size to 93%.
The css declaration for the body shall also include the color.

@jjsarton Where do you find pixel sizes in fonts? It may be on the demo site, but this is outdated. Check out the last version from CVS and the main font size should be 0.75em http://drupalcode.org/viewvc/drupal/contributions/themes/corolla/base.cs...

Thanks for reviews, body font size is no longer an issue in contrib as it's configurable via theme settings.