From Accessibility to Zope

When in 1981 Steve Jobs said that “Rectangles with rounded corners are everywhere” he began a trend which today sees dozens of rounded rectangles on millions of PC screens almost all the time.

On the web the situation is even more desperate. Bound by the available technology, and aiming towards intuitive and usable HCI, designers often draw on rounded rectangles to make functional layouts appear more friendly and personal. More than that, using rounded rectangles is perhaps the simplest way to design a site that isn’t just boxy and dull.

In CSS, there are two well-known approaches. The fluid-width approach is to stick small graphics of rounded corners into each corner of a box - these cover up the box’s corners and make it appear round. The fixed-width approach is to have top and bottom images that comprise the corners, and a tiling background to blend between the two. CSS3 offers an improved background model that will render these hacks unnecessary.

Of course, it’s not necessary to stick to plain rectangles: using the above approaches, it’s possible to decorate them with drop shadows, highlights, stripes, cutouts or whatever else you’d like to. These aren’t just techniques for cutting corners - they generalise to techniques for decorating web-based boxes.

There are some caveats with nested rounded rectangles that you should watch out for. This is how nested boxes with rounded corners should appear.

The arcs for all the nested rounded boxes that share a corner should be arcs of concentric circles. In practice, this just means tweak the radii until they look right - so that they appear to focus on a point. Any square boxes should fall inside that focus.

Notice in the diagram below how square corners don’t work unless they are inside the focus. Nesting rounded boxes inside square boxes is an absolute don’t. A more common mistake is to use the same corner radius for an outer rounded rectangle as for a nested one. Most tools preserve the setting for corner radius, and that’s not what you want. Notice how the outer box appears proud in the diagram below, right (cf. above, left)

Notice below how when the boxes don’t share a corner, you can use the same corner radius, but the effect is slightly different. Using the above rule-of-thumb throughout will keep the design a little more down-to-earth.

A lot of hobbyist web designers start by creating the content for their web pages, then try to add graphics to “spice it up”. This is a mistake. It’s very hard to make a page look appealing in retrospect.

Start with a high-quality vector graphics tool - I recommend Inkscape - and properly design the website. To represent where to put content use Lorem Ipsum or simply rectangles to represent individual paragraphs. Once you are satisfied with a design, recreate it in HTML, exporting any graphical elements you need from the mockup.

You can use this approach even for sites that don’t need graphics; it is beneficial for choosing colours, fonts and layouts as well as for creating fully graphical sites.

Be careful though - you need to design a mockup that you can successfully convert to HTML. Graphics programs are WYSIWYG but the web is not and this places constraints on what you can successfully produce. Beware in particular of how the site changes as your browser window or text size changes.

Most mistakes web designers make stem from the assumption that the way they are seeing the site in their web browser is the way everyone else sees it. By using uncommon defaults in your web browser, you can ensure that you have left to the default only those aspects of a page which you had intended. I call this “misconfiguring” because it is intentionally configuring a web browser to display pages wrongly. If the page looks correct with such settings it is probable nothing has been left to chance.

It is common practice to test a web site in various web browsers, but this testing can give a false impression of the compatibility regarding different default settings. This is because almost all browsers have settled on a common out-of-the-box set of defaults. The user is allowed to override these defaults. Fail to anticipate this and your website risks visual problems for some users (perhaps 1% or so, to take a wild guess). Problems include:

• Character set issues, such as £ or the opposite, a broken character symbol (the question mark diamond in Firefox) rather than £.
• Specifying a font colour but not a background colour, causing clashes or even invisible text. Perhaps 10% of websites fail to specify a page background colour but assume that it will default to white.
• Linking images which are intended to composite onto white. This looks dreadful onto most other colours.
• Copy looking illegible due to tiny serif fonts (sans-serif is more legible on low-resolution screens).
• Body font clashing with image-based buttons and titles: serif and sans-serif fonts rarely mix.
• Pale-coloured boxouts. What appears pale is in fact a function of the background colour. A light pink box appears pale on a white background, but very bright on a black background, for which the corresponding effect would be a dark red box.

