techblog 

Acronyms (and abbreviations for that matter) within a website, according to the Accessibility Guidelines, have to be explained at least once (usually at the first occurrence, and usually via a title, long description, alt or other tool-tip). This is good practice and very helpful. Ironic then, that the three organisation’s websites that contribute to Euroaccessibility.org don’t actually do this. Take Ability Net, whose homepage statement reads

‘AbilityNet helps disabled adults and children use computers and the internet by adapting and adjusting their ICT.’

Well of course they do. But what is an ICT? It’s not explained on their homepage.

It’s not under ‘About us’ either. Search the site and you get a news link to “AbilityNet joins ICT Consortium to support the voluntary and community sector”. So will the article tell you what an ICT is? No, it won’t. But it does mention (and link to) the ‘ICT Consortium’ site. Surely that will tell you? Going to the ICT Organisation site states, heplfully, ‘ICT Hub: Delivering ICT Resources for the Voluntary and Community Sector’. Followed by the homepage text which reads ‘Welcome! It’s been a busy time at the ICT Hub. Staff have been in post since January and amongst other things are organising a series of seminars and conferences around the country.’. No luck so far. But they do have an About page - at last the place where ICT is defined? On the ICT’s own site ‘About Us’ page?

But you’d be wrong. In fact nowhere in the ICT site is ‘ICT’ actually defined. Even though it’s mentioned in practically every sentence, link or heading.

Unfortunately the same goes for the RNIB and RNID sites. Whilst I’m aware of what they stand for, others might not. In fact, RNID’s acronym does not stand for their full name. At least on these sites, if you dig deep enough (RNID>Home>About Us>History, mid way down) you can find it.

Maybe AbilityNet, RNIB and RNID are all relying on Google to explain themselves?

