Latest Accessibility News on Accessify

Web Accessibility Workshops

• Canberra - 14 & 15 February 2006
• Melbourne - 1 & 2 February 2006

These one-day workshops run by Vision Australia, are targeted at web-development team leaders, corporate communications professionals and business managers, along with content authors, web programmers and designers and web contract managers.

They provide a thorough overview of accessibility issues and how to address them. It covers the World Wide Web Consortium’s Content Accessibility Guidelines and their implementation and a consideration of assessment tools and techniques. A basic knowledge of HTML is assumed for the standard workshops but not for the less technical ones.

Further information: Vision Australia: Designing for an Accessible Web - Workshops

Registration details:

• Canberra
• Melbourne

Just to let you know that the next MDAWG will be on the 11th January at 6pm at the Manchester Digital Development Agency premises.

The presentation will be from Lawrence Shaw of Sitemorse who have created quite a stir in the accessibility and website testing fields. I know for a fact that some of our luminaries are up for a healthy debate on the nature of automated testing vs human testing so it should be a good session. personally I think it’s a superb way of getting the grey matter moving early in the new year.

For more details see the related MDAWG blog entry.

The @media conference returns in 2006 after an incredibly successful conference in 2005.

This time there are more presentations and panels, spread across two tracks, and more speakers, including Eric Meyer, Dan Cederholm, Dave Shea, Andy Clarke, Jon Hicks, Molly Holzschlag, Tantek �elik, Jeremy Keith, Andy Budd, Roger Johansson, Veerle Pieters, Cameron Moll, Stuart Langridge, Simon Willison, Ian Lloyd, PPK, Patrick Griffiths, Gez Lemon, Patrick Lauke and Robin Christopherson. That’ll do for now, won’t it? More to be announced soon…

To be held at the prestigious QEII conference centre in middle of Westminster, London, this time around @media promises to be an even more lavish affair.

@media, Europe’s foremost professional web design conference, brings together some of the world’s most highly respected web experts to talk about the latest major happenings, best-practice thinking, and cutting-edge techniques in the world of web design.

The presentations and panels will tackle a multitude of aspects of web design, covering topics such as user-interface design, web standards, CSS, DOM scripting, and accessibility.

The multi-track, two day conference schedule is further built upon to provide plenty of valuable networking time and evening activities.

For details see the (very nicely presented) @media 2006 event site.

As has already been noted on previous occasions, automated accessibility testing tools can be useful … but only if their results are not merely taken at face value, but backed up by human testing and plain common sense.

All too often these tools simply follow accessibility guidelines by the letter, adding their own arbitrary (and often secret) heuristics to test what can’t be tested programmatically, and give a report containing false positives or false negatives (see for instance Isofarro’s excellent article on SiteMorse).

In this light, I find the accessibility check carried out as part of SilkTide’s sitescore quite amusing.

Testing one of my sites, the tool came across a single invalidly encoded character (an em dash from a copy/paste straight out of a Word document). Yes, this makes the page’s markup invalid, which in turn makes it fail WCAG 1.0 checkpoint 3.2 "Create documents that validate to published formal grammars".

Now, an automated tool would indeed be correct to flag this up as an issue (and fail the page for level AA and AAA), but SilkTide’s choice of words leaves a lot to be desired (and, to the cynic in me, sounds a lot like fear mongering intended to sell their consultancy services).

Under the ominous "British legal requirements" heading, the sitescore report states that the site:

… is probably unlawful in Britain from the 1st October 2004. The British Disability Discrimination Act makes it unlawful to discriminate against a disabled person by refusing to provide any service provided to members of the public - including websites.

This is wrong on at least three levels:

1. although the markup is invalid, in this instance the error is relatively minor; I would be very surprised if this single badly encoded character constituted a real access barrier to anybody;
2. the DDA does not specify any particular level of compliance, or indeed any set of guidelines at all; neither the DDA itself nor the related Code of Practice - Rights of Access - Goods, Facilities, Services and Premises mention WCAG or which level to aim for (although yes, WCAG will most certainly be taken into consideration once a case is brought to court, though it’s doubtful that an automated check against WCAG 1.0 will be the deciding factor in deciding on a site’s real accessibility);
3. the text perpetuates the false belief that October 2004 was the "cut-off" date for inaccessible web sites; the final part of the DDA, which indeed came into force in October 2004, only relates to physical adjustments to service providers’ premises - section III of the DDA, which relates to accessible web sites (as per the CoP), already came into force on 1 October 1999.

But, overall, it’s nice to know that an automated tool can now also give us such valuable legal advice…who needs lawyers anymore?

It’s an online advent calender, and behind each door you’ll find a web development tip/tutorial to impress your friends - 24 of them, to be precise. I’d prefer that to a piece of chocolate any day. 24 ways to impress your friends kicks off with some easy ajax prototyping.

