RE: Action Item #20

Our target is the INTENT section.  Everyone agrees that tables are covered by 1.3.1 and they are a primary and evergreen issue for accessibility.  The language in INTENT mentions tables, but is unclear on how the guideline should apply to them.  Since our scope is limited to citing and interpreting the guidelines and the INTENT section, the bus example does help the matter for SW.

Adding clarity to INTENT should not be objectionable.  Tables are mentioned but not addressed, in practice this has caused confusion, and in SW the problems are compounded many times over.

I like your rewording (and the comments that followed), it is available to a wider audience, and it looks like the group is focused on addressing some of the "term mines".  To that point, it appears as though the word "example" is a poor choice for INTENT, but "for instance" is commonly used in INTENT (e.g. 1.3.1, 1.3.2, 2.4.2, etc.).  As far as using a note, we think it fits better before the last paragraph that currently and quite awkwardly utters "table."

To answer your other question, in Action Item #19 we submitted a short list (for consideration with 4.1.2) and it does not include row, column, or header references.  Fixing the clarity issue here in 1.3.1 is preferable.

Pierce

From: Peter Korn [mailto:peter.korn@oracle.com]
Sent: Wednesday, June 27, 2012 4:51 PM
To: Crowell, Pierce
Cc: 'public-wcag2ict-tf@w3.org'
Subject: Re: Action Item #20

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?

Separately...  Reading through "Understanding SC 1.3.1<http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html>" 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:

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

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.



--
[cid:image001.gif@01CD548C.15ADAAB0]<http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 506 9522<tel:+1%20650%20506%209522>
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<mailto:peter.korn@oracle.com> to reach me
________________________________
[cid:image002.gif@01CD548C.15ADAAB0]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment