Re: Action Item #20

\




On Jun 27, 2012, at 3:50 PM, Peter Korn wrote:

> Pierce, Al,
> 
> Would addressing row/column relationships in tables in SC 1.3.1 also address the concerns you had raised in our discussions of SC 4.1.2?
GV:  (I think that is precisely where this action item came from.  To add it to 1.3.1 and then it was handled and didn’t need to be in 4.1.2.   Am I remembering correctly Pierce?)

> Separately...  Reading through "Understanding SC 1.3.1" I'm wondering how best to add the points you are making in your text below.  I wonder if it would be more effective to convey it in the "Examples of Success Criterion 1.3.1" section.  And...  Looking at what is there already, we have a table example that makes clear that row/column structure and links to headers must be preserved.  The text from the "Examples" section is:

GV:  We don't include example section in our doc -- so putting them in the examples wouldn’t show up in the task force doc. 
> A bus schedule table where the headers for each cell can be programmatically determined
> 
> A bus schedule consists of a table with the bus stops listed vertically in the first column and the different buses listed horizontally across the first row. Each cell contains the time when the bus will be at that bus stop. The bus stop and bus cells are identified as headers for their corresponding row or column so that assistive technology can programmatically determine which bus and which bus stop are associated with the time in each cell.
> 
> 
> I'm curious, based on this existing text, what you feel is missing?  Is is that "table" isn't mentioned very specifically in the text above "Specific Benefits..."?  In that case, I have a friendly suggested rewording, in the form of a Note to appear immediately above the "Specific Benefits..." section:
> Note: One example of structure and relationships that are perceivable visually is information presented in tabular form: the visual structure and relationship of one cell to another, the structure and relationship of one cell to all the cells sharing the same row or column, and the structure and relationship of one cell to the row and/or column header. These are all important structure and relationships which should be programmatically determined or available in text.

GV:  Wow.  Nice wordsmithing Peter.   This really does fit the INTENT section language -- and mentions tables clearly.  

This does say "example' so that might cause it to be moved to examples - and fall out of the Intent -- but with the ending on it -- it really isn't a standard example -- so might stay as a note.    Not sure what a future editor might do with it though..  hmmmmm

Oh - I just noticed that we are trying to avoid standard normative terms (shall, should, may)  but I don't know how well this is done throughout Understanding WCAG 2.0  so may be OK.   but if problem we could change   Should  to  "would have to be"  to reflect that the SC makes that a required. 


I like the other paragraph that Pierce cleaned up (the last paragraph in INTENT).  would like to see that still passed up as a suggested edit. 

> 
> Regards,
> 
> Peter
> 
> On 6/27/2012 1:21 PM, Crowell, Pierce wrote:
>> 
>> Al and I received advice from Gregg on how to address this action item in a manner palatable for the WCAG WG.  Thank you Gregg.
>>  
>> Pierce
>>  
>> ACTION-20: Work with Al to come up with addition to WCAG intent for 1.3.1 to cover table cells and row/column headers:
>>  
>> 1.      Add the following paragraph to make it clear that 1.3.1 covers tables (in front of the current last paragraph):
>> When information is presented in tabular form, the row, column and header information for each cell would have to either be "programmatically determined", or the relationship between each cell and its row, column, and header information would have to be available in text.
>> 2.      For easier reading, edit the current last paragraph to read as follows:
>> There may also be cases where it may be a judgment call as to whether the relationships should be programmatically determined or be presented in text.   However, wherever possible, information and relationships should be programmatically determined rather than described in text.
>>  
>>  
> 
> -- 
> <oracle_sig_logo.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 506 9522 
> Oracle Corporate Architecture Group
> 500 Oracle Parkway | Redwood City, CA 94065 
> Note: @sun.com e-mail addresses will shortly no longer function; be sure to use: peter.korn@oracle.com to reach me
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment