6 December 2001 WCAG WG Minutes

In attendance:

JW: Jason White
WC: Wendy Chisolm
KHS: Katie Haritos-Shea
LGR: Loretta Guarino Reid
JA: Jenae Andershonis
PB: Paul Bohman
CS: Cynthia Stenger
MS: Mark Stinson
JM: Jo Miller
GSW: Gian Sampson-Wild
GV: Gregg Vanderheiden

Action Items:

PB: Rewrite examples for Checkpoint 1.3, to address hierarchical vs non-hierarchical 
confusion
PB,JW,CS: Think about a better phrasing of Checkpoint 1.3, criterion 2, 
to address "data model" problems
CS: Rework the working of Checkpoint 1.5, criterion 2


Discussion of success criteria

Checkpoint 1.3:

WC: The structure of a portal site may be very different from structure of 
a long document; the main thing we need to be able to test is for is
whether the structure is "Unambiguous"
JW: If there is an element in the mark-up language (or equivalent), that 
should satisfy the test.
WC: What is ambiguous, other than incompletely marked up text?
JW: An incorrect element, e.g., a heading listed as a general container. 
KHS: Incorrectly marked up data
JM: Is this solely dependent on the technology? 
PB: What technologies don't fit this?
WC: Flash? streaming video?
JW: HTML document with nothing but Span elements 
WC: Are there technologies where the capacity to mark up structure 
doesn't yet exist?
JW: Raster-based image formats
WC: We think we can test success criterion 1

JM: Criterion 2 seems testable, with the same remarks as for the first 
criterion
CS: "important" will be in the eyes of the author
JM: This also relies on the technology
WC: Jenae, can you give your testing experience?
JA: It was hard to get my group to understand this item from WCAG 1.0; I think 
this will still be hard to understand.
CS: Applying the last version of WCAG on MSN, we had trouble because it was 
too technology specific and didn't apply to ASP. Is that changing?
JA: e.g., everyone understood that Alt text needs to be used, but I had to 
explain that this element needs to have an Alt text of "".
CS: if this were a spec review, what feedback would you give
JA: We are developing a document to make all the steps explicit
JW: Wendy and I have been discussing a document that tells you where the 
techniques will go. Some will be in Core Techniques and some will be in 
Technology-Specific documents. What someone does for an HTML image is 
different from what is done for SVG or for PDF.
WC: We will combine core techniques and the gateway to other techniques 
into a single document.
JW: Problem with 1.3 is that it expands into a unlimited list of 
requirements; every time someone develops a new XML-based language, there 
will be a new set of techniques needed.
GSW: On spoonfeeding developers - if we have a good enough document, they 
should be able to figure it out
JA: Testers don't know what the developers are doing or have as much 
knowledge of the technology
GSW: At the end of the day, it doesn't matter what technology was used but 
that the site is accessible
CS: Jenae is engaging in evangelism with the development group
WC: once people can see a concrete example of what we are talking about, they 
seem to be able to understand
WC: If we try to be comprehensive, we'll be here forever
CS: It sounds like what Jenae's organization is doing is what we expect 
organizations to do with WCAG, especially with the toolkit approach
JA: When the technology-dependent details are in place, do we think these 
success criteria are sufficient and testable?
CS: Yes, but we'll need to do some writing about what should be considered 
important.
PB: I have a question about distinguishing between hierarchical and 
non-hierarchical. Is there a clear differentiation? e.g. header for a 
table column, or a cross reference, can be hierarchical
KHS: I had the same thought
CS: Headings aren't related to their columns, except by placement
JM: Here's an example: in an html document, the relationship between a chunk 
of text and the image that is the alleged equivalent is non-hierarchical. How 
would that be expressed?
WC: Your first example makes sense as a hierarchy - even though HTML isn't 
a container model. But we have a problem with the second. Maybe we can 
say "relationship"? Hierarchical relationships and other relationships.
CS: There are some things you can't do in HTML, like have an H1 contain the 
paragraph
WC: Can we throw out "important"?
JW: Don't think "non-hierarchical" is a problem, since hierarchical and 
non-hierarchical cover the entire space of possibilities. Where is the problem?
WC: In the examples, maybe? Problems in second may be "Important", 
"non-hierarchical", and examples.
PB: This has less to do with HTML than the data model behind HTML. e.g., a 
cross-reference may be a subitem of a definition. 
JW: Can you take an action item to rewrite the examples
PB: I'll give it a shot
CS: Data model is ambiguous, since data model may be the underlying database
JW: Whatever the end user receives must satisfy the guidelines?
CS: That steps on the ability to do multiple optimized renderings
JW: Only if every rendering must satisfy all items. We can discuss this later
WC: I think we should attack the issues as they come up. One issue with this 
checkpoint is the definition of data model.
JW: What term was used in XML information set? (XML document categorizes 
the information contained in the document in case there isn't any markup; 
info may be accessible via APIs.) We want a definition that will cover that, 
and structured PDF.
WC: Was there a definition of data model in the glossary?
KHS: we talked about it, but it's still an open issue
CS": Do we want this to say "data model" or "other stuff that does the 
same thing as markup"
JW: we could say "information set"
PB: "content format"? "data format"
WC: should it document the relationships between elements of the content?
JW: Then someone will think they can document this in an accompanying document,
commenting on the document.
WC: What if we say "relationships are represented unambiguously in the markup
or ??"
JM: We should get back to having it capture the structure, rather than 
suggesting or implying the structure.
JW: If we try to list all the ways it can be done, this may exclude future 
solutions
WC: "content format" or "data store" or something like that
JW: who wants to think about this? 
Action item: PB, JW, CS

