JavaScript and Accessibility

Comment by Roger Johansson — Jun 12 2005 @ 2:17 pm

Like I said when we talked a bit about this at that pizza place that we finally found, I’m completely with you on this. The question is how to get there.

What about getting screen reader manufacturers to cooperate? perhaps they could provide an easy way to toggle JavaScript on and off? Not an easy thing I suppose to cooperate with the leading manufacturer after hearing what some people have to say about them… maybe Apple is more willing to listen.

About orientation guides, that is something I started thinking about not too long ago, and will start implementing on some sites.

Comment by Jesse — Jun 12 2005 @ 3:05 pm

oooo… I wish I would have been able to go to @media.

JAWS and others seem to be well intentioned but what I have noticed with the few blind and low vision students we have here is that they turn off as many features as possible and navigate with Google. Why? JAWS gives them too much information and it is distracting – they have the voice going so fast no one but them can understand it. This is just a really small sample though… and they are very web savvy students.

Oh, and I like that accessibility toolbar but where is the OS X version ;)

Comment by bruce — Jun 13 2005 @ 2:46 am

HI Derek
It’s interesting to read that some blind users turn off JavaScript for its verbosity. In the next in my series of comparing screenreader’s reading of standards-based markup against old-skool markup, I’m looking at how Jaws reads old-style JavaScript rollovers versus css :hover rollovers.

I’ve already got the mp3s of Jaws’ dulcet tones (and will post them next week after my holiday), but I can certainly concur that there’s way too much redundant information with the JavaScript (Dreamweaver-generated) rollover approach,

Comment by Michael Ward — Jun 13 2005 @ 4:32 am

The Web Standards Project should be on this one, IMHO.

Like they did with the browser manufacturers, design tool creators, etc. they need to evangelise web standards to the accessibility groups.

The makers of JAWS, etc. are still living in a by-gone era – and they are letting their customers down when their tools cannot utilise the accessibility features (as laid down by web standards AND common sense) that considerate designers and coders are building into their web sites.

It’s time for accessibility tool providers to step up to the plate and bring themselves into the new century. Things HAVE changed, and they will continue to change.

Comment by ppk — Jun 13 2005 @ 6:24 am

Basicually we have to re-think JavaScript and accessibility from the ground up, and we need more data on screen readers before we can start doing that.

Derek, great to meet you and great that you had the courage to say something that doesn’t fit into current JS/accessibility theories. We need that.

Comment by Mike Stenhouse — Jun 13 2005 @ 6:59 am

I seem to remember reading somewhere that JAWS had at least some support for DOM’s adding of nodes. Wish I could find that link. I’ve not gone back to try it myself yet but it might be a good question for Access Matters…

Comment by Small Paul — Jun 14 2005 @ 10:48 am

It is a tricky one. The current WAI model of JavaScript accessibility is, roughly, “Make it work without JavaScript, as well as with JavaScript”.

From a development point of view, that means you have to think up two different systems in tandem. Emminently do-able, but it’s unavoidably more work.

When you’ve got n user agents that support a bit of JavaScript, but don’t support another bit, that multiplies the difficulty by a factor of n.

And when user-agents support a bit of JavaScript, but in incorrect or unexpected ways, we’re basically screwed.

Comment by Dave S. — Jun 15 2005 @ 4:36 pm

Man am I ever glad someone’s thinking about this. Thanks Derek, looking forward to seeing what comes of your testing.

Comment by brothercake — Jun 16 2005 @ 11:47 am

I can add this much from existing experience of scripting with screenreaders in mind (I’ll separate what I know as fact from what is mere supposition):

Fact: neither JAWS nor HPR fire the “onfocus” event of a link when tabbing to it; they do fire onfocus for form elements, but not links.

Supposition: this may be because they don’t actually focus links at all, what they do is more akin to text-range selection (and may indeed be readable as such, but I haven’t got as far as trying that)

Fact: keyboard navigation with a screenreader doesn’t generate mouse events (obviously)

Supposition: it may not be possible to navigate using a screenreader and a mouse at all, and if so – screenreader=keyboard is a firm assumption

Conclusion: using that information we can construct a reader-aware event-handling model like this:

