Comments on: Question: Headscape tabs

By: Ralph Brandi

Ralph Brandi — Fri, 30 May 2008 08:25:17 +0000

Paul,
Rather than setting up a separate accessibility page as Andrew suggests, perhaps a better approach would be to just place the option of whether to use Ajax or not at the head of the page. This is the approach I took on a site for the North American Shortwave Association. One section of the site contains a database of shortwave radio stations that the club’s members have heard over the years. I used the opportunity of creating the site a couple of years ago to teach myself Ajax, but part of the audience for the site is blind, so I had to make sure it was accessible. My solution was to put a couple of radio buttons at the top of the page asking users if they wanted to open the details within the page or in a new page. Then the event handler for each item checks to see if the choice to open within the page is checked. If it is, the Ajax query is used; if it’s not, the PHP-based query is used. I also set a cookie when the radio buttons are checked so that the chosen option is retained. You could throw this option off the edge of the page; I chose to leave it visible for everyone. I also use the selection of option to define whether sorting of the table is done in page or with a page refresh (but don’t mention that in the radio buttons; the label would get too long if I did).
You can see this in action on the NASWA site at http://www.naswa.net/logs/. Search for a country like “United Kingdom” and you’ll get a number of results, along with the radio buttons I mentioned. I would probably write the Javascript there a little differently if I were creating the site today, but you’ll get the idea.

By: Gilbert

Gilbert — Fri, 23 May 2008 08:08:00 +0000

I was wondering what sort of effect the single page site approach was having on your stats? Specifically pgae views in the traditional sense.
The AJAX approach of loading the case study fragment from another page would mean that in things like Google Analytics, looking at a case study wouldn’t register as a page view.
I guess if you’re using stats from log files, looking at a case study would register as a page view.
Then I guess you could also just look at where people were actually clicking on the page.
There you go I’ve answered my own question I think.

By: Damien Lebrun

Damien Lebrun — Thu, 22 May 2008 15:48:21 +0000

@Simon: the Ajax solution scales better.
Each case study has its own page, and the home page will display only 6 of them. The Ajax solution avoid duplicate content without page reload.
@Paul: a solution that might work would be to use a fragment identifier:
- Here’s a typical case study link href: “/clients/xyz.htm”;
- with js on, it becomes “#studycase:xyz”;
- when the link is clicked “/clients/xyz.htm” is loaded and inserted in an element with the id “studycase:xyz” and the even should not be cancelled so that the browser focus on the “studycase:xyz” element.
If the focus can happen after the new content is inserted (is it possible?), the feedback won’t only be visual and it should be working with a screen reader as well.
Also using something like the history plug-in (http://plugins.jquery.com/project/history) it won’t break the back button and will allow bookmarking the case study.

By: Simon Griffiths

Simon Griffiths — Tue, 20 May 2008 14:11:31 +0000

I’m not sure why you didn’t use CSS to do this in the first place but I am guessig it is because of browser compatibility. Have you had a look at the menu system developed by Steve Gibson that does the SecurityNow podcast? He has opensourced the code at http://www.grc.com/menu2/invitro.htm.
The interesting thing about this is that it is pure CSS, and is compatible with all browsers pretty much (look at the code and you will see he has spent a lot of time on this). In theory you could use this to do pretty much the same thing, with no scripting at all, and therefore maximum accessibility.

By: Rory Fitzpatrick

Rory Fitzpatrick — Sun, 18 May 2008 13:10:28 +0000

Thanks for the post Paul, some responsible scripting techniques on the go there!
I had thought that screen readers wouldn’t pay attention to hidden content, but on closer inspection you’ve used some nifty negative positioning which I assume will work?
For an accessible approach to Ajax, check out the W3C ARIA spec (http://www.w3.org/WAI/intro/aria), it allows you to mark an area of a page that might be updated via Ajax and alert the browser to when this happens. Its not got very wide implementation yet, only FF3 and Webkit as far as I know, but its a promising solution.
Cheers
Rory

By: Paul Boag

Paul Boag — Fri, 16 May 2008 15:59:33 +0000

@Andrew... love the cookie approach. I'll have to think about it some more but at first glance it sounds like a winner.

By: Cole Henley

Cole Henley — Fri, 16 May 2008 11:49:29 +0000

@warren
Nice thought but web stats won’t pick up screen reader use. Screen readers do not themselves view web sites (the exception perhaps being the use of text-based browsers such as Lynx) but rather sit over the users web browser of choice.
Therefore, the header requests that generate your server stats (or alternatively the javascript requests that generate client-sided web traffic statistics) will only show the web browser being used and not the tool that is being used to interpret what the browser returns,
Cole

By: Warren Buckley

Warren Buckley — Fri, 16 May 2008 11:32:22 +0000

Hi Paul,
I have learnt something new about the jQuery library which is the “.load” event. I like the idea of how you loaded in external content from another page of your site.
I like that this will degrade gracefully if JavaScript is disabled. In my personal opinion I think you should only do optimisation for screenreaders if your stats show you that people are browsing to your site using a screen reader.
Additionally I don’t think many screenreader users will be reading a site about managing websites in my opinion, your audience will be people who will most likely be running the latest browser versions and operating systems, due to the background of the subject.
Anyway my 2 cents worth, as always keep up the good work.
Thanks,
Warren

By: Cole Henley

Cole Henley — Fri, 16 May 2008 11:26:25 +0000

Interesting post Paul.
The simplicity and power of jQuery is making me much more experimental in my use of ajax. One question/thought – if your message for screenreaders relates to the use of javascript on the site then why not use javascript to add it so that with javascript disabled screen reader users won’t get a message that doesn’t relate to them?
Have seen this a lot where message relating to behaviour are hard-coded into the HTML (as a handle to be manioulated by javascript) when every other aspect of a site’s behaviour has been carefully separated/progressively enhanced/gracefully degraded (insert catchphrase of choice).
Just a thought,
Cole

By: Andrew Green

Andrew Green — Fri, 16 May 2008 09:58:46 +0000

An approach that we’re planning on using for Buy Our Honeymoon (but haven’t yet done so) is to have a switch on an Accessibility Options page that will set a “no-ajax” cookie.
Assuming then that the main pages aren’t static HTML, the site will check for the presence of this cookie and, if it’s there, omit the Javascript for the Ajax functions from the delivered page. That way you can retain some useful progressive enhancement with Javascript, whilst allowing users to disable the Ajax stuff if they want to.
Of course, the link to the Accessibility Options page needs to be non-Ajax itself in the first place!
Cheers,
Andrew.