And here’s part 2 of the follow-up by etre.com on the problems faced by sites with the introduction of IE7. In this article, they look at some of the specific problems they identified, and at the effect, in IE7, of some of the workarounds and hacks which worked in IE6.
Following on from their informal survey of how websites fared in IE6 and IE7, the guys at etre.com have written a couple of follow-up articles. Here’s part 1, looking at the background, and at whether it’s the standards-compliant or tag soup websites that seem to fare best in IE7.
The BBC’s Access 2.0 blog looks at what’s going on in the world of the web today and tomorrow from the perspective of inclusivity. The man behind it is Paul Crichton, Director of net-progress, who also writes for Ability Magazine (a campaigning publication for people who have difficulty using information technology).
Recent topics up for discussion have included the accessibility of the BBC’s jobs website, Google and accessibility and the demise of Home Page Reader.
This looks like a great blog to complement BBC’s and Abilitynet’s joint My Web My Way, a site packed with information for users so they can better access web pages.
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 »
RNIB’s Stephen King presents Julie with a card from all of her colleagues at RNIB, wishing her the very best for the future.