1 – a document mousedown handler sets a “mousedown” flag; a mouseup handler resets it

2 – a document focus handler sets a “hasfocus” flag; a blur handler resets it

Now – whenever a link receives an “onclick” event, we can assert by reference to these flags that:

a – the event is from a mouse-using graphical browser (because mousedown is true); or

b – the event is from a keyboard-using graphical browser (because hasfocus is true but mousedown isn’t); or

c – the event is from a a keyboard-using HPR or JAWS installation (because neither is true)

Does that make sense?

Comment by Jules — Jun 20 2005 @ 9:24 am

OT: I’d like to defend Dreamweaver along the same lines as defending a butter knife that has been used to repair a Nikon camera: don’t criticize the tool, criticize the dummy that misused it. By default, DW does not automatically insert JS when you are happily going along creating a page, you must go through the process of inserting behaviours.

However, I will not defend the quality of the JS behaviours provided with DW: some were written in 1997 complete with browser detection.

Comment by Dustin — Jun 21 2005 @ 7:05 pm

thus, unobtrusive javascript is born (or reborn).

Comment by Derek Featherstone — Jun 21 2005 @ 7:41 pm

thus, unobtrusive javascript is born (or reborn)

No, its still here, and never left. It may be born and/or reborn for other people, but for many of us, it has always been the “one true way.” ;-)

The bottom line for me is that even unobtrusive JavaScript may not work properly with screen readers (or is that screen readers may not work properly with unobtrusive JavaScript?) I’m specifically suggesting that instead of us testing like mad on every possible screen reader combination, with loads of different configurations, perhaps it is time to tell users of older screen readers that they should turn JS off so that they can deal with the pages better.

Comment by brothercake — Jun 22 2005 @ 7:41 am

perhaps it is time to tell users of older screen readers that they should turn JS off so that they can deal with the pages better.

An edge of many swords, this is :)

On the one hand – how is telling a group of users to turn off javascript any different from telling a different group of users to turn ON javascript? It’s still content inequality of a kind.

Having said that, it’s very true that users themselves must take some responsibility for the situation, and “come to the table” with a decent toolset, as it were

So I think our imperatives here are three-fold

1 – find out what kinds of scripting can be made (or already is) compatible with modern builds of screenreaders – JAWS 5, HPR 3 and so on

2 – find out how incompatible scripting can be rendered harmless – so that these same readers get equivalent static content, even though they have scripting enabled

3 – work out where to draw the line ;)

Ultimately, move towards a consistent and reliable set of technique and practises

And on a side tip – I’ve now worked out how to make Home Page Reader say something on demand – but it’s a dirty hack, loaded with unsafe assumptions, and doesn’t work in JAWS. I won’t bother posting details just for now ;)

But you know I can’t help but feel that really XHTML+Voice is the answer to all of this, but X+V is technology for a different purpose … it’s not in the niche to solve our problem, I don’t think, although it has exciting possibilities of its own.

Comment by Derek Featherstone — Jun 22 2005 @ 7:56 am

On the one hand – how is telling a group of users to turn off javascript any different from telling a different group of users to turn ON javascript? It's still content inequality of a kind.

That’s the point though – we don’t have to tell a group to turn JavaScript on, because we’ve built our sites such that they don’t require it. Further, if there are “problems” with the way that some older screen readers handle certain JS “things” (if you’ll permit be to be vague for now), then turning JS off may give them a better experience that meets their particular needs more effectively.

How do you see it as a “content” inequality? I see it more as a “behaviour” inequality, and that is reasonable to me, given that various users have different needs in terms of their experience when using a site or application.

Comment by ADAM . . . — Jun 23 2005 @ 6:44 am

I’m a bit late to the party, didn’t get to @media and am therefore doing a lot of catching up!

