E-mail List Archives
Thread: discrepancy with frames and 508 standards
Number of posts in this thread: 3 (In chronological order)
From: Chris Keller
Date: Thu, Feb 14 2002 1:52PM
Subject: discrepancy with frames and 508 standards
No previous message | Next message →
I have heard and read many times that websites in frames comply with the W3C
508 guidelines. However, we had a blind student, CJ, test our courses which
are using frames with his screen reader, Jaws (version 4.0, I believe), and
he could not access our courses. We are naming our frames and can't figure
out why the student can't access our courses. We have done our own tests
and validate CJ's findings that our frames setup is inaccessible with his
Jaws software. He gave a presentation to our 20 full time employees and
adamantly argued that frame sites are inaccessible and that we should design
in tables. Here is an example course:
http://ce.byu.edu/courses/univ/488025350004/public/start.htm
Could anyone please address this discrepancy or give us suggestions? Thank
you.
Sincerely,
Chris Keller
Quality Assurance Supervisor
BYU Center for Instructional Design
(801) 378-7686 office
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Thu, Feb 14 2002 3:35PM
Subject: RE: discrepancy with frames and 508 standards
← Previous message | Next message →
I tested the example course that you referenced with Jaws 4.01 on Window
2000. I was able to navigate it without too much difficulty.
There are a few things that may be causing errors for the student
though:
1. The navigation frame is built on JavaScript. None of the links do
anything if JavaScript is disabled. All of the links say <a href="#">
and then have some onClick function. Maybe the student has JavaScript
disabled. If at all possible, you should provide real links: <a
href="page1.htm">, for example. It is possible to specify both a real
link destination and an onClick function. This won't solve the problem
if the onClick function is necessary to make the site work, but it will
solve the problem if the JavaScript function does not provide any
special features that are absolutely necessary to run the site. It seems
to me that you ought to be able to get rid of most or all of the
JavaScript without sacrificing too much, if anything. It's always best
to use server-side scripting whenever possible, rather than client-side,
from an accessibility standpoint.
2. Your frames have names, but they don't have titles. JAWS usually
reads the names, but name attributes are not meant to be read to humans,
they are meant for programming/scripting purposes and the like. The
title attribute is meant to be read by humans. For example, you could
say: <frame name="main" title="Course content, main frame"...>. When I
accessed the course using IBM Home Page Reader, I did not hear the frame
names. When I used the keyboard shortcut to access the list of frames
(Ctrl + E) I heard "Frame 1: Blank, Frame 2: Blank, Frame 3: Untitled,
Frame 4: Untitled." The keyboard shortcut in JAWS is Insert + F9. JAWS
does read the names.
3. Maybe the student had frames disabled in the browser. You can get
around this problem by making sure that you have <noframes> content. The
noframes content could be a list of links to other pages within the
course. For example, your noframes could consist of the top menu items
(Sites, Discuss, Email, etc.), the side menu items (title page, welcome,
getting around, etc.), and maybe a link which says "next page". With
these links available, the student should be able to go through the main
content pages one by one, by returning to the list of links.
Frames are not necessarily inaccessible. In both screen readers, I was
able to use the keyboard shortcuts to get a list of frames, then
navigate between them (even though I didn't have the names of frames
when using Home Page Reader).
** One problem may be that the student doesn't know the keyboard
shortcut to get the list of frames. This is not a trivial problem,
because it can lead the user to believe a site is inaccessible even
though it may not be. There are a lot of people out there who are not
power users of assistive technologies and software. To make a
comparison, how many Word users know how to create a table of contents
for a document which is self-updating as the document undergoes
revisions and alterations? Power users can do this. The average user
cannot. It's true that web developers cannot control for all of the
deficiencies of the end user, but it is still something to take into
account.
Can frames be accessible? Yes, they can be.
Were the frames in your course accessible to me, with my knowledge of
screen reader shortcuts, on my machine, with my configuration? Yes. I
didn't have any problems.
Does this mean that the course will work just as well for everyone? No.
Older screen readers don't handle frames well. Also, the use of
JavaScript becomes an issue (and, in this case, is probably a bigger
issue).
As far as the potential problem of user ignorance is concerned, you may
want to provide a page that explains the layout to screen reader users.
Tell them that there are four frames, and explain what is in each one of
them. Tell them what the keyboard shortcuts are for JAWS, Home Page
Reader, Window Eyes, and other common screen readers (I don't know what
the shortcut is for Window Eyes, sorry). Make sure that this file is
available to the user *BEFORE* entering the frameset, and make sure that
the link which leads to the file explains the purpose of the file. For
example, the link could say: "Instructions for screen reader users".
Of course, there may be benefits to a non-frame approach too. It is
something worth considering, but it is perhaps not necessary from an
accessibility standpoint.
You can test out the keyboard shortcuts and screen-reader compatibility
by installing a screen reader yourself. A trial version of JAWS can be
downloaded from www.freedomscientific.com.
Let us know how it goes.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu
From: Mark Newhouse
Date: Thu, Feb 14 2002 3:51PM
Subject: Re: discrepancy with frames and 508 standards
← Previous message | No next message
on 2/14/02 3:35 PM, Paul Bohman at = EMAIL ADDRESS REMOVED = wrote:
> 1. The navigation frame is built on JavaScript. None of the links do
> anything if JavaScript is disabled. All of the links say <a href="#">
> and then have some onClick function. Maybe the student has JavaScript
> disabled. If at all possible, you should provide real links: <a
> href="page1.htm">, for example. It is possible to specify both a real
> link destination and an onClick function. This won't solve the problem
> if the onClick function is necessary to make the site work, but it will
> solve the problem if the JavaScript function does not provide any
> special features that are absolutely necessary to run the site. It seems
> to me that you ought to be able to get rid of most or all of the
> JavaScript without sacrificing too much, if anything. It's always best
> to use server-side scripting whenever possible, rather than client-side,
> from an accessibility standpoint.
Here is an excellent article on how to create such links:
http://www.evolt.org/article/Links_and_JavaScript_Living_Together_in_Harmony
/17/20938/index.html
or, if the above, wrapped url causes problems, this will get you there:
http://makeashorterlink.com/?G26E14A6
HTH,
--Mark Newhouse
We put the "blah" in blog...
<http://homepage.mac.com/iblog/>;
---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/