Web Access Centre Blog

All eyes and ears will be on the Beijing 2008 Olympics website next year when the games swing into action on September 6th. I for one am very excited and hoping to get over there to see the real thing but if not will have to make do with internet coverage for up to date results of what is going on. Given the experience of the 2000 Sydney Olympics website sued by Bruce Maguire for being inaccessible the Beijing Olympics website will be under more scrutiny than it may expect and the word in many accessibility circles is “Will it be accessible and will I be able to access it”?

But of course it’s not just a question of if you can access a site if you are disabled. Internationalisation (also known as i18n) and localisation (also known as l10n) must also be taken into account to ensure ease of access for people from different cultures speaking different languages. Mobile access will also play a key role with people wanting to check results while on the move. This is even more important considering mobile access to the web is higher in Asia than the West given that lack of hardware and Internet connections.

In Part One I’ll be looking at the accessibility of the current site, in Part Two I’ll be exploring ease of access for international audiences and in Part Three I’ll be looking at mobile access.

But first, how does the site currently fair in terms of accessibility? Continue Reading »

Time to vent some steam about the TITLE attribute. This, almost more than any other item in the web author’s toolbox, seems to be misunderstood and overused.

The TITLE is an essential attribute for some elements, such as ACRONYM or ABBR, and is a required attribute for FRAME elements where it provides contextual information that wouldn’t otherwise be obvious to screen reader users.

Unfortunately though, it can be applied to almost any HTML element. Most often we see it on links and images, where it can confuse or even mask essential information. It can create issues on other elements, but for this article we’ll concentrate on the damage it can do to clear link text and images with good ALT attributes. Often creating classic examples of too much accessibility.
Continue Reading »

Commission for Social Care Inspection (CSCI), who have recently been awarded the See it Right logo for accessible websites, has documented their experience of making an accessible webiste working together with their design agency Webcredible and the RNIB Web Access Team. Learn more about how site owners, web design agencies, user testers and consultants can work together to build in web accessibility to a site in the CSCI case study.

Over the last few months I’ve been closely watching the progress of the December 2006 United Nations (UN) Convention on the Rights of Persons with Disabilities. This marks an exciting shift in the accessibility arena as it is the first time that accessibility is mentioned in an international human rights initiative. While the Web Accessibility Initiative (WAI) publishes technical guidelines on how to make websites accessible there has been no global movement to date that outlines the framework of what must be done.

Continue Reading »

There’s been an awful lot written recently about the accessibility assessments in Socitm’s Better Connected reports. Some of it has been… well, let’s just say that some of it has been less than accurate! So here’s a detailed overview of the process we use for carrying out multiple assessments for projects like Better Connected, with some of the background about how we developed this process.

Continue Reading »

A classic example of trying too hard and making accessibility bloopers, can be found when web authors provide too many JavaScript event handlers in an effort to ensure device independence. This is the fifth in our series of articles on “too much accessibility“.

Ensuring that users can make JavaScript events work, regardless of the way that they access your web page is vital. Users should be able to activate JavaScript events whether they use a mouse, keyboard, pointing / switch device or any other means of navigation.

However, if two or more event handlers, designed to perform the same task are used, the effect can be the opposite of the one you intended. Continue Reading »

WCAG1, WCAG2, WAI, W3C, EOWG… for those new to the world of web accessibility, the plethora of acronyms can be totally confusing. Those of us who have dealt with web accessibility for any length of time have a tendency to forget that, and to use these acronyms without thinking. So here’s a starter pack of web accessibility acronyms expanded and explained.

WCAG1 or WCAG 1.0 (”wih-cag one”) = Web Content Accessibility Guidelines version 1. These are the current guidelines on accessible web design. They were first published in 1999, which is a long time ago in web terms, which is why a second version is nearing completion.