I’ve been working through Jeremy Keith’s slides from his presentation (http://adactio.com/atmedia2005/). The script for generating pop-up handlers works particularly well and also (to me) seems like a good example of unobtrusive scripting.

However when I ran a page using this script through JAWS the pop-up links worked exactly as expected, creating new browser windows. This seems to work counter to the expectation that javascript attached dynamically won’t get picked up by JAWS?

Has anyone else tested this or other unobtrusive scripts with similar results? . . .

Comment by Derek Featherstone — Jun 23 2005 @ 6:56 am

ADAM, thanks for your comment:

However when I ran a page using this script through JAWS the pop-up links worked exactly as expected, creating new browser windows. This seems to work counter to the expectation that javascript attached dynamically won't get picked up by JAWS?

In that particular case, it doesn’t have anything to with the fact that JAWS recognized the dynamically attached functionality. The case in which it didn’t (that I actually tested) was an onmouseover event handler. Part of the reason I tested that case is that JAWS has special behaviour for onmouseover/onmouseout events and exposes specific “extra” functionality.

In the case of Jeremy’s script, JAWS probably doesn’t to do much more than listen for new windows and then give them focus, so it likely doesn’t have much to do with JAWS actually working with the JavaScript itself.

In any case, keep your ears/eyes open for some updates/announcements of some activities related to these exact problems. Hopefully the info will be made public today…

Comment by brothercake — Jun 23 2005 @ 7:59 am

In that particular case, it doesn't have anything to
with the fact that JAWS recognized the dynamically
attached functionality.

Yes it does – it has everything to do with that – taking the best example of unobtrusive popup scripting, that example will work in JAWS exactly as it does in a vanilla install of IE, for exactly the same reason. Was that intended? Or wouldn’t it be better if screenreader users don’t have to deal with popups?

This the point I’m trying to get across point – where behavioral differences have the potential to create content inequality.

Here’s an example of behavioral inequality – a page where the content is either available through dynamic show hide mechanisms, or it’s all there by default. There’s no accessibility problem there – all users can access the same content, albeit in different ways – so behavioral inequality != content inequality. Good.

But what we have is browsers that partially support javascript – they support the language, but some of the events don’t happen. We also have the difference of modality that affects how an interface is perceived (all at once, or bit by bit), and we have the fact that interface elements behave differently with the keyboard than the mouse. So we already have several areas where our script might potentially fail.

Keyboard navigation we should be catering for anyway – so let’s assume that’s taken care of. The real problem is the difference of modality, and here’s a prime example:

A JS-based tab interface where you have a list of links, each of which is a #target link to blocks of content, styled to look like a row of tabs on top of a single content area. You click that link and the script hides the current layer, shows the layer you want, and returns false on the link. For noscript browsers, all the content is visible by default so those links still works as anchors to each content area.

But a reader is not a noscript browser; if we’ve used offleft positioning on the non-visible content areas then they’ll still all be there fine enough, but our screenreader doesn’t get to use them like that – JAWS does the same thing as IE, and the same thing happens – the layer visibility is toggled, and nothing else – they don’t jump to the target, because the link returns false.

So they’ve changed the content of the page, but with no notification – they don’t know it’s changed until they read it, and maybe not then – when accessing information serially, you don’t have that random access that the eyes have – you don’t see it change, so you won’t necessarily know that it has.

And there’s content inequality – right there – even though we’re using best-practise unobtrusive scripting, JAWS still can’t interact with our content in an equal way – JAWS users have a cognitively much harder job to make sense of the page.

Comment by ADAM . . . — Jun 23 2005 @ 8:25 am

I possibly failed to look before leaping here? And maybe my example was a wee bit specific.

What I was hoping for was a pop-up script which would be suitably hidden from screen reader users so that pop-ups wouldn’t be triggered. That seemed to be reasonable possibility based on statements above.

Back to the drawing board! . . .

Comment by brothercake — Jun 23 2005 @ 8:48 am

It is a reasonable possibility – we just haven’t worked out a safe way of doing it .. yet ;)

Comment by Derek Featherstone — Jun 23 2005 @ 12:13 pm

Yes it does – it has everything to do with that – taking the best example of unobtrusive popup scripting, that example will work in JAWS exactly as it does in a vanilla install of IE

I’m not sure I follow you, and I think we’re talking about different things here. I’m specifically saying in the quick testing I did, the special functionality of JAWS to deal with “onmouseover” content was not triggered when the onmouseover behaviour was attached dynamically rather than inline.