Checkpoint 1.4:
JW: Note, when we resolve the issue of "data model" in 1.3, we'll need to 
fix this language so it reflects the use of markup equivalents.
Consensus is that this seems testable.

Checkpoint 1.5:
JW: There is an open issue whether this checkpoint should be combined with 
checkpoint 1.3

Criterion 1 - seems testable; also seems similar to Checkpoint 1.3
JM: Could we at least put this checkpoint next to 1.3 (reordering these 
checkpoints).
JM: I think this should stand on its own, and not be folded in.

Criterion 2 - 
CS: Note past discussions about the difference between content and 
presentation; we have open issues to define these.
WC: Testing content vs structure is a problem.

CS: Rather than have separate data structures, maybe what we need is emphasis 
and relationship being available in visual format. Emphasis particularly. 
Perhaps that is more important than what the underlying data structures 
look like.
WC: Sounds similar to 3.2
CS: Make it so the things one normally does with visual presentation can be 
done with other kinds of presentation as well.
JW: If someone is using VoiceXML to provide an audio presentation, they need 
to have it stored in a form that isn't presentational. Not just confined to 
visual presentation. 
WC: Need media-dependent or device-dependent information available in the 
structure to be transformed?
CS: Emphasis should be accessible via structure
WC: I like Jason's wording - presentation 
CS: The three critical areas are reading order, relationships, and hierarchy.
This covers reading order, but also needs to cover emphasis. Suggest deleting 
criterion 2, since we don't really care about the underlying data structures
JW: Do we think anything can satisfy what we've been discussing without 
satisfying criterion 2
CS: Presentation could be attributes of logical structure.
JW: I would consider that satisfying 2, since the presentation info is 
separable from the structure
CS: Maybe I have a programmer-centric view of "data structure"
CS: Suggestion: cut off the sentence at "that is", and everything after it
CS takes action item to rework this success criterion

Checkpoint 2.1
CS: "One or more" doesn't seem the same as "multiple"
GV: There is always one mechanism for navigating a site
WC: This is measureable; but we aren't sure whether it means anything
GV: Originally this was to address cognitive issues, since different 
navigation mechanisms let people approach content in different ways
JM: We also need to dicuss the of level of complexity, since some sites are 
so simple that multiple navigation mechanisms don't make sense
CS: It seems like we are trying to say "use a site map"
WC: We are really saying more - site map, index, search engine
PB: Our site has 3000 pages - a complete map would be incomprehensible. Is a 
search engine a viable technique for people with cognitive disabilities?
JM: One can satisfy this in the letter, but violate the spirit
JW: Another way would be a hierarchical table of contents structure. We 
should list these known ways in these examples
JM: Suggest: delete "one or more" and "all or selected portions"
GV: A site with a home page and 5 other pages would violate this.
JW: We need to set some kind of complexity threshhold
GV: This should apply to any site where all pages can't be directly accessed 
from the home page, where there is a not a direct link from the home page.
JW: Here's a problem - suppose you have a long document in a single, large 
file. It has a Table of Contents, but doesn't include every subheading in 
the document. It's not an entire site, of course.
GV:  Single-page/document content never needs a site map. 
WC: I'm concerned about users with cognitive disabilities. There are sites 
that have hundreds of links on one page, and I can't find my way around 
such sites.
JA: But do these sites really have just one level? They are probably also deep.
PB: The User Agent can take care of search.
WC: If you know what you are looking for.
JW: One of Lisa's messages notes that there should be some upper limit of 
the number of choices available at any time.
WC: That would cover my problem.
CS: There is always design tension between "nothing should take more than 3 
clicks" and "don't make your menus too complicated"
GV: Unless the upper limit number is ~40, you can't divide things 
alphabetically
??: yahoo page has lots of links but is still very usable
GSW: If users don't have to think hard, they are willing to click lots of 
links
CS: It depends on what you are doing; portal page links get clicked lots 
more than secondary page links
GV: If limiting yourself to a small number of links makes it ambiguous where 
to search for your goal, that is less usable. 
CS: Different users have different needs, too.
Action item (who?): Look at Greg's wording for 2.1, criterion 1 
WC: Do we agree that either wording is testable?
GV: Need to check success criteria 
Proposal: Change criterion 2 to "navigation mechanisms are easy to locate"

Received on Thursday, 6 December 2001 21:11:53 UTC