[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