RE: Bug #506

I think putting the details in the definitions is a good idea.

 

Two concerns with the definition below though.

 

1 - tables are listed as non-hierarchical which is not really best.  Would
suggest tables be moved out from the 'non-hierarchical" category and put by
themselves in the same sentence.

 

2 - the picture example may imply that we are requiring that all pictures be
done in SVG and be fully marked up in hierarchical fashion.   I think that
example might be better in techniques where it can be explained better and
looked at as where we want to go someday - not what is required for level 1
conformance - which is implied by making part of the definition of the term
used in level 1  

 

 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

  _____  

From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of David MacDonald
Sent: Monday, May 10, 2004 9:32 AM
To: 'Wendy A Chisholm'; w3c-wai-gl@w3.org
Cc: caldwell@trace.wisc.edu
Subject: Bug #506

 

Hi Team
 
I was assigned Bug #506 in which Kansas Web Accessibility Subcommittee
writes:
 
"Checkpoint 1.3: Clarify the definition of "structure" more.  There should
be a clear understanding of the difference between structure of code and
layout of information.  Example:  Developers use xml to semantically mark

up content but the output uses html/css to render screen layout."

 

I had a good conversation with Frances Grenier, Public Service Administrator
for the Kansas Rehabilitation Services, SRS, who wrote this. I send a
summary of our entire conversation soon. She feels that there will be
confusion among web masters as to whether we are speaking about layout of
information or whether we are talking about code such as server side stuff
(i.e., PHP)

 

The answer, as I understand it, is that we are referring to both the layout
and the code **as it is perceived by the user agent**. In other words we are
not referring to programming on the back end except to the degree to which
it is being sent to the client. 

 

Frances suggested the following rewording:

 

Current: Guideline 1.3 

"Ensure that information, functionality, and structure are separable from
presentation"

 

Frances' recommendation: 

"Ensure that information, functionality, and structure of the code and
layout are separable from presentation"

 

My recommendation is that it would perhaps be better to fix this in the
appendix under the definition of "structure". Also our technical documents
would give specific coding examples that would help clarify the guideline.

 

I've added a sentence to the definition of "Structure" in the appendix. (I
also fixed a typo and a spelling error that were in this definition)

 

structure 

Structure includes both hierarchical structure of the content and
non-hierarchical relationships such as cross-references, or the
correspondence between header and data cells in a table. The hierarchical
structure of content represents changes in context. For example,

1.	A book is divided into chapters, paragraphs, lists, etc. Chapter
titles help the reader anticipate the meaning of the following paragraphs.
Lists clearly indicate separate, yet related ideas. All of these divisions
help the reader anticipate changes in context.
2.	A bicycle is divided into wheels and a frame. Further, a wheel is
divided into a tire and a rim. In an image of the bicycle, one group of
circles and lines becomes "wheel" while another group becomes "frame."

 

<new>We refer to structure as it is perceived by a User Agent such as a
browser on the client side. </new>