Thoughts on 3.1 (Provide access to alternative content)

Here are some thoughts on the Guideline 3.1 (Provide access to 
alternative content) in the current draft 
(http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100105/).

1. Should check definition of alternative content to make sure it 
doesn't include on-demand things like definitions for words, raw HTML 
view, etc.

2. Re 3.1.1 (Notification of Alternative Content). I'm not sure the 
current definition of "notify" achieves the goal of this SC. For 
example, is it OK if the presence of alternative content is only 
indicated in the status bar when the user moves the focus to or selects 
that particular piece of rendered content?

3. In 3.1.2 (Configurable Default Rendering: Provide the user with the 
global option to set which type of alternative to render by default. If 
the alternative content has a different height and/or width, then the 
user agent will reflow the viewport. (Level A)) we should change "which 
type of alternative" to "which types of alternative content".

4. Re 3.1.3 (Browse and Render), it's obviously unfinished but I can't 
tell what it's going to be structured.

5. Re 3.1.4 (Available Programmatically: If an alternative is plain text 
(e.g., short text alternative), then it is available programmatically, 
even when not rendered. (Level A)),

5.a What is the purpose of this? Is it programmatic access, why isn't it 
under Guideline 2.1 (Facilitate programmatic access)?

5.b Why only when the alternative content is plain text? If there's an 
object whose alternative is an image, shouldn't the content of that 
image be available programmatically? Access to plain text is useful for 
screen readers and equivalent, but screen magnifiers could take 
advantage of a scalable version of the image if one is available, screen 
readers might want the pre-recorded audio equivalent of content, etc.

5.c We don't define "plain text". Presumably it includes text with 
markup tags, and in any character set?

6. Success criteria 3.1.2 (Configurable default renderings), 3.1.3.b 
(non-synchronized alternatives) and 3.1.5 (Rendering Alternative 
(Enhanced)) all include the clause "If the alternative content has a 
different height and/or width, then the user agent will reflow the 
viewport" or equivalent. I believe that there's value to the ability to 
NOT reflow the container, instead either truncating the alternative 
content or providing scrolling within its container. That option is 
necessary because some pages become unusable when reflowing changes the 
layout (e.g. things no longer line up correctly, obscuring their 
intended relationships). An example of a spreadsheet, where enlarging 
every cell to fit its contents (normal or alternative) could easily make 
the document quite unwieldy. See discussion of proposed 3.10.5 (Access 
to content outside viewport or container) and proposed new SC "Expand 
and scroll viewports" which Jeanne and I have been debating.

    Thanks,
    Greg