I know that JAWS will work properly with unobtrusive scripting, and that wasn’t the point I was trying to make. Popping up a window is popping up a window to JAWS, whether it is done with an inline event handler or a dynamically attached event handler. That is what I was trying to contrast with the onmouseover behaviour where the dynamically attached onmouseover wasn’t recognized at all. Moving on…

what we have is browsers that partially support javascript – they support the language, but some of the events don't happen

Can you provide further details – to which events are you referring? (I’m serious with this question… are you referring to JAWS for example as a browser in this statement? Just looking for clarification…

JAWS does the same thing as IE, and the same thing happens – the layer visibility is toggled, and nothing else – they don't jump to the target, because the link returns false

I need to test this more, but have tried, with success: simply don’t return false – use the default behaviour. Or, use the href that should be there to go and place the focus on that element and then return false to prevent a larger history of in page links from building up.

Comment by brothercake — Jun 23 2005 @ 1:44 pm

That is what I was trying to contrast with the onmouseover behaviour where the dynamically attached onmouseover wasn't recognized at all.

Oh I see, I hadn’t grasped that point. I hadn’t really considered JAWS’ onmouseover-triggering behavior as a serious contender anyway – maybe it’s me, but I haven’t been able to get that behavior to do anything at all – JAWS prompts for the event and then says “the page has not changed” when I can see that it has ..

Can you provide further details – to which events are you referring? (I'm serious with this question"¦ are you referring to JAWS for example as a browser in this statement? Just looking for clarification"¦

I am referring to JAWS as a browser yes, and I’m referring to things like the fact that focus events on links are not generated (as per my first reply). There may be more – I don’t know – and that’s part of what testing should establish.

I need to test this more, but have tried, with success: simply don't return false – use the default behaviour. Or, use the href that should be there to go and place the focus on that element and then return false to prevent a larger history of in page links from building up.

Sure – and the first thing the client says is “why does the page jump when I activate the first layer”?

But I’m not dismissing your suggestion, maybe there’s a way of managing that. Maybe having links building up in the history would be betteer for all. These are exactly the kinds of questions we should be asking, and testing to bear out our theories.

The point I really meant to make, in my own over-verbose way, is that it’s not as simple as whether a browser does or doesn’t support javascript – we have browsers (eg, JAWS and HPR) to consider that do support javascript but may still not be able to use a particular script, and yet we can’t sniff them out and do something different in any conventional way, like we could for a noscript browsers, or netscape 4

Comment by Derek Featherstone — Jun 23 2005 @ 2:34 pm

Oh I see, I hadn't grasped that point. I hadn't really considered JAWS' onmouseover-triggering behavior as a serious contender anyway – maybe it's me, but I haven't been able to get that behavior to do anything at all – JAWS prompts for the event and then says "the page has not changed" when I can see that it has

Is that a public page that I can see for myself? I’m curious, you see… Don’t take these questions the wrong way – you may know this already – but did you use the Ctrl+Enter keystroke to invoke the onmouseover behaviour? It should do that, then say the page has changed at line X. Then you hit “G” and enter that line, where focus is subsequently transferred, and JAWS reads from there… At least, that is my recollection of the testing.

I am referring to JAWS as a browser yes, and I'm referring to things like the fact that focus events on links are not generated (as per my first reply). There may be more – I don't know – and that's part of what testing should establish.

Agreed, 100%. And I missed that bit about focus events.

I'm not dismissing your suggestion, maybe there's a way of managing that. Maybe having links building up in the history would be betteer for all. These are exactly the kinds of questions we should be asking, and testing to bear out our theories.

I couldn’t agree more, and that’s exactly what I was suggesting. We are very much on the same page here…

it's not as simple as whether a browser does or doesn't support javascript

Exactly. That was my point up above when I said this:

Using these methodologies, we can deal with JavaScript on or off, but we can't deal with in between.

We are completely on the same page here… and, in my overly-verbose way, I think I can rest, knowing that we are on the same page. Unless of course you don’t think we are, in which case, we can continue to agree with each other using different words… :)

Comment by Nicolas Chachereau — Jun 26 2005 @ 5:00 am

My suggestion to turn JS off might be a bit impractical. How often do you turn JavaScript off when you are developing and then forget to turn it back on, only to find that other sites suddenly don't work and you wonder why?

In fact, there is a simple way to allow people to disable JavaScript, and that only on your site. This would be especially true on Web Applications.

You could simply set a cookie and check in your script, the same way you already test for the DOM.
If the cookie is present (or not, depending on how you make this work), you attach the event handlers or not. Then, using Server Side Scripting (which you use anyway in a web app), you could send your JavaScript file only to those user who actually request it through the cookie, thus saving bandwidth.

In a web application you would probably have user sessions, and you could set an option for each user whether or not he wants the JavaScript behaviour.

If accessibility is somewhat crucial for your app, you should probably send by default the application without any JavaScript. Then, in the options for each user, you could write something like :
“Activate JavaScript behaviour. This will ease the use of the application, allowing you to do some things without reloading the page.
Warning! This needs a proper JavaScript support.
Warning! If you use a screen reader, this will make the pages more difficult to navigate, thus you shouldn’t activate it.
[ Activate ]”

Of course, this is all really doable in a web application, where the script may be important enough to justify such efforts. In a “simple”, informative web site, like a blog or a wiki, this would be somewhat complicated. Maybe we should admit that for simple web sites we should be extremely careful with the use of any script…

Comment by brothercake — Jun 28 2005 @ 9:25 am

Is that a public page that I can see for myself? I'm curious, you see"¦ Don't take these questions the wrong way – you may know this already – but did you use the Ctrl+Enter keystroke to invoke the onmouseover behaviour? It should do that, then say the page has changed at line X. Then you hit "G" and enter that line, where focus is subsequently transferred, and JAWS reads from there"¦ At least, that is my recollection of the testing.

This is the page I’m testing: http://www.udm4.com/demos/popup-relative.php

if you tab to the “About UDM” link in the chunk of demo text at the top, the mouseover of that opens a popup menu. Testing in JAWS 5.0 on Win 2K, when I activate that it says “page did not change”, though you can see that something has changed – a menu has appeared.

Using another version of the menu script (a more recent version, unfortunately I can’t show you because it’s not yet public) it responds differently – it says that something has changed, but the line number it refers to is the line of JS that’s just been executed. I have no idea what’s changed in the script that would explain that difference … but I’ll investigate.

But either way, I don’t blame JAWS for an inability – I don’t see how it could possibly get that right as it is. What actually happens is that a nested UL – at the very end of the source code but positioned off the screen – is positioned back on the screen; you can see it change, but all that actually has changed is some CSS.

So I wonder – what is this mouseover triggering intended for? What kinds of scripting did the developers have in mind when designing it?

We are completely on the same page here"¦ and, in my overly-verbose way, I think I can rest, knowing that we are on the same page.

Oh yes, I think so :)

