Re: Frames and Accessibility

it helps me but then how do we get back from the point at which we were when
we followed the link easily if we wish?  I don't think although I could be
incorrect that the back button works in this senario and I cannot think of
an easier way to do it.

----- Original Message -----
From: "Jim Thatcher" <jim@jimthatcher.com>
To: "'Aaron Smith'" <aaron@gwmicro.com>; <w3c-wai-ig@w3.org>
Sent: Friday, January 17, 2003 10:53 AM
Subject: RE: Frames and Accessibility



Sure Aaron. And I am sorry about not being up to date on how Window-Eyes
handles focus and frames (especially given the GW Micro site!). I should
have an example, but I don't.
Say your have two frames:
Left hand side:
name="navigation"  (the name attribute is restricted to have no spaces)
title="navigation links"

Larger frame on the right:
Name="maincontent"
Title="Main content"

Say you put a whole bunch of links in the navigation frame, and when you
activate a link there it opens content in "Main content" (Use
target="maincontent". It is very important to use that target attribute
so only the target frame needs to load.) If you do that then the focus
(the dotted focus rectangle around the link) stays in the navigation
frame. This is a bug in IE, as far as I am concerned. Because of the
bug, it is the way JAWS handled frames - I think Window-Eyes too. Focus
should move to the main content frame and be handled there in the same
way that the browser handles opening any page. The way this should work
(and the way it works with HPR) is, when you activate a navigation link
and new content opens in "main content," the assistive technology will
read the main content. This is the way access to lists of links and main
content should work.  (The frames are properly coded in
http://www.freedomscientific.com/HTML_challenge/files/frames_demo2.html
and if you get the focus rectangle in the navigation frame you can SEE
the focus stay there - wrongly - when the content opens.)

Did that help? I feel like I am just saying it over again and louder!

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 Aaron Smith
Sent: Friday, January 17, 2003 9:18 AM
To: jim@jimthatcher.com; w3c-wai-ig@w3.org
Subject: RE: Frames and Accessibility


Jim,

Can you provide us with an example of what you're referring to below? I
was
going to respond in terms of what Window-Eyes does, but I'm not real
clear
on what we're attempting to do here. Are you saying that, after
selecting a
link in a frame, focus should go back to that frame? Wouldn't that
depend
on what content changed in what frames?

The reason I'm asking is because we're in the process of doing some very

cool stuff with Window-Eyes in terms of web accessibility in for next
release, and we'd like to get this problem straightened out.

Thanks!

Aaron

At 09:49 AM 1/17/2003, Jim Thatcher wrote:

>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

--
To insure that you receive proper support, please include all
past correspondence (where applicable), and any relevant
information pertinent to your situation when submitting a
problem report to the GW Micro Technical Support Team.

Aaron Smith
GW Micro
Phone: 260/489-3671
Fax: 260/489-2608
WWW: http://www.gwmicro.com
FTP: ftp://ftp.gwmicro.com
Technical Support & Web Development

Received on Friday, 17 January 2003 11:21:09 UTC