techblog 

I’ve been working on something in Wordpress with my colleague Ewan, and we ran into a very strange problem with Firefox yesterday. The theme which Ewan was designing for it looked fine to him in Firefox, but to myself and a colleague had a few issues visually. The header image wasn’t in the correct place, and a couple of elements disappeared that should have been there. The curious thing was that we were all running Firefox 2.0.0.6 and above.

After trying various things, we realised that Ewan’s version was upgraded from 1.5 to 2.0, whereas the rest of us were using clean installs of 2.0. Ewan cleaned Firefox off his machine, installed the latest version, upon which he could see things the same as us.

So what caused this? Were some elements of Firefox referring to an older version of Gecko (Mozilla’s rendering engine)? What did trouble us was the idea that other people may be designing websites for Firefox, and just not seeing what their users see.

I’m working on a project involving RSS feeds, and I am interested to know what people are using to read them. Looking at the statistics for Feedburner, it is clear that the majority of RSS Feeds are being read in My Yahoo, Google Reader or Bloglines, but I would like to find out what else is being used, particularly in terms of offline readers. So if you are a user of RSS feeds, please let me know in the comments what tools you are using.

Whilst working through the examples in the “Ajax on Rails” book I had all sorts of problems with Prototype and script.aculo.us. For a start, there is a simple example of a link that toggles a div between visible and invisible, like this:

<%= link_to_function "Toggle DIV", "$('indicator').toggle()" %>

But all I got with this was the error message “toggle is not a function. I even tried replacing toggle() with show() and got another error. Eventually I upgraded from Prototype 1.4 to 1.5 and the problem went away.

Now all through this, script.aculo.us had been working fine. But then I tried another simple example:

Effect.toggle('indicator', 'blind')

Again I got the error message that ‘toggle is not a function’. So this time I upgraded script.aculo.us to 1.7 and it all seems to work fine.

Having said that all I’ve done is upgrade within my current project so now I need to work out how to upgrade the prototype and script.aculo.us built into Rails so that all new projects start with the new versions.

Freemind is an opensource mindmapping tool (written in Java) that can usefully export to a variety of formats (main homepage seems to be freemind.sourceforge.net , link from wikipedia). I had an occasion to use it recently with a view to providing a mindmap on the Nominet website. A problem here though was Freemind’s required use of Java - and no real practical way to provide an accessible alternative (imagemaps anyone?) for anyone viewing the map.

A solution was to use Flash as a container (although that in itself raises accessibility questions). To create a mindmap entirely in Flash was also a possibility although that would be tricky and time consuming; so using Freemind was the only realistic alternative. Unfortunately, the latest release (0.8.0) does not support exporting to ‘.swf’. Exporting SVG (or even JPG) static maps is entirely possible, but this would not have contained any interactive links to other content, for example.

Luckily, the latest beta (0.9.0 beta .8) does indeed contain an option to export to ‘.swf’. The bad news is (as I found out) that the functionality of ‘rich text’ within nodes does not work within a Flash environment. This means that anything other than text within a node (or even styling of that node’s text, including any formatting) will not appear. Any attempt to include an image next to a node results in ‘undefined’ when displayed.

However, there is a tweaked version of the Flash browser, developed by Juan Pedro at Efectokiwano.net. This has some sketchy support for rich-text within the Flash container, which at least means images can be placed. However, there are definitely some areas that could be improved, such as:

• Complete rich text support for all image formats
• Ability to place images before or after a node’s text.
• Hyperlinks: this needs to be customisable, either by underlining the text or by linking an image, not just the tiny red arrow.
• Nodes that have children: currently shown by a small rounded circle - this needs to be far clearer.
• Icons - again should be able to be placed left or right of a node’s content.
• Local links (local to the .mm’s file location) currently do not work unless the map is on a server.

A fairly useful userguide can be found at: fb.stikipad.com.

Thanks to Mark Baker who showed me this little trick.

Whenever you display and email address in a web page there is a good chance a spambot will harvest that address and add it to a database. This technique allows you to publish email addresses in a way that browsers and email programs correctly understand but very few spambots do.

The way it works is to write out the email address using HTML character data - i.e. each letter is written like &#number; . So the email address jay@nominet.org.uk gets written in HTML as follows (line breaks added for clarity)

<a href=”mailto:&#106;&#097;&#121;&#064;&#110;
&#111;&#109;&#105;&#110;&#101;&#116;
&#046;&#111;&#114;&#103;&#046;&#117;
&#107;”>&#106;&#097;&#121;&#064;&#110;
&#111;&#109;&#105;&#110;&#101;&#116;
&#046;&#111;&#114;&#103;&#046;&#117;
&#107;</a>

which ends up looking like this:

jay@nominet.org.uk

Can you tell the difference?

Some of you may be thinking that this trick will be quickly discovered by spambot authors. However I think that spambots are generally only after the quick pickings and unless this trick becomes very popular it is not going to appear on their radar.

As you may have seen there have been no new posts for a week whilst we made the move to WordPress, away from Blojsom. Blojsom initially suited us very well, but as time has moved on it doesn’t have the functionality that WordPress has. In fact WordPress is a very impressive product.

Migration was pretty straightforward using the RSS import utility. There was one post that did not import and had to be re-entered by hand (the one about tail -f). More concerning was that there was no way to import comments without writing code, which we half did and half just cut and pasted.

With the move to WordPress we have made some improvements, namely:

• The categories have been tidied up
• One post can now be in multiple categories
• We’ve added links to our personal blogs (for those that have them).

The design is only partly complete, we will be revising it over time.

Unfortunately we did not keep the same permalink structure so old links will need to be changed. But the posts are all still there.

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.

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.

One limitation I found when using Web Ontology Language (OWL) was that it does not support customised datatypes. I realise that the
main purpose of OWL is to recording how data relates to real world objects, but allowing authors to reference XML Schema to define OWL-related
datatypes, while keeping an OWL document in valid DL form would be most useful.

Some work has been undertaken in addressing this (see Working Group Note “XML Schema Datatypes
in RDF and OWL” - specifically using the id attribute), adding an ID to the XML Schema. then referencing it in the OWL Document:

<owl:DatatypeProperty rdf:ID="domainNameValue">
<rdfs:domain rdf:resource="#domainName"/>
<rdfs:range rdf:resource=
"http://xml.nominet.org.uk/schema/datatypes#domainName"/>
</owl:DatatypeProperty>

..but using customised datatypes through this method turns documents into OWL Full, which is not ideal. Due to its syntactic freedom,
it is unlikely that future reasoning software will be able to support complete reasoning for OWL Full.

Interestingly enough. further to the W3C reccomendation, a possible extension
OWL-Eu has been suggested to overcome this, but as far as I know this datatype issue hasn’t yet been resolved within the W3C reccomendation,
and until this point reasoning tools will not likely support this.

Real world Semantic Web tools will only support OWL DL due to the limitations/complexities of OWL Lite/Full,
so unless users can create OWL DL documents using customised datatypes, the takeup of OWL will probably be slow.