boogdesign blog

Web design, web development, standards compliance, Linux, events I went to related to that, and random things I found on the internet.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now


12:53:59 am Permalink Links for October 18th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


12:53:45 am Permalink Links for October 11th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


12:17:06 am Permalink Links for October 4th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


02:32:00 am Permalink Links for September 27th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink


11:55:14 pm Permalink Standards.Next Cognition and Accessibility

Categories: Web Design, Usability & Accessibility, Front End Web Development

Review: Standards.Next Cognition and Accessibility at City University, Room C343, Northampton Square, London, England EC1V 0HB 13:00 to 17:00

Last weekend I went to the second Standards.Next event, a whole afternoon devoted to talks and discussion related to the often ignored and misunderstood area of accessibility for people with cognitive impairments.
Picture of the audience listening attentively to Ian Pouncey

Accessibility beyond code - Antonia Hyde (slides)

Antonia talked about some of the issues in enabling access outside of the details of code. With the range of disabilities, plethora of personal preferences and array of access methods are there any general approaches which help to address all the combinations? To provide some context we watched two video clips of Martin, an experienced web user with learning difficulties. First we saw him using a site he was familiar with, eBay, then a site he was unfamiliar with, Amazon.

Martin got on very well with eBay, he made extensive use of its consistent search features and the nature of the site means that it features a lot of large meaningful pictures which are the focus of the content. Even so, there were some details which caused issues which perhaps were not significant enough that the designer would even think of them. For instance there is a 'Buy it now' button on the product pages which, not surprisingly, allows you to bid for the item, but there is also an identical 'Buy it now' image on the search results which wasn't clickable.

On Amazon, a site often lauded for its usability, Martin had a great deal of difficulty. There was a lack of meaningful icons, a lot of the most striking imagery on a page was unrelated to the main content, there was often bad typography and poor contrast and the buttons were not clearly defined. Martin had great difficulty first of all trying to sign up for the site and then trying to buy something.

Antonia then talked about some general strategies for making sites more accessible:

  • Be literal: This doesn't mean going in to excruciating detail, it means saying things simply and clearly with no contradictions. It also means grouping page elements and respecting the hierarchy of visual language, having consistent colour coding and using meaningful icons with related words. There was a great (but bad) example taken from a warning sign on the Underground - the text says "Don't run on the escalator" but the graphic shows a man happily running down the escalator with his briefcase.
  • Make things bigger: Not just literally, for instance having space around items can make them appear bigger. Also having obvious tools for text sizing, alternative colour schemes and content access methods can really make or break the accessibility of a site. We got into a bit of a side discussion at this point about why users didn't just use built in browser functionality for this, the gist of it was that browser manufacturers need to find a way to make stuff more discoverable.
  • Responsibility: Accessibility is the responsibility of all people involved in creating a website - designers, developer, content producers and managers are all equally responsible. Cohesion and consistency is a key factor in accessiblity, and content is useless if it can't be accessed.

What is Autism - Jamie Knight (slides)

Jamie is a web developer who is autistic. He gave a presentation on what autism is and this was followed by an open discussion. Autism means having a thinking process which is slightly different in the way it processes ideas and inputs from the environment. Some things which are problematic for autistic people are:

  • Background music on websites, and background noise in general, make it impossible to read
  • Language coming too quickly (eg. in video or audio), especially if there are multiple speakers with no delay or visual pause between them
  • A literal mindedness can lead to confusion, eg. "Add friends" means a different thing on almost every website, especially in Facebook where it means different things on different pages

