- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 22 Jun 2000 10:47:44 -0500
- To: w3c-wai-gl@w3.org
**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