Comment by Big Dave — Jul 12 2005 @ 8:51 am

This is a subject I’ve been pondering on for a while now…

The company I’m working for create desktop GUI applications. With changes in Government requirements, those desktop apps now have to have “a browser based equivalent that uses Web Standards” (They mention WAG).

From research I’ve done there seems to be 2 types of “web application”:

1. For example, Amazon is considered a web application, (although I consider it a web site).

2. Apps like OddPost – which mimics desktop app behaviour in a browser.

The second option is more inline with what we will be creating.

Usability experts like Jakob Neilsen suggests that these browser-based apps should follow the same guidelines that desktop GUI apps follow (e.g. standards set forth by Microsoft, Apple and Sun etc.).

Most desktop GUI applications have “minimum system requirements” (e.g. Windows 2000/XP, 256Mb RAM, JRE 1.4 etc) – these new browser based apps also have system requirements (e.g. IE 5+ or Mz 1.0+, JavaScript Enabled etc)

My point/question is where do these Accessibility Standards (508/WAG) sit with regard to this new kind browser based app?

Or do they? I mean, do they only apply to the Web Content available to the masses (web sites)?

Comment by Richard@Home — Jul 21 2005 @ 4:01 am

How about a link at the top of the page that reads “Switch to screen reader friendly version of this site” (and vise-versa)?

The screen reader friendly version is just the “no javascript” version of the site.

