action item for the testability of 3.5 (annotating complex information)

My action item was to look at the success criteria for 3.5: "Annotate
complex, abbreviated, or unfamiliar information with summaries and
definitions."

The guideline currently has the following success criteria and issues:
----------------------
Success criteria:
1. a definition or link to a definition is provided for phrases, words,
acronyms, and abbreviations specific to a particular community. 

Issue: Should this criterion be restricted to the first occurrence of an
acronym or abbreviation, as in WCAG 1.0?

2. a summary is provided for 
- relationships among cells for tables with nested headings, 
- relationships among cells that span multiple columns or rows, 
- or other relationships that may not be obvious from analyzing the
structure of the table but that may be apparent in a visual rendering of
the table. 

A summary may also describe how the table fits into the context of the
current document.

Issue: the second success criterion is very specific to tables. Can it
be generalized? 
Issue: What other applications of the principle enunciated by this
checkpoint should be included in the success criteria? How can the
criteria be improved? 
------------------------------------------------
Success criteria 1:
It is testable. I suggest modifying it to state that all acronyms and
abbreviations should be defined, not just those specific to a particular
community.

In response to the issue about how often to provide the definition, I
think that providing the definition when the term is first used is
sufficient. If you provided the definition with every occurrence, the
document could become cumbersome. Redundant links to definitions could
be distracting, especially if the term is used often.

------------------------------------------------
Success criteria 2:

As it is written, it is not testable because
1. It is not clear what constitutes a summary. 
2. It is not clear what types of tables warrant a summary. 
3. The third bullet that talks about summarizing a table with
relationship that are not obvious is subjective.

Regarding #1 - We need to be clear about what a summary is. Does it mean
referencing the table within the text of the document? What if the whole
page is about one table - is a summary really needed, or does the entire
page count as the summary?

Regarding #2 - The success criteria lists 3 things to summarize. If
we're saying that only tables with these items need to be summarized, I
think we should word it like:
"Provide a summary for tables with nested heading and/or cells that span
multiple columns or rows. The summary should explain the relationship
between the cells."

Regarding #3 - Deciding whether or not a "relationship is obvious" is
not testable because it depends on the person evaluating the page. I
think it should be omitted or put in a "non-testable" section.

In response to the issue about other applications that require
summaries, here's a list:
- Visual representations of data, such as a graph (e.g., a line graph)
or chart (e.g., bar chart)
- Diagrams (e.g., network topology)

These items should be supported with a summary to explain their context
or purpose.

Received on Wednesday, 23 January 2002 00:50:42 UTC