There is no doubt that the Internet is in a state of constant evolution. The dot.com boom-bust era is now a distant memory as e-commerce thrives, fuelled by a growing public acceptance of security. Web pages are being browsed in cafes equipped with wi-fi networks, and even on PDAs (personal digital assistants). The Internet is becoming more pervasive - an integral part of life. Even for blind people.

The word 'even' is not meant to marginalise blind people. It merely reflects the fact that most people assume that web pages are a mixture of images and text intended for consumption by sighted people. But there are a huge number of blind and partly sighted people who actively use the Internet. Partly sighted people use hardware or software screen magnifiers - blind people listen to a speech synthesiser in order to 'read' the page from top to bottom.

The accessibility of web pages for these people and others such as the physically disabled, who cannot operate a mouse or keyboard became a key issue in 2004. In the UK, the Disability Discrimination Act 1995 and in the States, Section 508 of the Rehabilitation Act Amendments of 1998 came more fully and purposefully into force. In essence, these acts require that disabled and non-disabled people have comparable access to web sites. The World Wide Web Consortium (W3) instigated the Web Accessibility Initiative to this end, in conjunction with organisations around the World, including Microsoft. Some web sites and service providers have already been sued for failing to provide comparable access to disabled users. This has necessarily created a much greater urgency for accessibility conformance for web designers.

The accessibility factors that the acts focus on are quite diverse and demanding. A web page should be viewable on a monochrome screen without loss of function. So you cannot rely purely on colour to control operation. And you must ensure that colours contrast well where necessary. Grey lettering on yellow may simply not be visible in monochrome. Images should be accompanied by an image name (via the alt keyword), allowing speech synthesisers to say what the picture represents.

CSS - The Solution…?

Cascading Style Sheets (CSS) have come to prominence as a means of supporting accessibility needs. CSS is a set of markup instructions that a web browser reads to determine how to layout and style a web page. It works in conjunction with HyperText Markup Language (HTML). The emerging idea is to define the content of a web page using HTML, and the presentation of the page using CSS. The latter is often in a separate file, enhancing the separation, and allowing for independent changes to many pages that share a CSS file. For example, one CSS file change can convert <ul> list bullets from circles to squares in all pages of your site.

With CSS, you can easily control text sizes (for partly sighted users) dynamically from the web page itself. A different colour scheme could likewise be selected for users with colour blindness. With CSS you can define different layouts for PDAs and when printing.

However - and this is a big however - web pages are viewed by the majority of people via web browsers. The most used of these are Microsoft Internet Explorer (IE), Firefox (Mozilla), Netscape and Opera. These have evolved over many years, and all display the same page in different ways. They have their own interpretations on the precise meaning of HTML and CSS statements. And you have to bear in mind that these are massively complex applications, since web pages can be very complicated.

In addition to the different interpretations, they all have a swathe of bugs that interfere with the page display (and page printing). More worryingly, they only partially support the latest (release 2) of CSS.

CSS - The Problem…?

If you look at CSS guru sites on the Internet, you will see a lot of clever CSS design ideas and techniques. Unfortunately, a lot of them have to be clever in order to overcome the shortcomings in the different web browsers and get similar display results. But there is something much more fundamental that seems to have been entirely missed: that CSS itself is a very immature markup language, with its own shortcomings.

By far the best example makes for an amusing story, if you can see it in the right light. It concerns a concept called the CSS Box Model. This is a truly fundamental part of CSS and, indeed, of any kind of page layout. We're talking about a box that may contain text or images or both. The box model allows styling to be defined regardless of content. The basic components are an optional set of left, right, top and bottom margins, borders and padding. The box content is surrounded by the padding, then the border and finally the margin. The latter allows boxes to be separated from each other, and the padding to give content separation from the border.

All good so far. Except that the CSS designers chose to define the width and height of the box to be the content part. Not the whole box with its padding, border and margin. Merely a part of the box. This is profoundly crazy, as you'll see.

If you define a box to have, say, a 10 pixel margin, 1 pixel border and 5 pixel padding, with a width and height set to 100%, then you are defining a content area that will fit the whole browser screen. Regardless of the browser size, you will always have scroll bars. These are required to see the right and bottom padding, borders and margins, which take the size beyond 100%. So, no matter how big you make the browser window, the box will be too big to display!

The funny part of it is that when Microsoft developed IE 5.5 they made a sensible assumption that the box dimensions were just that - those of the box, and not the content! And there are many thousands of users still using IE 5.5, so current box definitions must add a tweak to correct for IE 5.5 which actually got it right from a design point of view!

Fortunately, the CSS 3 draft specification addresses this issue with box-width and box-height keywords. But this is merely the tip of the iceberg. The CSS float feature allows boxes to be stacked left or right on a page. When printing a page in the Netscape browser, if a floated box exceeds the page end during printing, then all subsequent pages are ignored.

For example, I have a web page that is centred in the browser. I have had to add a 1 pixel border around it to stop Netscape losing parts of the page when the browser window is too small to display it all.

Too Much, Too Soon?

But CSS has a much more significant problem. It is grossly immature as a page layout mechanism. In the days when tables reigned supreme, layout was extremely flexible. But tables are in the HTML domain. They should hold content, not presentation. This breaks the accessibility rules - a table-based page viewed on a text-only browser can be so disorganised as to be inaccessible. But CSS has very limited page layout support, failing to provide :

• Support for multi columnar boxes
• Article flow from one box to another
• Box relations to others by name to allow controlled page layout
• Page centring without trickery

...and so on. Couple this with browser bugs in the box float mechanism, CSS design is a black art at present.

Size Matters!

There is also the sticky accessibility matter of text sizing for the partially sighted. IE provides five ranges of text resizing, from small through normal to large via the View | Text Size menu option. It will resize all the text on the page except for text that is defined with precise pixel (as opposed to point) sizes. And, curiously enough, it will fail to resize form data entry box text. This is a truly serious shortcoming.

Netscape and Firefox also provide text resizing in a similar way. Except that the resizing affects box layouts more often than not. On one page of mine, a zoom to 150% moved an image from the left to the right of the page, overlaying text. But a zoom to 200% saw it move back to the left. This is bizarre. More insidious is the pixel font text - which it also expands. So your nice fixed-size page banner text in IE is resized in Netscape. It's even possible to corrupt the display of the the Netscape home page when viewed at 200% magnification in Netscape's own browser!

Opera have chosen a different way of looking at text resizing. In hindsight, it looks to be by far the best solution: an intuitive approach to the problem where resized text affects screen layout. They simply resize the whole web page. The other browsers cannot complain that the technology to do this is difficult since they provide a similar zooming facility when print previewing.

The poor web designer has to juggle bugs and inconsistencies in the browsers, and shortcomings in CSS in addition to these accessibility requirements. A tall order. So let's do some forward thinking. We'll look forward to CSS 4 in the expectation that it may really get to grip with page layout needs, and a suite of browsers that fully support it. Then we can more readily meet the accessibility requirements. But this is many years ahead - there has been no major release in IE for two or three years, and older versions still are so much used that the juggling process is set to continue for a number of years.

But for one matter. Given the ever increasing threat of web site litigation, it can only be a matter of time before the browsers themselves are targeted and their developers made to account for their failure to make for consistent accessibility. The days when these companies have a free reign over the ways in which they implement the standards may be fast disappearing.

Neil Moffatt is a programmer, artist and photographer based in Cardiff, Wales. He has a strong interest in usability and puts this into practice with www.delphibasics.co.uk, a tutorial and reference site for Delphi and www.designbasics.co.uk, a more explicit portal for usability ideas.

December 2005