You could also do a bit of browser sniffing to detect if the user-agent was a screen-reader (caution however, browser sniffing is fraught with problems and I’m not even sure if screen readers annouce the fact) and make the switch automatically.

Comment by Bob Easton — Jul 28 2005 @ 6:57 am

Derek, James Edwards, Mike Stenhouse and I are starting a series of JavaScript tests over at Access-Matters. The first one tests movement through groups of links. We are logging event activities to determine how various assistive technology handles scripts.

Come on over to Access-Matters and try the test case.

Comment by Aaron Leventhal — Nov 04 2005 @ 4:30 pm

It may be too late for this older blog entry, for anyone to notice my comment, but the JavaScript accessibility story is changing.

Firefox 1.5 is due out soon and has JavaScript accessibility support via namespaced role and state attributes. This allows for accessible DHTML/AJAX applications. More details here: http://www.mozilla.org/access/dhtml

Comment by brothercake — Nov 05 2005 @ 4:38 pm

Well, to be more precise, this should allow for a framework in which it may be possible to develop accessible DHTML applications, that work in Firefox 1.5 with Windows Eyes 5.5

Don’t get me wrong here – I’m not critical, I think this is a very exciting development and could well point the way forwards, but it’s very far from being a universal solution, and the deeper stuff in there where it delves into practical code examples, doesn’t consider any other browsers besides IE and Firefox 1.5, so it’s not web-ready code by any respect.

Comment by Aaron Leventhal — Nov 07 2005 @ 10:10 am

Thanks for the feedback!

> Firefox 1.5 with Windows Eyes 5.5
Also:
– Many of the examples already work with JAWS 7.0, and JAWS support will be fixed.
– ZoomText follows the focus in these widgets
– Input aids that use the keyboard API work with these widgets.

> doesn't consider any other browsers besides IE and Firefox 1.5,
> so it's not web-ready code by any respect.

It’s web ready because it gracefully degrades while supporting better accessibility for 98% of the browsers out there.
– keyboard navigation in IE
– both keyboard nav and assistive technology support in Firefox

This doesn’t hurt accessibility of any web pages that use it.

We won’t push other browsers into supporting this until the benefits are exposed on websites this discuss JavaScript accessibility, and until better code examples starting getting passed around the web. It’s a community effort.

Comment by brothercake — Nov 08 2005 @ 5:13 pm

Okay, well first let me apologise if my tone sounded dismissive – that was certainly not my intention.

I merely wanted to sound a note of caution – what we’re talking about here is paradigm which should (and I assume, will, though it honestly is too soon to say that for sure) provide a means of making properly accessible client-side interfaces; but it will only do this for people using the very latest version of Firefox and the very latest version of Windows Eyes

For IE using another reader, and IE on its own, you say that the keyboard navigation will still work – but are you absolutely sure about that? For example – JAWS (up to and including 6.2) doesn’t generate keydown or keyup events on links – how do you propose to implement the additional scvripting that a system based on custom tabindices would require, when the reader doesn’t generate the events that power it?

But more to the point – what about other readers, like Hal and Home Page Reader? What about other browsers like Opera and Safari? A tree menu or other widget built using these techniques won’t work at all for any of these devices, when one built using the “traditional” method of using only links and form controls for interactive elements, will work fine in all these devices, including the new ones.

So retrofitting an existing tree menu using the approach you’re recommending could actually make an interface inaccessible to several groups of users, when it was accessible before.

And that was really my point – perhaps I misunderstood your intention, but to suggest that this is a ready-to-use, websafe paradigm would be misleading – what we’re looking at here is cutting-edge development which may or may not turn out to be a viable approach.

Comment by Mike — Nov 15 2005 @ 8:02 am

It seems to me that this is very similar to the problem with hand-held devices: some don’t support the @handheld CSS rule, while others still deliberatly ignore it, because they feel that it degrades the content they recieve.
It seems like we need to lean a bit more heavily on some of these relatively minor players, and/or put a little more weight on the W3C recommendations.

Comment by Aaron Leventhal — Nov 16 2005 @ 1:33 pm

> let me apologise if my tone sounded dismissive
I didn’t think so :) We’re both learning here.