The browser defaults which you may want to change include

• Character set
• Background colour
• Text colour
• Font style
• Font size, although in theory you should avoid specifying this for accessibility reasons.

Misconfiguring a web browser is an art. It is perfectly acceptable to use the defaults a user specifies, as long as all of them are respected. While you should feel free to wholly b0rk a browser which you use purely for testing, it is more beneficial to misconfigure the web browser that you use for primary development. For me, this is the same web browser that I use for everything else, Firefox. Therefore the misconfiguration has to be something that isn’t wholly unusable to me. More importantly, the new defaults have to be ones that I would be unlikely to use for a website, otherwise I could still rely on my defaults.

Because I tend to use sans-serif fonts, white backgrounds and black, grey or blue text, and UTF-8 character set, my browser is set to default to serif, coppery-orange text on a mid-grey background. I’m experimenting with ISO-8859-11 (Thai) as my default character set, because this isn’t compatible with UTF-8 nor ISO-8859-15 for the most common problem area: £ and € symbols. It is compatible for ASCII-range symbols, so try UTF-16 if you are aiming for perfect incompatibility. I don’t specify font-size but I Ctrl-roll my mousewheel on occasion to watch how the site changes at different font sizes.

So my default browser settings look like this. If I ever see these styles on a page, I know I’ve failed to specify something.

For most of us, visualising date and time comes very naturally. I’m sure if we surveyed how people visualise date and time there would be some similarity among a plethora of different answers. However, one form stands alone for its ubiquity: a year-planner-style calendar. Twelve grids of numbers, each seven columns wide, four to six rows deep. Click on a number to do something with that date.

Calendars are so simple for me and - statistically - you that it’s easy to forget that a server-generated calendar like this is actually not accessible at all. The issue here is linearisation: flattening out the days of the calendar to a script that can be read - aloud, in braille… or by a search engine. A calendar in this form linearises to a script that reads like this:

January. One. Two. Three. Four. Five. Six. Seven. Eight. Nine. Ten. Yawn. Zzz. Snore… February. One. Two…

And so on. It’s not useful to read out 365 numbers (366 next year) and expect users to just wait to respond when the day of the year they are looking for comes up.

What is the accessible version? Well, the approach to take is to work out the linearisation we would like first. For example,

The following periods are currently available: the fifteenth of October to the twenty-ninth of November, then the eleventh of December to the seventeenth. Which date are you interested in?

Now, for a web page we might not expect to follow this pattern exactly, but the model is clear: list the calendar information, then query for a date. It looks something like this:

Periods Available

• 15th October - 29th November
• 11th - 17th December

What date are you interested in?

This is not bad even in a graphical user agent; describing calendars as schedules is not hard to visualise. Note that it would be perfectly possible to use Javascript to convert this calendar to a visual representation. Whether using Javascript in this way is accessible is open to debate. There is no reason screen readers can’t execute Javascript. Some, I believe, already do. But there is a trend for graphical browsers to provide Javascript and for non-graphical browsers not to.

I’d suggest if you are willing to forgo an approach that caters ideally to non-visual users, it’s possible to do better. We can cheat the system, almost, by using alt attributes in images and image maps to provide the schedule version as above, but for the images and maps to supply the visual layout. In my latest project, I’m also using line boxes full of images rather than a table. This allows a single <a> tag to span a whole month worth of dates. But what it saves on the semantics, it loses on file size. A cheaper approach might be client-side image maps, especially of the lesser-known form involving <a shape=”"> tags rather than <area shape=”"> elements, or similar features in SVG.

However, even with the approaches I’ve explored above, this is one area where I suspect there may not be a very solution that does equally well for visual and non-visual users. 365 dates worth of information is difficult to represent in a concise form. That’s why we use calendars.

I finished updated my brother’s blog over New Year, and I’m now quite happy with it. I spent ages on a graphical title block in Inkscape. I’m not totally satisfied with the caricatures who are a little more cartoony than I would have liked. The new theme is based on K2, which I do think is pretty.

