E-mail List Archives
Number of posts in this thread: 1 (In chronological order)
From: Terence de Giere
Date: Feb 14, 2002 4:19PM
Subject: Re: discrepancy with frames and 508 standards
No previous message | No next message
Chris --
Frames are supported in HTML 4.0/4.01 and XHTML 1.0, and accessibility
guidelines from both the W3C and in the Section 508 rules give some
assistance in the use of frames, but frames are really not ideal for
accessibility even when the technology supports them. I read somewhere
that there was a "big battle" at the W3C over whether to support frames
or not, which they finally did.
While frames are very convenient for displaying fixed material with
scrolling content, and can put up multiple pages, possibility from
different locations, into the frame windows, they have usability
problems in non visual modes. The main problem is unlike with visual use
frames are not simultaneously experienced in a non visual rendering, and
in a text browser such as Lynx, sometimes used with a screen reader,
frames are presented as links to separate pages.
So the user must first identify the frames, and then enter them
separately. The TITLE attribute may help as in the accessibility
guidelines, but some of the technology does not render the TITLE
attribute. It renders the NAME attribute instead. When I tested IBM Home
Page Reader and Lynx neither rendered the TITLE attribute, but both
rendered the NAME attribute for frames. That helps, but navigating in
and out of the frames was not immediately straightforward. If one frame
window is navigation then giving the TITLE attribute a value like
"Navigation Links" and the NAME attribute a value like
"navigation_links" will help with some technology. For the content frame
use something like "Main Content" for the TITLE and "main_content" for
the NAME. There are some older technologies that do not support frames.
To support these, you need basically a non frame version of the site.
Twice the work.
Frames also break the page to page navigation paradigm for the Web. The
user must figure figure out how the frames are related, which frame
loads what. This gets more difficult when there are more than two
frames. Thus navigation requires going to separate pages for content and
navigation and whatever else might be in a frame window - very awkward.
Suppose you had to eat meals by going to a separate room for each kind
of food.
Also, if links are in the content pages, pages may load into the
frameset that were not intended to load. I used an intranet once, where
a secondary department site used frames. A link to the home page of the
intranet resulted in loading the intranet home page into a framed
subsection of the same site. That means the coding of all pages in the
site require attention so pages do not load into the frames that were
not intended to do so.
The W3C seems to be moving away from frames. XHTML 1.1 and XHTML Basic
do not include frames. The ISO version of HTML also does not allow
frames. The replacement for frames is the OBJECT element, which can be
nested to allow for multiple alternative content. If a browser does not
support OBJECT, it could, for example, display a link to the same
material, or a text version of the material.
CSS2 allows pages to have fixed elements and many of the effects of
frames, such as scrolling content with a fixed menu (which could also
have scrolling content if the window was too short) can be created. And
this can be done with a plain flat HTML page model. Internet Explorer,
however, the most used browser, does not support this fully yet. This
method provides pages that appear normal to assistive technology.
The W3C is working toward a flat page model, that with single authorship
(that is, with a single HTML or XHTML page), all devices and browsers
can be accommodated. Frames appear to be being phased out.
Some sites make the frames more interactive by scripting. If a page
changes in the content frame by following a link in the content frame
page, scripting can highlight the menu item for the new page in the
navigation frame. But such script often does not render at all in screen
readers even if the underlying browser supports it.
Also check the HTML - validate the HTML. The W3C frameset specification
varies from what many graphical development tools create, and there may
be some anomalous code problem that is preventing JAWS navigation into
the frames.
I do not have a copy of JAWS at the moment, but there are comments on
the Internet to the effect that frames are accommodated by JAWS. Some
users appear to have trouble because they cannot remember or find the
commands to use. There is the old engineering proverb - "When all else
fails read instructions". Each assitive device has its own peculiar set
of keyboard commands that allow entry and exit into frames, forms etc.,
and they tend not to be self evident.
Regards,
Terence de Giere
= EMAIL ADDRESS REMOVED =
>
> From: Chris Keller < = EMAIL ADDRESS REMOVED = >
> Subject: discrepancy with frames and 508 standards
>
> 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/