> For IE using another reader, and IE on its own, you say that
> the keyboard navigation will still work – but are you
> absolutely sure about that? For example – JAWS (up to and
> including 6.2) doesn't generate keydown or keyup events on
> links – how do you propose to implement the additional
> scvripting that a system based on custom tabindices would
> require, when the reader doesn't generate the events that
> power it?
At the moment these web applications are designed to work with “forms mode” in JAWS or “browse mode off” in IE. You’re in a GUI control and you need to have to browser do the browsing instead of the screen reader. It’s the same already today with ordinary HTML form controls.
In fact if you put xhtml2:role=”wairole:application” on your or then Window-Eyes will automatically go into the correct mode to start with. You’re basically saying, treat this as you would an application rather than a document.

> what about other readers, like Hal and Home Page Reader?
I’m not sure what Hal will do, although I have contacted Dolphin systems to get their support for Firefox.
HPR is almost entirely used by web developers looking at the accessibility of their web pages. It uses IE undeneath, and hasn’t been updated to support DHTML accessibility.

> What about other browsers like Opera and Safari?
Opera and Safari are contributing to the WHATWG spec (www.whatwg.org) which includes tabindex=”-1″ usage.
So, eventually they will be covered on the keyboard navigation issues. Opera isn’t currently screen reader accessible at all, and I believe Safari is farther along but not complete in that regard. I doubt keyboard-only users would be on an Apple at this point. So, what I see here is a problem for Opera keyboard -only users.

> And that was really my point – perhaps I misunderstood your
> intention, but to suggest that this is a ready-to-use, websafe
> paradigm would be misleading – what we're looking at here is
> cutting-edge development which may or may not turn out to
> be a viable approach.
Okay, I may have overstated where we’re at. Being cautious is good at this point. Right now I just want to at least get the cutting edge developers to start experimenting with this.

Folks at major companies are looking at this stuff, because it is extremely powerful and is being put into a W3C standard. We need to get enough cutting edge developers like yourself to understand and give us feedback so that we can move it to the next level.

Once we get the standard published we can push some of the other browser manufacturers to support it, if we have enough industry buzz and interest.

Comment by mike — Nov 17 2005 @ 5:32 am

You’ve lost me again now – you seem to be saying now that this will only be useful after all of these awkward browsers fully support this as a standard, but if they just supported HTML fully then we wouldn’t have a problem anyway.
Before anyone gets upset, I do appreciate that the current HTML standard makes compliance a lot easier for Visual browsers, so maybe a few changes to that would help, but the basic problem is that these browsers do not/ can not understand structures that are normal for a visual browser.

Comment by brothercake — Nov 17 2005 @ 12:07 pm

> but if they just supported HTML fully
> then we wouldn't have a problem anyway.

> but the basic problem is that these browsers
> do not/ can not understand structures that are
> normal for a visual browser.

I don’t agree – the basic problem is not understanding stuctures, per se, it’s understanding dynamic changes to those structures. If every browser and reader was 100% compliant to HTML it wouldn’t help us here, because that isn’t the problem.

The core problem is one of understanding and notification. How does a screen reader know that a list is a menu, and not just a list? How do they know that a triggering link within it is an interface trigger, and not just a regular link? They have no visual design cues that a sighted user relies on. And when (in that same example) a menu opens, how do we convey that difference – how do we describe “open” and “closed” as states to a screenreader – how do we even notify them, let alone convey any sense out of them?

If there’s one thing we’re learning from the testing at Access Matters is that readers just weren’t designed to convey and handle this kind of dynamic state information on the client – they’re designed to handle the state information of individual page requests over HTTP.

So as much as it would be lovely to find solutions to these problems with current technology – and I’m certainly not ready to give up just yet – I also think it’s reasonable to take a different view at the same time – to suggest that maybe current technology simply isn’t up to the task, and what we need to do instead is derive a new set of technologies, and then encourage the vendors to take them up (if they prove to be successful)

And phrased in those terms I think that’s what this is all about, so with the notes of caution and provisos I’ve mentioned myself, I think it’s completely fair enough to start thinking in the terms of what devices “should do in the future” as well as what they “actually do now”

Comment by mike — Nov 18 2005 @ 4:50 am

