Tech Stuff - Access with CSS
Way back in 2007 (see site history September 2007) we finally decided to address two problems that we considered to be important and that had, as we saw it, similar solution strategies:
Accessibility issues for visually challenged readers. This was driven by a sense of guilt (were we doing enough for all readers) and self-interest (with the premature aging of eyes due to sitting in front of a screen for hours on end, we would fall inevitably into the visually challenged category ourselves).
An increasing range of screen sizes and resolutions. Back then it was mostly that screens were getting bigger.
After reading the trivial amount of serious and practical advice about accessibility (lots of motherhood stuff though, a situation which has changed little in 2015) we concluded that there were three elements that would give a reasonable trade-off between meeting our site's objectives and providing some level of user flexibility and control:
Liquid screen layouts. That is the ability of the displayed page to occupy the whole of the window size provided by the user's browser. None of this 800 pixel or 1200 pixel design framework nonsense. Let the user (or the user's hardware) decide. If you change the size of the browser window when viewing this page it will automatically expand or contract to use 100% of the available window. Most of this work was started around 1999 using HTML tables (honest).
We coupled this with a 3 column layout; left-hand menu column (essential navigation, fixed width); central panel containing all the information (variable width): right-hand menu column (auxiliary information which could be dropped for small screens, fixed width). In practice we had started this aspect of the work in a 1999-2000 timeframe again using tables and converted both the liquid design and 3 column layout to a full CSS implementation in 2003. If you change the size of your browser's window while viewing this page the text in the central panel will automatically reflow to use the available space. Related to this we decided to load pages in the order of central panel first, then left-hand menu, then right-hand menu. Thus, the user is presented with the information content that they, presumably, want (the central panel) without having to wait for unnecessary infrastructure (navigation) information to load. It has a negligible impact on fast DSL/cable lines but a significant one on slower links.
Finally, based on the best advice we could find at the time (2007) - which included probably the clearest advice from the W3C - we decided to change from defining our fonts in a point size to em units, smaller and larger text sizes could be defined using either em (for example, 0.8em or 1.5em) or % (for example, 80% or 150%). The difference is that em (or %) use a point size relative to either the browser default (for desktop browsers this is typically set to 16 pixels or 12 point) or to whatever override value the user has defined. All text is displayed relative to this size and automatically scaled. Again based on the best advice around at the time (2007) we also took the opportunity to define the line-height CSS attribute from the default (approximately 1.1em) to 1.3em to allow more white space around the text (one of the key characteristics, with color contrast, of readability). The crucial issue here is who controls page layout. If explicit point sizes or pixels are used then the web site controls the users viewing experience (changing the defaults would not, originally, override the explicit point size supplied in the web site's CSS style sheet). If relative units are used (em or %) then the user is at least nominally in control (even if they just use the browser defaults).
Note: During some remedial work it was discovered that the browser default for monospace fonts (Courier New, etc.) typically uses a ludicrously low default point size in most browsers (who knows why) forcing usage of either point or pixel sized text when using this style of font, not the more desirable solution of relatively sized text such as ems or %. Since we use monospace fonts frequently to document code snippets this affects us a lot. Sigh.
Fast forward to 2015 and let's look at what happened over the intervening years. Essentially, two things happened (or in one case did not happen):
Few web developers (or their clients) adopted relative font sizing practices. The original accessibility features have failed, not in design (they were and are perfectly sensible) but by a failure of web developers to embrace them. It appears that the web development business is still locked into the antediluvian practice of print layouts rather than using sensible design methods for the web medium. In general, print practice involves pixel perfect designs for total control over the visual layout. Web design has slavishly followed this practice, including of course, font size control. The net effect is to limit user control over layout. Ordinary users are welcomed as long as they abide by the web site rules. Browser developers were caught between these unfriendly (to those who wanted or needed additional point size flexibility) sites and real users who found it unacceptable. The solution has been to allow the user to set a variety of parameters (rather than just the original default font size) and recently the zoom feature that simply provides a bigger everything. In short a messy kluge has evolved, implemented with a lack of consistency across the browser families.
Screen sizes. They now vary from the tiny (smartphones and the like) to the impossibly large LED displays that need walls to be knocked down to get them into the office. But it's the small screens that pose the real accessibility challenge. Such is the power of modern smartphone and tablet OS's that they all run minor variants of full-function desktop browser families which includes the default desktop browser font size of 16 pixels or 12 points - which is essentially illegible for all but the young, and if they persist in web browsing on smartphones, not for much longer. Most recommendations suggest a minimum font size of 16 points (approximately 21 pixels) for smaller screened smartphones which means that all sites are now forced to recognize a mobile device (relatively trivial) and set the font size appropriately rather than simply changing the mobile browser's default fonts to reflect the screen size. The current situation and implementation essentially renders what little implementation of relative font sizes there is stone dead. Most bizarre of all is that google not only recommends this as an approach but goes further and threatens page ranking results if this policy is not followed.
Notes:
The number of web sites that provide a useful text sizing button or widget can be counted on the fingers of one hand. In any case this solution does not work for small screens because you typically cannot see the widget and even if you could it uses javascript which is rarely turned on by default.
To preserve the visual layout control of fixed point size web sites the viewport mechanism is provided in which a part of the web page (the viewport - normally starting on the left of the page for classic latin languages) is displayed on the users screen. The users then scrolls (normally to the right) to read across the page.
We have a policy failure on our hands and a series of klugey and inconsistent browser fixes. The W3C recommendations, while being eminently sensible and well thought through, have not been adopted in practice and should either be scrapped entirely (and a new series of recommendations developed) or given more teeth through pressure groups for the visually impaired or the aging baby boomers. Or we can continue to fudge the issue and sensible solutions will just quietly atrophy away.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
