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

Re: Frames and Accessibility

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Fri, 17 Jan 2003 14:11:26 +0200 (EET)
To: w3c-wai-ig@w3.org
Message-ID: <Pine.GSO.4.50.0301171338280.12096-100000@korppi.cs.tut.fi>

On Fri, 17 Jan 2003, Julian Voelcker wrote:

> I can't realistically get rid of them totally because it degrades the
> functionality for normal users too much.

Almost all frames-based sites would benefit in functionality and usability
if they were transformed into frameless design. It's impossible whether
either of your cases is an exception to the rule, especially we haven't
got the URLs.

On the other hand, people and organizations that use frames on their pages
are usually convinced of their necessity, in a manner that is immune to
rational argumentation. So the pragmatic approach is to consider how to do
the wrong thing right.

There are about six basic points then:
1. Name the frames meaningfully. Listen to the names. "Messages" makes
   sense; "top" does not. Use more verbose explanations too, in title
   attributes in <frame>, but don't count on the titles.
2. Write a useful <noframes> element. Primarily, put there the content
   you would have on the main page if you didn't use frames.
3. Don't try to hide the borders between frames, and don't try to
   make the frames non-resizable.
4. Make sure the navigation works without JavaScript. (Quite a many
   frames-based sites rely on JavaScript being enabled.)
5. Use as few frames as you can be persuaded to. Two frames is usually
   tolerable. Ten frames is surely confusing, especially if nested.
6. Make sure that each framed page has a link to the main page of the
   site. This is more of a usability issue, but fairly important.
   The framed pages can and will be found through search engines, so
   that users get links to them directly. (And attempts to prevent this
   would create even more serious problems.)

> So, do I..
>
> 1. Put an alternative version in the <noframes> section

Of course. That should be done in any case.

> - this might be
> a little tricky because bother areas of functionality will require
> refreshing/reloading the page which will result in the frames being
> continually loaded.

It's hard to see what this refers to.

> 2. Provide an explanation in the <noframes> section and then a link to
> an alternative page.

Explanation? Maybe in some special cases. Link? Well, that would be
minimal content there. Normally it's better to include some basic content
(main heading, short description of the site, and a top-level menu of
choices) directly into <noframes> (which will act as the main page in
non-frames browsing situations).

> 3. Provide a link to an alternative page along side the link to the
> framed pages?

I think the best question is: What would you do if frames were forbidden?

> 4. As part of our strive for accessibility we have added a page so that
> users can set their own fonts, colours, etc.

That means solving the wrong problem. The task of setting the fonts,
colours, etc., in a browser is simple and works well for any page that
doesn't se constructs that break the natural adaptability of Web pages.
In fact, page-specific buttons for setting fonts, colours, etc.,
reduce accessibility somewhat especially if placed at the start of a page,
as they usually are. How useful would it be to a blind user, for
example, to hear first "(link) zoom in (link) zoom out" when he enters
a site?

> We could expand that so
> that users can specify whether they are happy to use frames or not and
> then deliver what they can handle.

In theory, <noframes> is just for that. In practice, most browsers are
still noframes-incapable. Thus, you would include an explicit link
to a noframes version somewhere, e.g. into the navigation frame or
into the initial content of the content frame. Maybe this could be
combined with the link mentioned in the 6th item in my list.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Friday, 17 January 2003 07:11:29 GMT

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