[thelist] site check (accessibility)

Ian Anderson ian at zstudio.co.uk
Wed Nov 2 03:44:25 CST 2005


Eike Pierstorff wrote:

> The client supplied some bits of flash, some eye candy for the start 
> page and a flash game. 

The fact that the animation on the home page won't stop is an access 
problem. Using gif, the user can stop the animation if they have a 
cognitive disability that makes it hard to concentrate when there is 
movement in their field of vision, but if it's Flash this shortcut 
doesn't work.

All animation should stop after a short time.

> Nobody really 
> seems to know how screen readers respond to Javascript. 

Most screen readers (virtually all, in fact) are used in conjunction 
with Internet Explorer for Windows. IE builds the page, including any JS 
generated content, and supplies it to MSAA, the Microsoft Active 
Accessibility layer, which maintains a version of the page very similar 
in nature to the DOM tree. It is this MSAA data tree that is navigated 
and read by the screen reader application.

So, screen reader users have full access to JavaScript content that is 
created as the page loads. They also have access to any UI that uses 
onClick, as this fires when the link has focus and is activated by the 
Enter key. MouseOver events do not fire, and these should have 
alternative event handlers such as onFocus and onBlur specified,for 
functionality that is important (i.e. not for rollovers or supplemental 
information). This is more for sighted keyboard users than for screen 
reader users, because typically mouseovers are used for modifying the 
page display and there are various reasons why this isn't any use to 
screen reader users even if the functionality is triggered.

Things like JS popup windows tend not to cause any problems, and because 
they contain a restricted amount of content are often easier for screen 
reader users to work with compared to normal templated pages with all 
the excess navigation and so on.

The most worrying issue in this connection is when and whether the MSAA 
data tree is updated when the DOM is manipulated by JS.

There are normally two cases:

1. The page is modified on the fly, but the MSAA data tree is not. The 
screen reader user is not aware of any changes. Or, the MSAA data tree 
is updated but the screen reader application chooses not to use the new 
version.

2. The page is modified on the fly, and the MSAA data tree is updated. 
The content is now available for the user to experience, but the page 
resets to the top while the user is in the middle of the page. This is 
like being hit over the head with a brick while you are trying to read 
the newspaper.

In the screen reader preferences, the user may be able to choose which 
behaviour they prefer. Neither is much use.

In general, for accessibility it is best not to modify the DOM after the 
page has loaded, but you can do anything you like *while* it is loading 
with some confidence that screen reader users will not be adversely 
affected.

Final word of advice - download JAWS and try it out on your site. The 
basic shortcuts are quite easy to learn - you don't need to be expert in 
all of the hundreds of controls to get a lot of value from the exercise.

For the faint-hearted, you can try IBM Home Page Reader instead, but it 
isn't typical of JAWS, Window-Eyes, Hal or other proper screen readers.

Hope this helps

Cheers

Ian

-- 
_________________________________________________
zStudio - Web development and accessibility
http://zStudio.co.uk

Snippetz.net BETA - Online code library
File, manage and re-use your code snippets online
http://snippetz.net




More information about the thelist mailing list