Euroaccessibility.org is a consortium of european organisations that has been around for a good few years now. The members are most of europe, with the UK’s individual contributors being Ability Net (www.abilitynet.org.uk), RNIB (www.rnib.org.uk), and RNID (www.rnid.org.uk. Their objectives are (taken from their website):

• Avoid the risks of fragmentation of the WAI outcomes
• Develop testing methodology based on the W3C/WAI Web Content Accessibility Guidelines
• Set up a common certification methodology of Web sites
• Create an Accessibility Quality Mark based on common rules
• Establish a certification authority for Web Accessibility
• Set up a European network of regional consulting desks
• Develop an harmonised set of supporting services over Europe
• Disseminate best practices in accessibility evaluation
• Significantly increase the number of accessible Web sites

The important one I believe is ‘Set up a common certification methodology of Web sites‘.
This is obviously going to set (at last) a common framework for developers of online content to work to. But should that be ‘european developers of online content’? Is europe going to lead the way? Doesn’t North America have some strong views on developing for accessibility? Will non-european developers just do their own thing?

The consortium is working with W3C, so hopefully this is just a case of someone taking a lead in the absence of any standard.

We have had occasional problems handling credit card payments via our payment service provider, DataCash whereby customers have received an error message and sometimes ended up paying twice due to retrying. We eventually tracked this down to a network timeout. What happens is that DataCash receives the data about the transaction from us, processes the payment, but is then too slow to send a response. So our client code times out. This means that payment has been taken from the customer’s credit card, but we don’t know as we haven’t received confirmation from DataCash. In order to avoid problems in the future, I changed the code to explicitly trap these timeouts so that we can get the customers to contact us before trying to pay again.

The difficulty then was how to test this. Datacash have facilities for testing all the expected responses such as “Success”, “Declined by Bank” etc, but there is no way to test for a timeout waiting for a response. The solution is to change the URL you are communicating with to one that will be blocked by a firewall. It swallows anything you throw at it and never returns anything, causing the timeout. In this case I am pointing my test code at http://testserver.datacash.com:43817, but you don’t even have to point at datacash if you don’t want to.

As part of our goals to make our web content as accessible as possible, we looked at (amongst other functions) the use of access keys. There are actually many differing views on the use of this capability, with divisions appearing to take on a geographic dimension. To summarise, there now appears to be a distinct North American versus European standpoint on the subject, centering on the availability or choice of available keys.

What are access keys?

Access keys are author or user-defined keys that are assigned to textual hyperlinks or specific HTML
elements (such as <input>) within a webpage. In short, a hyperlink or HTML element may have a letter or number associated with it, which when used (usually in combination with keys such as Alt or equivalent) targets that link, thus removing the need to use a mouse to navigate or (for example) select a particular field.

The access key attribute, introduced in HTML 4.0, can be written as <a xhref=”somewhere.htm” accesskey=”L”>Link Text</a>

Are access keys standardised?

Access keys are advocated by W3C’s WAI (Web Accessibility Initiative). A broad example of websites that use, or at least encourage their use, include (in no particular order):

• Most but not all UK government sites (e.g. cabinetoffice.gov.uk)
• scottish.parliament.uk
• Other international government sites.
• bbc.co.uk
• sitepoint.com (developer/accessibility resource site)
• alistapart.com (well known CSS discussion site)

However, there are many differing views on accessibility, mostly aired on various forums or CSS discussion sites. A sample of sites that do not advocate use of access keys appears below:

• nomensa.com (http://www.nomensa.com/resources/articles/accessibility-articles/access-keys.html)
• accessifyforum.com (for and against, see website)
• wats.ca, Web accessibility consulting firm (http://www.wats.ca/show.php?contentid=32)

The benefit of using access keys in my view is that it makes it easy for some people to use and navigate websites if they are unable to use a mouse, solely need to use a keyboard for whatever reason, or are for example using a screen reader. Bearing this in mind, and although they are part of the Web Accessibility Initiative defined by the W3C, it seems it is no guarantee of takeup by the developer community.

What are the issues surrounding use of access keys?

The current situation regarding take up and use of an approved system is actually fairly complex. Fo  starters, there is no approved system of which, or what, access keys to use. The list below identifies some basic issues:

1. Not every browser or version supports access keys. In addition, behaviour differs from browser to browser; IE in later versions requires use of the Enter key after using an Alt key. However, since access keys are primarily aimed at users who would in all likelihood use a screen reader, non-compatibility of some browsers (Netscape Navigator, IE4) in this respect is not a major issue.
2. Some screen readers already make use of access key combinations; these will be overridden by those defined in a web page, negating the user’s preferential Alt keys (such as ‘D’ for accessing the address bar in a browser). The worst keys to use according to some are D, E, F, and H, as these are commonly used for other functions. See http://www.wats.ca/show.php?contentid=43 for more information.There is no standard set of key definitions, and therefore every web site has their own configuration. A more standard method would be to employ numbers instead of letters (this method is used by government and the BBC) to define commonly used functions – skip to main content, search, site map and home, for example.
3. Making users aware that access keys are available requires a visual clue for the links themselves (usually underlining or emboldening), as well as, or instead of, a page of content providing information on their use. This is not a serious problem, but can impinge on content layout or presentation).

As a region, North America uses two main screen readers (namely JAWS and IBM’s HomePageReader) that come with their own access keys already defined. These two applications hav  a fairly international user base however, and so most screen reader users in other parts of the world are also likely to be using this software.

Accessibility advocates based in North America have taken a position of championing these two applications and the access keys they use, and support a move to deprecate or simply not use the W3C defined XHTML accesskey attribute as it can override the access keys defined by these top two screen readers. This alternative position also advocates replacing the XHTML attribute instead with similar elements (see http://www.wats.ca/show.php?contentid=47)

Some accessibility groups have additionally persuaded the Canadian government to drop their implementation of access keys on their websites. The approach the Canadian government took originally was the same as the UK government; namely using a series of numerals (1-6) to provide specific functionality for common tasks. With British and possibly European developers now looking to the UK government’s implementation (rightly or wrongly) as a standard (the BBC implements this approach as well), there is now a real conflict of perceived ’standards’.

W3C have also written a new attribute (“@key”) into the draft XHTML 2.0 specification, again much to the annoyance of the North American accessibility groups who see it as the same as the previous “accesskey” attribute mentioned above albeit under a different guise. Developers of the Firefox browser have also written a plug-in for the JAWS screen-reader (which previously was not compatible with Firefox) that pre-defines the access key numerals 1-6, which would also conflict with a ’standardised’ UK implementation of using numerals for common functions.

Based on the above divisions in the developer and user community, there is a a marked division on how to proceed with any standard regarding access keys. In fact it seems that there is no broad agreement as to what that standard might be; hopefully one will emerge sooner rather than later.

We have used the open source dnsjava library for several applications. For most purposes, the library works well. However, each query is run its own thread, on its own port. This means that for applications with high query volumes, an unacceptable number of threads and ports may be in use.

To solve this problem, we have implemented an extension to dnsjava-2.0.0. The extension adds a new Resolver implementation, NonblockingResolver, with the following features :

• Java nio library used
• Queries run in one thread, on one port (where possible). If two concurrent queries have been set by the application to have the same header ID, then they will be run on separate ports.
• Original dnsjava Resolver::send and Resolver::sendAsync methods supported
• A new callback interface (INonblockingResolver and ResponseQueue) is provided to allow one application thread to handle completion of all queries.

Here is some example code that uses the ResponseQueue [It is pretty contrived - a simple example like this would do just as well to use the standard Resolver callback] :

import org.xbill.DNS.*
import uk.nominet.dnsjnio.*
NonblockingResolver resolver = new NonblockingResolver("localhost");
Message query = getQuery("example.net");
Integer id = new Integer(idCount++); // Not the header ID, but can be!
ResponseQueue queue = new ResponseQueue();
resolver.sendAsync(query, id, queue);
Response result = queue.remove(); // This call blocks until the queue is not empty
assertTrue(result.getId() == id && !result.isException());

The blocking remove call would normally be done in the event loop, and any query completion will complete the call.

This code has been tested on Windows XP and Solaris. The Java nio library contains a native binary for the platform it runs on; although all platforms should run fine, there are not yet any guarantees. I’d be interested to hear if anybody has any success/problems with any other platforms.

The code can be downloaded from here

Note that dnsjava must be on your classpath