Re: Web Frames Accessibility Question

**Summary:

I want to second Phill's assertion that we need a model of how people use
layout cells to build rhetorical structures.  To me, this is the key to
geting the components that build the graphical presentation marked well
enough with rationale so that we can infer (automatically re-flow the
contents into) appropriate or literate Table of Navigation and "just read
it to me" linear structures.

However, a defined linear sequence for the frames does not provide a
complete explanation of the logic behind a frameset.  One wants to know
about the content relationships that motivate the layout.   These form a
graph of "layout cell state topics" and relationships among these.  Once we
have a schema describing the generic way the rationale motivates the
layout, we have the foundation laid for routine algorithmic extraction of a
tree or linear flow that reasonably works.

Automatic extraction of this flow is a long-range goal.  The author can
provide the access functionality currently by putting frame role
identification in the titles and/or names of the frames as allocated in the
frameset, and a hypertext narrative overview of the logic of the topic
decomposition in the NOFRAMES section.

As we go from table layouts to frame layouts, we are forced to add 'state'
to the topic role name.  It is not just a layout cell topic -- it is a
layout cell state topic as the contents of the layout change.  It is good
to think in terms of layout cell state, because people reuse the same
layout across pages for usability, even when their hypertext officially
rebuilds the structure independently on each click.

**Details:

At 03:46 PM 2000-06-20 -0400, pjenkins@us.ibm.com wrote:
>
>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?
>

AG:

It means something which is more the general English 'element' than the
markup language-technical 'element.'  In other words the image which is the
content of a web resource referenced in an html:img.src attribute is an
element in the sense used here.

The connotations of element as used here are a) primitive and b)
constituent.  Primitive in this context means that one cannot subdivide the
'element' further by means of the markup language structure.  To the markup
language it appears as a unit.  Constituent means it is some of the data
used to represent the sense of the document or message.

>
>>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).
>

AG:

Frames are used to create a persistent two-dimensional presentation
structure within which one creates a pattern of changes in the content.
Tables are used in a way which (formally) create a two dimensional
structure where there is one and only one content value for each cell.  In
a frameset, the content options per cell will be multiple, in general.

A frameset is a rhetorical structure which is an invariant of a patch of
the interaction process.  Usually used to provide contextual information
which is generic across the multiple content samples that appear in a more
rapidly changing frame.


>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.

AG:

The ideas that have been running through my head lately on this topic are
about as follows:


It helps to know the role or function of the frame, and not just have a set
serial order for them.

And I agree that the design cliches that I am about to mention apply
equally to layouts built with tables, frames, CSS, XSL, SVG, you name it.

The top frame often has the role of distinguishing the site you are at from
the rest of the web.

The left frame often has the role of giving a guide to the site or
department in the site that you are currently in.  In terms of Dan
Connolly's triage of links are either "here, near, or anywhere" the main
frame embeds its own guide to further detail on its topic.  The left bar
guides you to resources that are near [on the same site and closely related
in topic].  Links to anywhere are ususally downplayed with an idea to
keeping you nearby.  They get pushed down into the foot bar which may be in
the main frame or in a separate foot frame.

The knowledge engineering approach that I see us taking is to look at a
page design and say: "If this page were the response to a query, what would
the query have been?"  And then make sure that the information is available
to match site contents with that class of queries.

Why are the contents of these two frames juxtaposed?  Why does this frame
link to that page?  

If we can answer those questions, we start to put together the schema for
how access-critical knowledge should infiltrate the on-page and on-site
information structure.

** Critical image:

The idea here is that if you are reading a framed site frame by frame, you
need to have accelerated access to the related content in peer frames.  [Of
course frame coding is imperative and doesn't set things up entirely this
way.  You don't know from one frame content what the peer frame content is
supposed to be except by acutally stepping through the process and getting
the frames populated.]  There is an natural move (i.e. that I think people
would really use) from the main frame to the nav frame of the same
frameset.  This is a potential UI verb.  The point is that for the audio
visitor that is going to be in a little peephole viewframe buried in one
frame or another, there needs to be a vocabulary of relationships by which
they can move among the frames of the common frameset which is more
informative than just "pop up to the frameset and re-read the titles or
names of the frames."  The roles of the peer frames could be imported into
the navigation destination list of structural navigation while one is in
content designed as the content of a frame.



>
>>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.
>

The graphic pattern into which text or other content is filled, as
constructed by a FRAMESET, is a non-textual macro or pattern in the web
content.  It is not an element in the sense that I defined above, but it is
a non-textual primitive that is a constructor of the way the author expects
the content to be presented.

Naming the frames and providing a guide to the logic of the frames in a
NOFRAMES section are available techniques to overcome the access barriers
caused by the fact that in a FRAMESET some of the rhetoric is in the
layout.  The part of the content that needs a textual equivalent here is
the underlying relationships between the parts that motivates either the
graphical layout or the tree or linear flow.

A linear flow is not enough without glue verbiage.  Remember your freshman
composition teacher talking about starting and ending sections of your
prose with framing and connecting sections?

The content is often arrayed in a graphic layout [c.f. true tables] because
there are content relationships to more other chunks of the content than
just those that can be placed as predecessor and successor to the current
chunk.  Because there are more relationships running around than can fit
into a linearized flow, there needs to be a little glue verbiage
interpolated.  Generating that in a literate fashion requires knowing which
relationships are significant in this document, and in content-specific
language what the relationships are.

>
>>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.
>

AG:

Yes; the most that was intended in including framesets in 1.1 is that the
frames in the frameset should be verbally identified well and that the
logic of the decomposition into frames should be articulated in a hypertext
guide to the contents embedded in the NOFRAMES section.  

A parallel page or sub-site was not, IIRC, ever considered as something
that one would need to do for a FRAMESET and its associated patches of
frame content to pass WCAG.

AG:

Glossary warning:

Where I say 'role' above I specifically mean a place within a pattern.
This is not something fully defined by a type of object in isolation, but
rather by some type of pattern that the object can fit into.

Webs are patterns that go on forever.  What you need to know about each
local patch of the web is not entirely isolatable from a family of contexts
stretching out farther than the eye can see.  But yet anyone can follow.
Hey, this is turning into a theme piece for the whole WAI.

Al



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

Received on Thursday, 22 June 2000 10:29:39 UTC