Re: Frames and Accessibility

On 17 Jan, Julian Voelcker wrote:

> I have a site that uses frames for some sections due to the nature of 
> the information being provided.

   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 ?


> 1. Put an alternative version in the <noframes> section - 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.

   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 ?





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

   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.




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

   I am not certain I understand why you believe this will solve the
  problems ?




> 4. As part of our strive for accessibility we have added a page so that 
> users can set their own fonts, colours, etc.  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.

   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.

   Consider this: if you use HTML and CSS, and stick with relative sizes for
  most things, then users can learn _one_ interface for changing their
  preferences: the one in their browser.

   If you, on the other hand, use a site-specific method for changing these
  preferences, then the user need learn one new interface per site. I really
  suggest you leave that path.



> What do you think is the best approach?

   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.

   If, on the other hand, you want to achieve it because you believe it is
  a good measuring stick for how easy it is for people to get to your content,
  then it would be time to look at which technologies you use, and why.

-- 

 Tina Holmboe           [Windrose@DALnet] [tina@elfi.org] [tina@htmlhelp.com]

$_ = <<'-- '; s/../pack("c",hex($&))/eg; eval;
7072696e7420224a75737420616e6f74686572205065726c206861636b65722c22
--

Received on Friday, 17 January 2003 07:16:23 UTC