E-mail List Archives
Thread: RE: Showing and hiding data
Number of posts in this thread: 1 (In chronological order)
From: Rachel S.
Date: Wed, Jul 30 2003 6:05PM
Subject: RE: Showing and hiding data
No previous message | No next message
Thanks for everyone's feedback, it's appreciated!
I wrote:
"I would like this application to be Section 508
compliant. Are you saying the app must work with
JavaScript turned off, in order to be Section 508
compliant? I thought that wasn't a Section 508
requirement? (I do know it is a WCAG guideline.)"
Jules wrote:
"You mentioned that your organization has specified
that employees use IE as their browser. Does this also
apply to the visually impaired? If not, what are they
using? Would your company be willing to specify which
assistive technologies they are to use? Knowing what
the visually impaired in your company use will enable
you to test your app against their technology."
My response:
There currently are no visually impaired users using
the app. That's not to say there won't be any in the
future, of course. I agree with you that we need to
test it in at least one common screenreader, so we at
least let potential users know it's been tested in
that one.
Terence de Giere wrote:
"The following Section 508 information is from the
Access Board's web site. It may clarify some of the
problems surrounding scripting. At one point I have
added some information, because some of the
information on this page is just not right."
and
"If the site is not a public site, but in a controlled
situation where the hardware, browser and browser
settings, and assistive technology can be controlled,
then this is a different matter. If the combination of
hardware and software is known to work with these
examples, then there is no problem. In a public
situation, however, this assumption that scripting
will always work is false."
My response:
I am familiar with this page. But I feel that it is
unclear; difficult to interpret. Your added comment
spoke to that unclarity. It was a great wrap-up of the
some of the issues surrounding this 508 guideline.
Thanks so much for your post.
In our situation, we do have a controlled environment,
so I think we can specify that the user accesses this
app with a browser or technology that supports
JavaScript. We need to make sure the JavaScript is
accessible and usable by newer assistive technologies,
and a test in at least one major screenreader will
help with that assurance.
Kieran wrote:
"One way round this is to reload the page then write
it, this will force jaws to read the new content and
update itself. If you are writing in with innerhtml
after a user action like a click of a button, try
writing the innerhtml then doing a focus onto an
anchor at the top of the new content. Ive found this
works well to kick start jaws and put the users where
they should be."
My follow-up question:
Are you saying that the technique of setting a focus
must be accompanied by a page reload? Or will the
focus technique work by itself?
This page is a form. I would like to avoid having the
page reload (because it means we will need to store
the user's inputted data into the database even though
they haven't submitted the form yet).
Thanks again everybody!
Rachel Sengers
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/