5th February 2009 by Liam McGee
The Priority Trust gives physically disabled children and young people greater independence by funding mobility equipment and sharing experiences; helping them to participate in society as independent, mature and responsible individuals and achieve their potential.
Communis are very pleased to have been chosen to develop their new web site, which can now be seen at www.prioritytrust.org. Please take the time to pay a visit.
12th December 2008 by Liam McGee
WCAG2.0 has arrived! The bouncing baby new de facto accessibility standard arrived into the world yesterday – December the 11th, 2008.
Being the accessibility obsessives we are, we eagerly tore open the metaphorical wrapping paper and started to play with it without reading the instructions. Unlike previous versions released, this is the stable standard and can be referenced with confidence. It’s not going to change again for a long time.
So, first impressions… I’m very pleased to see how thoroughly and extensively the W3C have consulted with the web community about this document – I was also pleased at how the contributions from developers (like us) and ordinary users (like lots of people we know) have been integrated and treated with as much care and respect as if they had come from Microsoft or Mozilla. This is not imposed from on high, this has emerged, flower-like from the contributions of the community as a whole. As a concrete example, we thought the previous ‘beta’ version was not the easiest to read. So we suggested an alternative. They responded with some thoughtful and constructive criticism, which we acted on, and then the improvements to the styling were gracefully implemented. A second example. I wrote in at one point a few months ago querying one of the requirements that asked for ‘liquid’ site designs. I disagreed. One of the team working on the document responded, disagreed right back, but very gracefully, and I amended my criticism to take into account some of the good arguments they raised. The result? The language around that checkpoint is now clearer takes into account my concerns. Again, I am very impressed by the development process.
WCAG2.0 is best thought of as a set of 4 mutually supporting documents – the first is main WCAG 2.0 document, containing the guidelines in a form that would be useful for technical specification, legal requirements etc. The second is the Understanding Wcag2.0 document, which goes into more detail about each checkpoint. It explains, in fairly straightforward language, the intended effect of the checkpoint, the benefits of implementing it, and gives some concrete example situations in which it should be applied. When you consider what was available for WCAG1.0, the improvement is immense, especially when considered alongside the Techniques document that gives more examples including mark-up to support them. One tiny niggle is that the styling breaks down slightly in Google Chrome, but this will doubtless soon be resolved.
The piece de resistance is undoubtably the customisable quick reference, billed as a ‘a key resource for designers and developers using WCAG 2.0′. I have to agree . This is a shorthand set of all guidelines and references that can be customised to display only those that apply to you site. If you aren’t using any rich internet apps (RIAs) then just switch off the WAI-ARIA applicable guidance. Couldn’t care less about SMIL? Then strip those references out with the click of a mouse. Or, this being WCAG, the prod of a key. Or the wave of a head-wand. Improvements could be made – for example, I’d like to kill all audio/video references if I’m not using them, but otherwise, a great effort.
A valiant attempt has been made at WCAG2.0 Documents to show how they fit together.
All very well, you may say, but what is it like to use in practice? I threw it at a wireframe I was building, and it was very interesting. Firstly, it’s less prescriptive… and the result is that it makes you think more. Techniques are referred to as ‘sufficient’ – in other words, you could meet the success criterion by doing this, but if you can come up with a better way? Why, go right ahead. There’s enough information there about the intent and benefits of meeting that criterion that allows you to make a clear cut decision about whether your alternative method is a reasonable substitute.
The AAA guidelines – always a contentious subject in WCAG1 (did anyone ever use access keys without messing up the functionality for some users, somewhere?), are far more sensible. For example,
Contrast (Enhanced):
1.4.6 The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
Firstly, this is very easy to see whether you have passed or failed. Secondly, it’s a similar but stricter version of the AA requirement. Thirdly, it gives you a get-out clause for branding/logos. If part of the brand value is ‘extremely subtle’, then you can keep that pale grey on white logo. But that body text had better be readable.
All in all, looks great. I look forward to applying it to many projects to come.
14th November 2008 by Liam McGee
WCAG2.0 is coming into force this Christmas. WCAG2.0 is a new set of accessibility guidelines from the W3C that supersede their current WCAG1.0 requirements.
WCAG2.0 has been a while coming – it resolves many of the ambiguities and historical anomalies in WCAG1.0, and takes into account the development in web technologies since the release of WCAG1.0 in the late 1990s. In fact, WCAG2.0 has been designed to be largely futureproof, starting with overarching principles and basing guidelines around them that should be applicable independent of technology.
The technology-specific methods for achieving compliance with the guidelines are removed from the guidelines themselves, and held in a separate techniques document. This latter document will be updated as developers (such as ourselves) come up with more effective ways of meeting a guideline. For example, WCAG2.0 already has many overlaps with the W3C Mobile Web Best Practice Guidelines. As the mobile web expands (and it will, now Google is involved), new techniques will be published to fill any new gaps.
Perhaps the most interesting difference between WCAg1.0 and WCAG2.0 is the fact that WCAG2.0 has been designed with enforceability in mind, WCAG1.0 never really made it onto the statute books as it allowed a lot of leeway for interpretation. WCAG 2.0, however, has been developed in coordination with other national and international standards; it is designed to make conformance claims legally testable, and so allowing governments to legally define required standards of accessibility.
The good news is that sites that already meet both the letter and the spirit of WCAG1.0 will require few if any changes to claim WCAG2.0 conformance. However, we suggest that anyone serious about ensuring their web site content reaches the largest audience possible.
WCAG2.0 is already available as a Proposed Recommendation (and unlikely to change in any significant way) at www.w3.org/TR/2008/PR-WCAG20-20081103/
10th October 2007 by Liam McGee
We’ve been thinking about accessible typography lately. The readability of text, to be precise.
Readability can be considered to be a function of margin space, leading (line height) and line-length. Traditionally, a line-length of approx 3 alphabets (the actual em-width of this will vary according to the font) seems to be ideal in balancing the number of new-line interruptions (for which longer lines are better) with the ease of returning to the beginning of the next line without losing your vertical position (for which shorter lines are better). Leading needs to take into account the difference in height of lower case and upper case letters in the font, known as the x-ration (the ration between the height of the capital X and the lower case x).
The other main typographic properties which affect legibility are font size and contrast.
Font-size
It’s rather hard to categorically state a minimum font size for legibility, as the legibility of a letter is based on the angle subtended by that letter on the reader’s retina — which is a function of the actual size of the letter and the distance of the reader.
Unfortunately as soon as you introduce a computer screen, there is an added complication in that the size of a character 12px high will vary significantly depending on the physical size and resolution of thescreen.
Contrast
There are specific rules about foreground/background contrast within the W3C WAI WCAG guidelines, and it’s one of the most common and significant design problems we see in accessibility testing. The palest allowable grey on a white background, for example, is #585858… or at least this is the case under WCAG1.0. WCAG2.0 is a different story, more about that in a later article.
8th August 2007 by Liam McGee
We often see sites where the site author has attempted to hide elements from sighted users by making use of the display:none style property.
Unfortunately, screenreaders interpret CSS (cascading style sheets).
As a result, assigning this style to an element removes it completely from the document flow for any user agent that interprets CSS, and that includes screenreader users. Note that visibility:hidden has exactly the same effect – screen readers ignore any element with this property.
So what should you do to provide information only to screenreader users? Well, firstly you should consider whether it’s really not relevant to users using other browsers. If this is clearly the case (its instructions on an interface for JAWS users, for example), then there are several alternatives.
title attribute. We’d avoid this one. In our experience most screenreader users don;t bother listening to title info unless they are both a sophisticated user of their software and patient enough to bother.position: absolute to position off-screen. This is our preferred solution. Note that you should position a long way offscreen, and it should be off to the left. Shift them in any other direction and you risk losing them on some software (Window Eyes, for one). Internet Explorer (IE) also gets confused by this method unless carefully implemented. Don’t place lists of links offscreen (IE loses the first item on an occasional basis), and make sure you use both top and left both when positioning offscreen and when bringing it back on (when a link recieves document focus, for example).17th April 2007 by Liam McGee
Liquid designs (where the design ‘flows’ into whatever window width it finds itself in) can cause problems when resized as column widths cannot increase in ratio with the text base size. This results in broken layouts at large text sizes. We use x3 as a rule of thumb — increasing the base font size to 300% shouldn’t break the design. Users who require magnification above this level are likely to be using separate screen-magnification software and will handle it in a different way.
The advantage of elastic layouts (i.e. where the overall width of the design is a ratio to the base font size) is that the design is much less likely to break on font size increase — it introduces horizontal scrolling, but that’s far more acceptable than making the design unreadable. The down-side is that you don’t take advantage of the screen real-estate provided by full-size windows on larger monitors, as you really have to design to a content width of 780-ish px (i.e. allow for users with 600×800 resolution monitors).
Visco-elastic design is what we call a method to overcome this problem with elastic layouts — it’s a set of several elastic layouts optimised for different window-width ranges. The detection of of the window width is performed by javascript and the appropriate style is presented (ideally you would cookie the preference so that the appropriate stylesheet was presented immediately). You would present the simplest (i.e. the narrowest) style by default, with more complex, multi-columnar layouts presented if window width is sufficient.
It’s definitely one for perfectionists, but it’s an interesting solution to an annoying problem.
17th March 2007 by Liam McGee
Readability/legibility are functions of margin space, leading (line height) and line-length. Traditionally, a line-length of approx 3 alphabets (the actual em-width of this will vary according to the font) seems to be ideal in balancing the number of new-line interruptions (for which longer lines are better) with the ease of returning to the beginning of the next line without losing your vertical position (for which shorter lines are better).
The other main typographic properties which affect legibility are font size and contrast.
Font-size
It’s rather hard to categorically state a minimum font size for legibility, as the legibility of a letter is based on the angle subtended by that letter on the reader’s retina — which is a function of the actual size of the letter and the distance of the reader.
Unfortunately as soon as you introduce a computer screen, there is an added complication in that the size of a character 12px high will vary significantly depending on the physical size and resolution of thescreen.
Contrast
There are specific rules about foreground/background contrast within the W3C WAI WCAG guidelines, and it’s one of the most common and significant design problems we see in accessibility testing. The palest allowable grey on a white background, for example, is #585858.
2nd February 2007 by Liam McGee
More and more these days we see significant overlap between what we do for our clients in terms of accessibility, and what partners of ours who work in the fields of usability, search engine optimisation (SEO) and web analytics are also recommending.
These are just a few examples.
But accessibility specialists won’t solve all a web sites problems. Nor, indeed, will an information architect, a graphic designer, an SEO specialist, a web analytics expert or a usability lab. For the most robust, successful web site designs, you need all of the above!
Templating, scripting, URL structure, server responses, interface design — all of these are examples cooperation from accessibility, usability, SEO and analytics specialists are required to ensure best results.
As our profession matures, we are going to see the most successful site design teams being those realise that no one person can know everything. Happily for us, we have a team of internationally respected experts in each of these fields to call on for larger projects. Keep your eyes open for case studies that show this integrated approach.
14th November 2006 by Liam McGee
How did it get to November so quickly? We’ve been very busy, that’s how… the weeks have flown past. Student Investor 2007 is a share trading game for schools – Communis have developed and run the game on behalf of ifs School of Finance (previously ifsProShare, previously ProShare) since 2005. This year’s incarnation launched at the beginning of the month, and we have seen tremendous activity on the site. In the first week alone, monday to friday saw:
Phew!
4th September 2006 by Liam McGee
Web2.0 is the latest marketing buzzword in the industry. It refers, roughly, to the idea of working towards the use of web communication protocols to create collaborative web-based applications. For example, social networking tools allow a large number of users to ‘tag’ web pages, adding information about the page (‘metadata’) that can then be used for categorising and searching by relevance and by popularity.
A loose collection of web applications based on Ajax (a javascript-based programming method) has evolved over the last year or two. The applications often allow other developers to piggyback on top of them to create ‘mashups’ — for example overlaying your own data on top of Google Maps.
Examples of successful web 2.0 applications are blogging (e.g. Blogger); tagging (e.g. del.icio.us); photo sharing (e.g. Flickr); mapping (Google maps); collaborative office applications (e.g. Google spreadsheets, Writely); project management tools (e.g. Basecamp); collaborative news (e.g. Digg).
While the applications are interesting and powerful, frequently heavy reliance on javascript, vision and mouse-use is heralding a new challenge for those with a vision of a standards-compliant, accessible web. Well formed, valid HTML is rare. Easy implementation of Ajax scripts for basic functions (online forms, for example) can render the site unuseable to people with older browsers or restricted or disabled scripting. While IE and Firefox are usually supported, users of other browsers are often excluded. Applications rarely give much thought to interoperability, usability or accessibility. Most importantly, there’s not that many people out there using these applications yet — not when compared to the numbers of people using ‘Web 1.0′. Beware Web 2.0 solutions for your shopping site!
On the plus side, the very openness of several of the applications (noteably Google maps) means that people like ourselves can rework them to make them accessible, useable, well-formed and search engine friendly. A start is being made by the good people of the W3C on a set of standards for ‘Accessible Rich Internet Applications’ (ARIA), the WAI-ARIA Roadmap. So first we sort out the teething troubles. And then Web 2.0 can really get going.