I’ve just heard from Andy that the Clear:left chaps are holding a 1-day training session in London for Ajax. Now, I know that they know their stuff, but I was compelled to ask "will it cover accessibility?". After all, a poorly thought out Ajax application is a potential recipe for disaster where web accessibility is concerned. Here’s what Jeremy had to say in response:

Pretty much the entire thing will be based on "Think before you do
anything!" with multiple warnings about the dangers of excluding
people/devices that don’t support JavaScript/Ajax … It seems that most of the Ajax tutorials/workshops out there are
based around using frameworks to accomplish cool techniques. This one
will be different. It’ll be about writing code for yourself and
constantly asking if it degrades gracefully.

I suspect that they’ll sell out on this one quite quickly, so don’t wait too long if this looks like a good opportunity for you - ‘cos you might just miss it.

David Sloan, Project Lead for the Digital Media Access Group at the University of Dundee, is looking for your input:

I’m conducting a short survey of awareness of alternatives to WCAG as part of some research we’re doing here in Dundee.

I’d be very grateful if you could take a moment to reply to me directly with your level of awareness of each of the 6 sets of guidelines listed below, each of which either partially or totally focuses on web accessibility issues.

Please reply to me at dsloan@computing.dundee.ac.uk, using the following scale to indicate your level of awareness for each set of guidelines:

Level of awareness:

1. I’ve never heard of them.
2. I’ve heard of them but never read them.
3. I’ve read them but never used them in my work.
4. I’ve used them occasionally to inform my work.
5. I use them regularly.

Guidelines:

1. Beyond ALT Text: Usability for Disabled Users (Nielsen Norman Group)
2. Web Usability for Senior Citizens: 46 Design Guidelines Based on Usability Studies with People Age 65 and Older (Nielsen Norman Group)
3. Research-based Web Design and Usability Guidelines (National Cancer Institute)
4. Making your web site senior-friendly - a checklist (National Institute on Ageing and National Library of Medicine)
5. Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers (Theofanos and Redish)
6. Research-derived web design guidelines for older people (Kurniawan and Zaphiris)

All data will be anonymised and the aim is absolutely not about measuring the competence and knowledge of the respondents!

Many thanks in advance for your help.

Nice to see an “official” response to CAPTCHAs (”completely automated public Turing test to tell computers and humans apart”):

The WAI Protocols and Formats Working Group has released Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web as a Working Group Note. Requests for visual verification of a bitmapped image pose problems for those who are blind, have low vision or have a learning disability such as dyslexia. The note examines ways for systems to test for human users while preserving access for users with disabilities.

The Web Content Accessibility Guidelines (WCAG) Working Group has released Working Drafts of the Web Content Accessibility Guidelines 2.0 and HTML Techniques for WCAG 2.0 and a First Public Working Draft of Understanding WCAG 2.0. Following WCAG makes Web content more accessible to the vast majority of users, including people with disabilities and older users, using many different devices including a wide variety of assistive technology.

The Authoring Tool Accessibility Guidelines Working Group has released a Working Draft of Authoring Tool Accessibility Guidelines 2.0 incorporating Last Call comments. The guidelines are written to help developers create accessible authoring interfaces that produce accessible Web content. Resulting content can be read by a broader range of readers including those with disabilities.

The respective working groups are inviting comments by 21 December 2005:

• Call for Review: Working Draft of Web Content Accessibility Guidelines 2.0
• Call for Review: Working Draft of Authoring Tool Accessibility Guidelines 2.0

When I first heard about the accesskey attribute in HTML I thought "Wow! What a great idea" and started to apply them willy-nilly to projects I was undertaking at work. Some time later, I started to read other articles that described problems with using accesskeys, problems that I would not discover by myself unless I were using a Screen Reader (something I’d do infrequently during testing cycles of sites at work) or some other assistive device. What’s the problem? Well, in a nutshell, the key that you as an author choose to activate a link/form element/whatever could very well conflict with keys that are already assigned elsewhere. I then came to the conclusion that this great idea is flawed (as did many others) and stopped using them altogether.

The next iteration of XHTML should sort out issues like that, surely? Apparantly not. In The XHTML Role Access Module still flawed, John Foliot summarises how a few years of badgering the various XHTML 2 draft authors appears not to have achieved the desired result:

I continue to maintain that, as currently presented, one of the fundamental flaws of ACCESSKEY will be carried through to this new Element and attribute so long as the @key attribute remains. While I come to this discussion primarily as an Accessibility Advocate, I believe the issues will in fact impact upon all users to some extent.

It’s a fairly long open letter but worth a read. Note -it’s not just John and Derek who can badger/bother/nudge the people responsible for the XHTML 2 draft, remember. If you feel strongly about it, you too can have your say.

Related

On the previous incarnation of Accessify, accesskeys were hard-coded and, almost certainly, clashed with assistive devices as mentioned in the article referenced above. Strangely, no-one ever wrote in to complain that this was the case. Regardless of this, I decided to try and tackle the problem head on with an interim solution - and that was to create a system that allows the user to opt-in and set their own accesskeys. I’d be interested in feedback on this idea and suggestions for improvement.