CHARLES: What about mixed-case problems? Difficult for some users to process. Should this be a technique? Don't encode information in all-caps only.
GV: Device-independence issues.
IJ: Case not well-defined for all languages.
NO RESOLUTION.
Issue 1.) Bug-8. Note that is recently underwent a revision and therefore might be expected to require some editing. As noted, the reference to "synthesized speech" as requiring a "text equivalent" would not be comprehensible without further explanation.
RESOLVED: Delete reference to synthesized speech.
/* Eric Hansen joined here */
Issue 2.) Bug-9. Checkpoint 14.2 mistakenly makes reference to equivalents "to text". [Provide visual or auditory equivalents to text where they facilitate comprehension of the page.]
RESOLVED: Edit the checkpoint to read, "Supplement text with graphic or auditory presentations where they will facilitate comprehension of a page."
ALSO RESOLVED: Remove note about helping non-readers - it's too simplistic to try to communicate through symbols only. Remove the Note and discuss it in Techniques.
Issue 3.) Bug-10. The possibility of synchronizing text equivalents for video was not acknowledged in checkpoint 1.3 [For each movie, provide an auditory description of the video track and synchronize it with the audio track.]
Proposed resolution: This idea is in checkpoint 1.4 [For any time-based presentation (e.g., a movie, animation, or multimedia presentation), synchronize equivalent alternatives (e.g., captions or video descriptions) with the presentation.] However, since it seems completely redundant with a portion of 1.4 have we left out an idea or has 1.3 been misrepresented? The editors will compare an older version with the latest and if nothing has been left out, delete this checkpoint. Otherwise, bring a new proposal for the wording of 1.3 to the group on Thursday. 1.3 is about providing a description. 1.4 is about synchronization.
RESOLVED:
PROPOSED: Until most video player technologies can generate an audio description of the video track from a text equivalent (see checkpoint 1.1), provide an auditory description of the video track] (synchronized with the audio track as per [#Tsynchronize-equivalents])
Issue 4.) Bug-11. The word "visual" is used to describe non-text elements, even though text is usually rendered in a visual manner.
Proposed resolution: The editors will reread the document to ensure that visual is use appropriately, especially in regards to presenting text. If something earth shattering is revealed, the editors will bring it to the discussion on Thursday.
ACTION Editors: review the document for the use of the word visual.
Issue 5. Bug-12. The need for text equivalents for ASCII art was cited in two checkpoints (1.1 and 1.5). [1.1 - Provide a text equivalent for every non-text element. 1.5 - Replace ASCII art with an image or explain it.]
Proposed resolution: Delete checkpoint 1.5.
Jason: Sufficiently rare that doesn't warrent a checkpoint. Put it in techniques document.
RESOLVED:
Issue 6. Bug-13. The description of the relationship between the terms "assistive technology", "screen reader", and "user agent" is not consistent throughout the document.
Proposed resolution: The editors will reread the document to ensure that these terms are used consistently. If something earth shattering is revealed, the editors will bring it to the discussion on Thursday.
ACTION Editors: review the document for consistent use of theterms "assistive technology", "screen reader", and "user agent" .
Issue 7. Bug-14. The guidelines document does not claim a conformance level.
Proposed resolution: Add the following statement at the end of the Conformance section, "The <a href="#claim">conformance claim for this document</a> is located at the end of the document."
RESOLVED:
Proposal: Say "do not" instead of "avoid"
GV: "avoid" conveys meaning that there is an alternative. "do not use" does not.
EH: But "avoid" also implies "discretion". I tried to but I couldn't.
Examine each case:
NO RESOLUTION.
ISSUE: PRIORITY 2 for all tables for layout? (checkpoint 5.3)
IJ: W3C Home page works fine. Why priority 2 if my table degrades gracefully?
GV: If we have a table linearizer, would this drop to Priority 3?
WC: You could use frames (but this is probably more troublesome than tables).
Proposed: Do not use tables for layout unless they render logically when table markup is ignored.
Wendy: The GL used to say 'If you can't use style sheets, it's ok to use tables "until supported"'. 10.3 is problematic as well. It's not about "rendering". It's about getting at data cell-by-cell (e.g., navigation).
JW: Cell-by-cell navigation is still a significant nuisance - understanding the logical order of a document.
JW: If you don't use tables but you do use style sheets, other elements (e.g., P) will be used properly. Otherwise, if tables are used, TH is abused.
JW: Don't like confusing structure with tables for layout.
CMN: There are abuses that don't compromise accessibility. But that doesn't mean we shouldn't care.
PROPOSED: Priority 1: Any table used for layout must make sense when table markup is ignored. Make clear in note that this is an abuse of tables.
JW: If same markup is used for layout as for tabular information, and can't be automatically distinguished, user must go through manipulations to figure it out.
ACTION Ian: send proposal to re: tables for layout.