For many "accessible JavaScript" would be an oxymoron, but in principle JavaScript could be as accessible as anything else if the author was very careful or if the user agent would know more of what is going on. …

One possible way to achieve this would be to have some user variable available to the script author, for instance stored in a user object.

Marking time

One quick preferences in Opera is Enable Animated Images. The wording isn't accidental. If you uncheck this option GIF, PNG, and SVG images will not animate, though these cases are actually handled in different part of the code (they have different models).

However a JavaScript animation will not be disabled by this preference because Opera cannot tell when the script is used for animation, and even if it could it isn't possible to cleanly separate the animation from whatever else the script is doing and safely run the rest of the script. We can't deanimate generic JavaScript. With Canvas it might be within the realm of the possible, but I don't know enough Canvas to say. (If it is, it is the first time I know of that an approach using Canvas would be more accessible than one not using Canvas.)

One of the WAI requirements is the ability to stretch or condense time in user interactions. Again, this is something a browser can do for formats like PNG or SVG, letting the animations run faster or slower, but it can't be done for JavaScript as we can't know if the passing of time is for an animation or other user interaction (which should be slowed down) or with a network process or anything else that really shouldn't be user-dependent. A clock shouldn't run slower or faster for accessibility reasons, but indicate what time it is.

Thus there is user-adjusted time as well as absolute time. In many animation formats a click, defined to be 1/60 of a second. If it had been slowed down to e.g. 30 clicks a second we would have gotten slow-motion effects.

People don't run at a universal time. There are good indications that people's time slow down as we get older, that what was seen as slow in our youth would be seen as fast in our old age. This slowdown is a fairly subtle effect. I don't know how slow the World's Slowest Person is or how quick the World's Quickest Person, but for the normal range it is far less than 2:1. A better way than slowing down time itself would be to slow down too-fast-moving objects, but such a relative slowdown is probably beyond our current capabilities.

Response time is a different matter. The time to not only perceive what the author has created, but also give the requested feedback to the author can be measured in the quickest responding many multiples faster than the slowest. Try filling in a form on a PC and on a simple mobile phone for instance.

We now have three times, absolute time, perception time, and response time. The one scripting the user interface will need to accomodate all three of these, though by assuming perception time to be same as absolute time and setting no upper bound on response time, most situations can be handled sub-optimally but tolerably well, but in some cases the author wants a response time. For instance a script will do some action if the user doesn't respond, to be able to do so accessibly he will need to know how long each of his users will need to respond. Given the wide range of reaction time he is bound to displease some of his users.

If there were two user (agent) settable properties:

user.moment
user.responseTime

it would be possible for the author to cater much more closely to the individual users, falling back to a more conservative choice if this information is unavailable.

Both times would be in seconds. I called the reaction time moment as roughly 1/10 second is the typical perception time, the rate at which we experience the world to be happening, though supposedly a moment used to be 90 seconds. They clearly lived at a slower speed in the Middle Ages.

User environment

A user object could be used for other environmental attibutes the author might need.

pointingDevice (e.g mouse | finger | multiple | noneOfYourBusiness)
keyboardType (e.g. PC | phone | remote control | none)
backgroundNoise (e.g. quiet | noisy | intermittent-noise | deafening)

Ideally an author shouldn't have to care about environmental variables like what kind of pointing device is used, but sometimes this distinction matters.