I had a strange bug with the Google Maps on the gallery which I found after a bit of searching was caused by Google Maps not supporting embedding within XHTML. But I’m pleased that the thumbnailing/unthumbnailing works so well. Previously the map enlarged and reduced; this is much less intrusive in either state.

I did have to disable all of K2’s shiny Javascript features to make it work with my Javascript (for map markers) But they were a UI disaster anyway. One of the advantages to JS over Flash is that it allows us not to create horrific new UI paradigms. So going to great lengths to do so is missing the point.

The other day I doodled some ideas for themes for this blog. Not really based around web design. Just interesting concepts, hopefully.

Just had an idea: how about using Javascript to record client-side usage of your website?

The principle is this:

1. Register Javascript listeners which construct a list of events, particularly mouse, scroll and click events, along with the time that the event was fired.
2. Register an unload event which posts the information as XML with AJAX to a script on the server when the user leaves the page.
3. Browsing sessions can be collated on the server using cookies.
4. Create a player, which reads the events as XML and renders them using a DHTML ‘cursor’ and/or by firing events within the DOM. Could have a time slider and fast-forward controls, etc, depending on how complex you want to get.

Voila - see exactly what people are doing with your site. I have knocked up a test which implements the first two steps, for mousemove events, and that much works, so the whole concept would be workable. I can imagine it would break down if your site uses plugins (or Javascript navigation, depending on how easy it is to replay the events accurately) but that’s a limitation you would have to live with.

There are obviously privacy concerns but this is relatively mild as no personal data would be recorded. Perhaps it could pop up a Javascript window.confirm() dialog asking if it’s OK to record your behaviour. But it would be a very useful tool for examining site usage, especially for commercial sites. This is the way modern marketing works. I leave it up to your conscience as to whether it’s ethical.

Sometimes - increasingly perhaps - I find myself using Inkscape for constructing program assets.

Program assets are a different beast to standalone artworks because you start to have to recombine artistic elements in new ways programmatically.

Most of the time, when web programming, you don’t really need to generate completely original artwork on the fly, but you often need to composite some selection of pre-drawn assets. There are a variety of ways to do this, but Inkscape doesn’t seem to make any of them very easy for me.

(more…)

I’ve been working on this website recently which has really challenged my technical abilities.

I’ve put together a Javascript system, which I’m quite proud of, for implementing quite a lot of Flash-like effects with pure DHTML, with the aim of remaining accessible.

The complete system works like this:

1. You describe and lay out the pages however you want them with XHTML and CSS.
2. You describe transition timelines in an XML-based language. You can animate scalar CSS properties and colour values with cosine interpolation; you can assign attributes and CSS properties; and you can import and replace content in the document with AJAX. For accessibility, the idea must be to transition one page completely into another, although there can be some purely graphical effects in between.
3. The Javascript loads the transitions with AJAX and sets up event handlers to run the transition.

Easy! It’s like developing web pages in CSS, except that you get to animate your CSS properties. There’s also a bit of hackery to smooth over some IE issues.

I’ll post more about this when it’s a bit more polished.

That’s not the bit that has challenged my technical abilities. The technical challenge is working with the clients’ ideas. This job is actually under subcontract so there’s a chain of clients all wanting to get their way, but it seems to me that every time I implement something technically impressive, the clients see what I have achieved and assume that any small modification is an inherently small task. This is not universally true.

I think the site currently looks pretty naff. I’ve not had artisitic control on this one, and it’s a mess. The animations are distracting, and the clients keep asking for something ridiculous, like “make this image fill the screen”. That’s not something that can be achieved in an attractive way with a fluid layout. This was actually in the brief, which was why I originally started with a fixed layout, but one of their first demands was to move from a fixed to a fluid layout, and I can’t seem to get them to understand that’s the trade off.

This is the damage Flash has done to the world of web design. Clients want pointless effects and WYSIWYG modifications, because they’ve seen it on other sites, without knowing the actual situation with respect to accessibility or maintainability.