W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2003

Re: Frames and Accessibility

From: David Poehlman <poehlman1@comcast.net>
Date: Fri, 17 Jan 2003 11:15:33 -0500
To: jim@jimthatcher.com, w3c-wai-ig@w3.org
Message-id: <002a01c2be43$a9bd58c0$6501a8c0@handsontech>

from what I can tell, jaws will not in the next release.  The problem with
frames is that you have to have focus to two objects at the same time in
order for them to be relivant in most cases.  The eyes can do this.  Screen
readers are juxtaliniar meaning that we can only focus on one thing at a
time with few rare exceptions and what is focused on is what is interacted
with.  The way we handle frans and the reason why good titles are so
important is that we can pick from among the frames what weems most relivant
for our needs in terms of what would be most meaningfull.  This is really
difficult to explain with out a site to demonstrate it with and I cannot off
hand think of one but it is kind of like flipping through sections of a book
to decide whether or not you want to read the index which is a good
reference, the table of contents which if done propperly can lead you to
where you need to go or at least help you prioritize your interaction with
the media or just o the main body to read from beginning to end.  Within
this structure, jaws also allows you to go through the main sections of a
web site if there are headings and they are well utillized sort of like
those tabs in some folders that are to devide one set of pages from another.
There are other engenious ways that users of newer jaws can utillize to
navigate and interact with web sites as well, but we still have not found a
way to use frames in a manner that allows us to scroll through the left
frame and have the mid/right frame updated and hear them both or the
relivant one.

----- Original Message -----
From: "Jim Thatcher" <jim@jimthatcher.com>
To: <w3c-wai-ig@w3.org>
Sent: Friday, January 17, 2003 9:49 AM
Subject: RE: Frames and Accessibility



Hi Julian,

Everybody is down on frames and I think one reason is that screen
readers (because of IE) have not, up till now, properly implemented
frames. Frames provide the best "skip Navigation" imaginable. When you
open content from the menu frame, assistive technology should
automatically be reading the content. Any time you follow a link within
a frameset, content that changes should automatically get focus. IE
doesn't do that, so JAWS didn't either (I have forgotten what
Window-Eyes does). HPR does it right now and JAWS will, in the next
release.

In all the responses to your question, Julian, I didn't see the one
"required by" Section 508. That is to provide meaningful titles to each
frame that describe the purpose of the frame. As someone said about the
name attribute, "top" is not good but "messages" makes sense. These
titles should be in BOTH the name and title attributes of the frame
elements because some assistive technologies use the name attribute;
some use the title. It is also a good idea to check that your frame
pages have meaningful TITLE elements, something that is often omitted
because they are not usually visible. There is more about frames in the
web course, http://jimthatcher.com/webcourse4.htm#webcourse4.2 .

With all the bad vibes that frames are receiving in this thread; please
understand that there is nothing in WCAG AA that require you not to use
frames.




Jim
508 Web Accessibility Tutorial http://jimthatcher.com/webcourse1.htm.
"Constructing Accessible Web Sites:"  http://jimthatcher.com/news.htm

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
Behalf Of Julian Voelcker
Sent: Friday, January 17, 2003 7:23 AM
To: w3c-wai-ig@w3.org
Subject: Re: Frames and Accessibility


Hi Tina,

Thanks for getting back to me.

> Keeping the nature of the information firmly in mind, is a very good
>   starting point. So why don't ask yourself whether or not the nature
of
>   the information you want people to get access to is _really_
separated
>   into two physically different entities ?
>
>     In the case of the library, is not the navigation really an
integral
>    part of the content ? A description of it ?
>
>     In the case of the chat, you are describing not only using frames,
but
>    also client-side technology - ie. a self-refreshing frame - which
may
>    not be available. This places you in the situation of actively
relying
>    on two different techniques, neither of which is guaranteed to be
>    present.
>
>     If you really want to reach 'AA', then refreshing done client-side
is
>    currently out of the question. With that in mind, why not also
remove
>    the frames ?

In both cases we have gone down the relevant route due to usability
issues.

It is impractical for us to cut back on the functionality/usability of
these
pages which is why we are considering providing an alternative version
of the
pages.

> Perhaps it would be a more productive route to look at the
functionality
>   which seems so dependent on a client-side technique that might not
exist ?

We are working through the site to ensure that it will work if js is
disabled.
The pages that we might have problems with are the pages that we would
prefer
to keep framed so will be looking to detect if js is enabled and then
redirect
the users to the non framed accessible versions.

> That would mean that the alternative page need use a different
functionality
>   that the main pages, which means you need *two* implementations.
Again it
>   seems more fruitful to actually rethink the concept.

We don't really consider that to be much of a problem.  We would rather
do
that than provide the users with reduced usability.

> That, in my opinion, is the entirely wrong way to go. Accessibility is
>   more hurt by having site-specific methods for changing fonts,
colours,
>   and soforth, than it is helped by it.

We have argued this one back and forth.  The site is aimed at the
voluntary
sector and we have spoken to a number of charities involved with visual
impairments and have received very mixed views.

At the end of the day we have decided to provide the facilities for
those that
want to use it, but will also be providing advice on how they can change

settings in their browser and use their own stylesheets so that all
sites
display how they want them.

> I suggest that you _first_ of all ask yourself "Why do we want to
achieve
>   WCAG 1.0 double-A ?", with the weight on the _why_. There is little
point
>   in doing it just to do it.

Our users have requested it and will benefit from it.


Sorry it is difficult to explain things more fully without showing you
the
pages, but they are all in a secure area of the site.

Cheers,

Julian Voelcker
Received on Friday, 17 January 2003 11:16:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:08 GMT