WCAG2 or WCAG 2.0 (”wih-cag two”) = Web Content Accessibility Guidelines version 2. These new guidelines are in final draft stage. When they are finalised they will take over from version 1 as the current guidelines on best practice in accessible web design.

W3C = World Wide Web Consortium. The W3C is the international consortium which oversees and is responsible for many of the technical standards and best practice guidelines that apply to the internet and to the Web. A quick wander round the front page of the W3C website will give you an idea of the wide range of technical and policy issues for which they are responsible.

WAI (”way”) = Web Accessibility Initiative. The WAI is one part of the W3C. Its remit is specifically to tackle issues relating to accessibility on the Web. The WAI has overall responsibility for WCAG1 and WCAG2.

WCAG-WG (”wih-cag working group”) = Web Content Accessibility Guidelines Working Group. There are many W3C and WAI working groups and interest groups. One of the WAI working groups is the WCAG-WG. This is the group which has specific responsibility for developing and writing the Web Content Accessibility Guidelines. This group is currently chaired by Gregg Vanderheiden of the TRACE R&D Centre at the University of Wisconsin and Loretta Guarino Reid of Adobe. You can view a list of WCAG-WG participants “in good standing”.

EOWG = Education and Outreach Working Group. This is another of the WAI working groups. This group deals with the issues of publicising and explaining web accessibility generally and the various WAI guidelines in particular. A key responsibility of this group is developing and maintaining a range of supplementary materials to help those in other organisations who raise awareness of web accessibility issues and who train people in accessible design techniques or in assessing websites for accessibility. You can view a list of EOWG participants “in good standing”.

Are there any other web accessibility acronyms you’ve come across that you’re not sure about? Either email us or leave a comment here, and we’ll post an explanation (and if we don’t know what it means either, we’ll post the question as there’s bound to be someone else out there who does know!).

Oh… and around here, WAC can mean either “Web Access Centre”, our website, or “Web Access Consultancy”, our team.

If ever there were a good candidate for a “too much accessibility” award, the FIELDSET LEGEND element would surely take some beating.

Yes yes, I know, if you don’t have a LEGEND on your FIELDSET, some automated accessibility checkers will throw it up as an error. Well, my answer to that is, they don’t have to listen to them!

By this, I don’t mean that LEGEND should never be used, but like everything else in the accessibility toolbox, it’s not what you use, but how you use it. Continue Reading »

There have been warnings galore over the past couple of years (including some from Microsoft themselves) of how badly websites are likely to cope when viewed in IE7. This being because it’s more standards compliant than previous versions, and also because Microsoft have said they have not designed IE7 to be particularly backwards compatible with quirks and non-standards compliant features of earlier version of Internet Explorer.

So I was interested to see a link to an informal check carried out by Etre (the company that does the eye-tracking stuff I mentioned seeing in one of the presentations at that Online Public Services conference I chaired a few weeks back). They checked the home pages of the websites of the FTSE-100 companies in IE6 and IE7, to see how many fell apart in IE7.

IE7: Were they ready?

And did they find the web in meltdown? Well, no, not really. 87 of the 100 sites displayed and functioned identically in the two versions of IE, and in the 13 others, the differences were pretty small.

Now they say themselves that this was far from a truly scientific survey, and they looked just at the front page of each site. It’s quite possible that horrors lurk below the surface of some of these sites, but given the lack of standards compliance that one tends to find on these corporate sites, it may be that the release of IE7 won’t cause quite such a mess on the web as some feared.

Mind you - if you do find any sites which work in IE6 but fall apart in a serious way in IE7, do post the details here so we can all take a look. :)

A prime suspect in the crime of allowing “too much accessibility” has to be the TABINDEX attribute.

How many web authors realise that if you give the TABINDEX attribute to just a few form fields or links on a web page, you could ruin the logical tab order for the entire page? I’m afraid the answer is: far too few.

To be frank, I’ve rarely seen the TABINDEX attribute applied without it creating more problems than it solves.

Continue Reading »