> I don't agree

Strange, all of your comments agree with the point I was trying to make!

Given the amount of DHTML that can now be done with pure CSS, merely turning off Javascript will not fix this problem.
Perhaps what we need is something similar to CSS, but for dynamic elements?

Comment by Saha — Dec 25 2005 @ 6:21 am

From a development point of view, that means you have to think up two different systems in tandem. Emminently do-able, but it's unavoidably more work.

When you've got n user agents that support a bit of JavaScript, but don't support another bit, that multiplies the difficulty by a factor of n.

Comment by Aaron Leventhal — Dec 28 2005 @ 11:07 am

> When you've got n user agents that support a bit of JavaScript,
> but don't support another bit, that multiplies the difficulty by a
> factor of n.

It’s still easier to create a web application than to write a win32 app, a GTK app and a Cocoa app. And then you get the advantage of instant distribution and updates. The user doesn’t need to click on any security warning dialogs, etc.

That’s why the ability to use this technology to add keyboard nav, and say what is a menu vs. a tree view vs. a list is important.

As for the problem where screen readers deal with each document on the basis of a new http request, this is dealt with by treating web applications as dialogs (echo focus and state changes) rather than as documents (where the screen reader is actually in control of the user’s point of regard). If a dynamic change to the document needs to be spoken, it can be marked with role:alert.

Comment by Bilkid — Mar 09 2006 @ 1:45 pm

I'm concerned that we're going to get people building AJAX type applications that simply won't work at all without JavaScript on
Well… We can use graceful degradation (or p.e.) to account for the users with javascript off or a non-javascript browser.
But can we make AJAX without javascript?

Comment by Richard@Home — Mar 22 2006 @ 5:44 am

hehe, way to plagurise my comments in the same article I commented on Pizza eater :-p

I suspect its some bot spam Derek ;-)

Comment by Baker — Mar 24 2006 @ 12:45 am

Hei! :)

Comment by Derek Featherstone — Mar 24 2006 @ 1:22 am

Hei! :)

Baker. I’ve deleted your URI from your comment… I looked at the site that comes up and I’m not about to support whatever it is that you have there at the other end. Some Top 10 thing.

Richard made the comment that the comments seemed like from a bot. It doesn’t really make a difference to me – bot or real person – if I see the URL as spamming, I’m going to either delete the comment entirely or remove the linkage.

If you are going to link to a site when you leave a comment, it had better be a real site with real content.

Comment by Chris — May 11 2006 @ 12:38 pm

Regarding this statement:

It's still easier to create a web application than to write a win32 app

Here’s my response:
I’d have to disagree. I can build a very Win32 application that will work on any Windows version from Win95 and up in a matter of a couple days. It’s all a matter of complexity.
If one is trying to build a web page that performs simple calculations (say mortgage amortization, very rough tax estimation, etc.), then I’d have to say it would only take me about the same amount of time to do a web based version (in JavaScript or otherwise), as it would a Win32 app.
Disclosure: Keep in mind that I’ve also personally written custom controls (mostly based on existing MFC controls), that work the way I needed them to.

Comment by Nathan — Jul 11 2006 @ 6:42 am

I think your comments about being able to turn javascript off are a great idea!

Not only does this present the means to provide alternative content in place of javascript coded applications but this method can also be used to present alternative information in place of java applets, flash, Quicktime Video, etc…. take a look at the swf object at http://blog.deconcept.com/swfobject/ and you can see that some members of the flash community have already begun to embrace this idea.

Given that jaws is one of many screen readers out there, with no single screen reader enjoying market domiance in the same way that IE dominates the browser market, XHTML and server-side scripting is still the best fall back in terms of accessiblity. And as AJAX and flash are more about hightening the experience of view information via the web XHMTL & Server-Side Scripting is still capable of providing the same base content.

Derek! please keep say turn off javascript!! and lets make those browers makers listen!!!

Comment by Kravvitz — Oct 10 2006 @ 9:44 pm

The URL to the Accessibility Toolbar seems to be broken. Here are two that work currently:

http://www.visionaustralia.org.au/ais/toolbar/
http://www.nils.org.au/info.aspx?page=614