Re: Web Frames Accessibility Question

Lubow Scott wrote:
>
> Hello,
> Under the working groups priority 1 checkpoints, it states that you must
> provide a text equivalent page for pages with frames (checkpoint 1.1).
> Checkpoint 12.1 states that you must title each frame.  I was wondering
> if this means that you must do both, checkpoint 1.1 and 12.1.  It seems
> redundant to title frames and then also create a text equivalent page.

Ian wrote:
>Scott,
>
>As I read checkpoint 1.1 today, I think it may be a bug in the
>spec [1] to have included frames in this list.

PJ:
I agree that "frames" does not belong in 1.1.  There are more, but I'll
keep these comments to the subject of FRAMES.  By the way (BTW), I believe
the term "non-text element" used in 1.1 is undefined and open to private
interpretation.  What does the term "element" here mean?


>Frames are generally used to create a two-dimensional graphical
>presentation. There's nothing inherently inaccessible about doing
>that (though we hope CSS positioning will replace frames, and
>frames are not promoted by W3C). However, if designed poorly,
>a frameset may not linearize well -  relationships among
>components may not "translate" to a serial rendering and therefore
>a page may be unusable by users who access it serially (e.g.,
>blind users).

PJ:
We need to consider adding a "layout order" checkpoint that cover both
tables, frames, and even CSS so that the "serial" rendering is as
accessible as the graphical visual rendering of the content.  This is a
common checkpoint in software guidelines, for example in the IBM Java
Accessibility checklist.  Again, most of the responsibility is on the user
agent, except that occasionally there are tools and / or programmers that
do not realize that "content" of the page is rendered serial in the way the
HTML code is entered in the file.  "Serial rendering" will also need to be
considered when using JavaScript.

>Frames can be made accessible through a combination of efforts
>by authors and user agents: authors are required to title frames
>properly and to provide frameset alternatives when the frameset
>does not make sense when linearized. User agents must provide
>navigation mechanisms so that users can get at components quickly
>when rendered linearly.

PJ:
I agree, except that NOFRAMES are not a recommend way to provide
accessibility to framesets that do not make sense when linerarized - a
better guidelines is to design a better ordered frameset.  NOFRAMES are
really for non-accessibility reasons, such as when frames are turned off or
are not supported by the user agent/assistive technology.


>I do not believe that it is necessary to provide a
>"text equivalent" for a frameset, notably one that only
>contains text content. To make the frameset accessible, ensure
>that is linearizes sensibly (frames should be titled for this
>reason) and if not, provide an alternative to the frameset
>that does. I note that it is preferable to avoid an alternative
>page and to make the frameset accessible directly.
>An alternative to the frameset need not be text exclusively,
>as long as the alternative content is itself accessible (e.g.,
>images with text equivalents, etc.).

PJ:
I agree it is preferable to avoid an alternative duplicated page and to
make the frameset accessible directly. In some cases, a well design
frameset is more accessible than using complex layout tables, but still has
the non-accessibility disadvantage of not being able to bookmark a specific
frame, which is most of the reason for recommending against the use of
FRAMES.

Regards,
Phill Jenkins
http://www.ibm.com/able

Received on Tuesday, 20 June 2000 16:13:47 UTC