On the other hand the web can be extremely liberating and empowering for autistic people, because it removes a lot of the time pressures of traditional social interaction (Antonia also mentioned this). In the interesting discussion that followed Jamie discussed how he used a screenreader (originally one he'd written himself) when he was too tired to read, highlighting that the set of people that are using screenreaders is not necessarily identical to the set of people that can't see your site. I also learned about the different voice options available in screenreaders - a faster 'robot voice' or the slower but more 'human' voice which differ in the algorithms used to determine sounds. Jamie used different voices in different situations - the robot sounded a bit strange reading out text in the first person, the human voice has difficulty with some pronunciations.

Why user testing beats dogma - David Owens

David had recently completed a project which included a lot of testing with users who have cognitive issues. There were no slides but it was good to hear from someone with practical experience of the sort of issues which can come up:

  • Before they even started their testing they had to rewrite all their user testing scripts as they were too complex and lacked context - it's not just your website that needs to be accessible.
  • Don't overcomplicate. When developing they'd paid particular attention to the source order - putting the main content first and the navigation after it. What this does is completely confuse screen reader users, especially the partially sighted ones for whom the layout of the page on screen no longer matched what they were hearing.
  • Reiterating one of Antonia's points, you must signpost the tools. Mostly users won't remember how to find their browser's text size option, or the key combination required.
  • If it comes to a choice between 'best practice' or the standards and what your test results show, always choose to make things easier for your users.

Content and Cognition - Ian Pouncey (slides)

Ian presented some practical advice based on his years of experience working in web accessibility:

  • Consistency: Make your navigation consistent, don't chop and change main navigation between pages; use a small number of fonts, counting different sizes and weights as different fonts; make sure your interactive elements, links and buttons, are the same across all pages and clearly are links and buttons.
  • Structure: Make sure your headings are clear and meaningful and represent their associated content; Break content up into lists, keeping each point short and concise; Make use of whitespace, particularly horizontal spacing; clearly differentiate content types, eg, quotes.
  • Focus: Avoid contrasting blocks of colour, eg. don't make your navigation more visually appealing than your main content; Avoid unexpected sound and moving content; Avoid popup windows and (after some comments from the audience) light boxes.
  • Readability: Make sure you have adequate text size and line height; Limit your line length to 70-80 characters but avoid justification because of the 'rivers of white' problem; Make sure you have good colour contrast; Keep your paragraphs short.
  • Transformability: Bearing in mind that you can't please everyone, you should make sure your content is easily transformed - ie. allows for resizing; Supports user stylesheets; Works well with images and/or styles disabled;; Make sure your content is printable, as many people prefer to read from paper; Provide an API or feed for when all else fails. In this section also mentioned that he thinks elastic layouts (where the size is based on the font size) are a bad idea - they make text resizing behave like page zoom, in effect taking an option away from the user.
  • Content: Pay attention to your spelling and grammar, if you can't get someone else to review your writing then leave it for a few days and look at it with a fresh eye, also getting a screen reader to read it to you may help; Define your terms, avoid jargon but not at the expense of clarity; Always summarise your content - point, example, explanation, summary.
Ian then gave a practical example of reworking a simple web page to be more accessible and some of the techniques you might consider. In the discussion we got on to CAPTCHAs and related techniques:
  • Don't assume that 'simple' tasks are simple, eg. 2+2 and Dyscalculia.
  • Similarly, questions like "What colour is the sky?" can cause problems both for those with a literal turn of mind and for those who struggle with language.
  • Remember it's your job to determine if it's spam or not, not your user's.

The day concluded with Bruce asking for people to get involved with the WHAT-WG HTML5 work and share their opinion on two particular issues:

  • The table summary attribute is to be removed in HTML5, as in HTML4 it is little used and is only to be read out to screen readers. The alternative currently recommended by the working group is to summarise the table in the preceding content.
  • Another issue of concern is with the new HTML5 form controls. Currently they are not styleable with CSS, which means they will present as the host operating system defaults, which is good for consistency. On the other hand, if they're not styleable it's far more likely designers won't use them and will instead come up with their own non-standard controls, thus losing the semantic benefits.

If you have any opinions, please contact Bruce.

All in all another great day, 5 out of 5. Watch the website for news of future events in the series or follow #standardsnext on Twitter.

Technorati tags for this review:  

Tweet this!
Send feedback »PermalinkPermalink

02:46:50 am Permalink Adventures in Web 3.0: Part 3 - More CSS 3

Categories: Front End Web Development, Standards, HTML and CSS

I talked about CSS3 in the last post in this semi-regular series on the web standards of the future, but there are some new features supported in the latest Chrome release and Firefox alpha which make this worth a second post. This time I'm going to focus on background sizing, CSS gradients and RGBA colours.

To start with, scaling background images with the background-size rule. I started off with the example code from the MDC article on -moz-background-size and tried to make a background image that covers the entire page:

body {
    background-image: url('bg-image-1.jpg');
    background-size: 100% 100%;
    -moz-background-size: 100% 100%;           /* Gecko 1.9.2 (Firefox 3.6) */
    -o-background-size: 100% 100%;             /* Opera 9.5 */
    -webkit-background-size: 100% 100%;        /* Safari 3.0 */
    -khtml-background-size: 100% 100%;         /* Konqueror 3.5.4 */
    -moz-border-image: url('bg-image-1.jpg') 0;/* Gecko 1.9.1 (Firefox 3.5) */

This results in a page which looks like this:

Screenshot of scaled background image in Firefox

As you can see above, there is a way to support scaled backgrounds in Firefox 3.5 by using -moz-border-image. A while back I'd read a comment which indicated that border image ought to be able to achieve this sort of thing but, when I tried to understand the spec, I couldn't figure it out. The example above shows it's a lot less complex than I thought back then, unfortunately it doesn't work that well for this particular use case as the border-image inherits from body to html. This is not as weird as it might seem, there's specific discussion in the CSS spec of the inheritance relationship between the two - read the third and fourth paragraphs of this section. Unfortunately, you end up with a repeated background, even if you explicitly set the background and border images to none. The workaround for this, if you want to support Firefox 3.5, is to make sure there's no margins, padding or border on body in which case the repeated background will be covered up. The alternative, which I will follow for most of the rest of my examples, is not to worry about supporting Firefox 3.5.

A second problem is that the background image only covers the area taken up by the body, if your browser window is longer than the body then the image repeats down the page. For certain images this may be what you want, in this case I wanted it to cover the whole background. This is easy to fix by adding background-attachment: fixed; to the CSS to arrive at my second example. This is what it looks like in Firefox with that change:

Screenshot of scaled background image in Firefox

In Chromium, the scaled background image generally seems to be better quality - there is an image-rendering property but it didn't seem to make much difference.

Screenshot of scaled background image in Chromium

It also works in Opera 10, but only on Windows, and it doesn't scale to the full page height, and looks only marginally better than browsers with no background scaling:

Screenshot of scaled background image in Opera 10

The other problem with background-attachment: fixed; is, if your page is longer than a single screen, it noticeably impacts performance as you scroll up and down the page and the browser is forced to re-render everything.

So, having successfully scaled a background image across the entire page my thoughts turned to the page content, now almost unreadable. Since this is the sort of arty design which is all about the background image we don't want to cover it up completely, but we do want to provide enough contrast to read by, so some sort of semi-transparent background is in order. There are all sorts of ways to do this already, and several of them can be made to work across browser (and so would be the ones to use in any 'real' website, of course). But rather than have an alpha transparent PNG as a background, or use CSS transparency on the back one of a pair of nested elements, let's use RGBA colours to set a semi-transparent background colour:

h1, p {
    background-color: rgba(255,255,255,0.5);

This specifies values for red, green and blue respectively as numbers between 0 and 255 and then a number between 0 and 1 for the transparency. So bright red would be rgba(255,0,0,1). This does make the text a bit more readable while leaving the background visible:

Screenshot of RGBA backgrounds Firefox

But perhaps, in the interests of exploration, we should relax this pesky 'readable' requirement and see what other effects can be achieved with CSS 3. One interesting possibility is the new gradient property introduced by WebKit and now also supported in the next version of Firefox. This allows you to produce some pretty crazy effects without any images at all:

Screenshot of gradient backgrounds Firefox

The bottom paragraph is the one I started with and it's fairly straightforward, here's the code for it:

p {
    background-color: transparent;
    background-image: -moz-linear-gradient(top left, bottom left, from(rgba(255,255,255,0.9)), to(rgba(255,255,255,0)));
    background-image: -webkit-gradient(linear, left top, left bottom, from(rgba(255,255,255,0.9)), to(rgba(255,255,255,0)));

Unfortunately there are two different syntaxes. In Firefox/Gecko the gradient type is part of the rule name - -moz-linear-gradient - whereas in WebKit the type is the first parameter (the alternative to linear is radial). There's no W3C spec at the moment, so it's possible neither option will be the same as the standard. I also found that Chromium didn't work too well with top left though I don't think the order should make any difference. In both cases, what is specified is a linear gradient, from top left to bottom left starting at white with 90% opacity, ending at white with 0% opacity (ie. transparent). Note that, because I was inheriting a background-color of 50% opacity white on the p elements, I had to override that in this rule to make the bottom of the gradient fully transparent. This could cause some problems in practical scenarios, as you may want there to be a background colour where there is no gradient support and the gradient otherwise. An approach which works in Firefox is to use a background property instead of background-image, Firefox 3.5 then displays the default inherited RGBA background and ignores the whole rule with the gradient:

background: -moz-linear-gradient(top left, bottom left, from(rgba(255,255,255,0.9)), to(rgba(255,255,255,0))) transparent;

Of course, you could achieve the gradient effect with a tiled PNG background image, with background-size you could even make it stretch to fill behind arbitrary content, so why would you bother? There are two reasons:

  1. There is no need to download an additional file from the server, so pages should load (slightly) faster
  2. The gradient is recalculated when the browser is zoomed, so it will always be smooth, no image resizing artefacts

So, now we're into the spirit of things, let's try something a little more complex. The next gradient I added a colour as well as a transparency and also tried to make at an angle by going from top left to bottom right:

p {
    background-image: -moz-linear-gradient(top left, bottom right, from(green), to(rgba(0,255,0,0)));
    background-image: -webkit-gradient(linear, left top, right bottom, from(green), to(rgba(0,255,0,0)));

As far as I could tell, this made no difference - the gradient still went straight across the image:

Screenshot of linear gradient from top left to bottom right Firefox

Since the browsers seem to be ignoring it anyway, I removed the top and bottom. In Firefox this made no difference, however in Chromium it stopped the gradient showing at all. So although you have to specify both directions in Chromium, it always ignores at least one of them. If two match then they will be ignored, if they're all different then it's not clear which way round your gradient will be - try it and see.

With CSS gradients you're not limited to heading smoothly from a single starting colour to a single ending colour, you can also visit any colour you want in between with a color-stop:

p {
    background-image: -moz-linear-gradient(left, right, from(rgba(255,0,0,0.8)), to(rgba(128,0,255,0.8)), color-stop(16%, rgba(255,165,0,0.7)), color-stop(32%, rgba(255,255,0,0.6)), color-stop(48%, rgba(0,128,0,0.5)), color-stop(60%, rgba(0,0,255,0.6)), color-stop(76%, rgba(75,0,130,0.7)));
    background-image: -webkit-gradient(linear, left top, right top, from(red), to(violet), color-stop(16%, rgba(255,165,0,0.7)), color-stop(32%, rgba(255,255,0,0.6)), color-stop(48%, rgba(0,128,0,0.5)), color-stop(60%, rgba(0,0,255,0.6)), color-stop(76%, rgba(75,0,130,0.7)));

This final example, which I adapted from the MDC page, paints a rainbow in the background. You can have an unlimited number of colour stops in your gradients, simply specify a percentage and a colour. If you specify 25% and blue then you gradient will pass through blue a quarter of the way along.

This post has been in gestation for over two months and I find myself well over my thousand word target for a post and only halfway through all the stuff I wanted to cover, so there will be at least one further post on CSS3. Having covered the basics of scaled backgrounds and gradients in this post, I'm aiming for some practical ways to use these features in web pages of the future.

Tweet this!
1 feedback »PermalinkPermalink


01:33:50 am Permalink Links for September 20th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink