Comments on New (8/8) Techniques Working Draft

In general -- great job!  I found it much easier to navigate the document,
and relate the specific work items to the goals they achieve.  Some thoughts
on specific sections:

Checkpoint 1.4 - Does anyone know if Flash supports synchronizing captions?
Is there a flash expert on the WG?  Anyone know one we should try to
recruit?

Checkpoint 1.5 - text equivalents for client side image maps.  
A possible technique: can you hide the extra links with CSS, and provide an
accessibility stylesheet that unhides them?  Is there a good way to allow
user-selected stylesheets on a per-site basis?  This could be a very
powerful way to enable accessibility features for those who need them,
without changing the UI/Prettiness experience for those who don't.

Checkpoint 5.4
The HTML technique "tables for layout" doesn't provide any more info that
the checkpoint that linked to it.  HOW do you do this?  Needs some examples.

Checkpoint 6.3
[Ensure that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide
equivalent information on an alternative accessible page.]

Directly accessible scripts section:  THIS ROCKS!  I'm very happy to see
this info included.
We should add something about using keyboard shortcuts.  For example:  
<span onfocus="click(this)" onclick="dofoo()" tabindex="1"
accesskey="c"><u>C</u>lick here</span>
alt-c will trigger the click event.
You could also add this through script at runtime.  For example, put a
button on the page that registers focus handlers for all elements with click
handlers. 

Alternative pages:
Here are a couple of techniques for creating automatic server transfer to
alternative pages:

A lot of server-rendered already do "browser sniffing" to optimize for
particular client technology.  By adding an else clause to your sniffing
script, you ensure that any browser you don't recognize gets that version.
Many sites already have this else clause, but send a "get a new browser"
message.  Instead, write a version of the server rendering script that
renders the content in linear form with much simpler HTML, content moved
from script to html, etc.   This is also useful for supporting old browsers
in general.   

The above handles the case of a browser you don't recognize, but many (most?
all?) browsers don't send the script status to the server, so you can't tell
from server script if (for example) an IE 5 user has disabled script in the
browser.  One option for this case is to set a cookie on the client machine
so that the user would always be redirected to the alternate page, and
wouldn't have to follow a link to get there every time they went to your
site.  Cookies can be set from server script in response to a user
navigating to a URL, so this would work on a modern browser (cookie
supporting) with script disabled.  Obviously, you'd want to inform the user
that they were setting a cookie and have a way for them to unset it.

On sites that support personalization, the user preference for the
alternative version of the content can be just another personalized setting.

Similar approaches could be used to change css or xslt style sheets on the
server without user intervention.

checkpoint 10.2 [form labels] 
IE5 supports the <label for> tag.  It works great with win2k narrator, and
ok with Jaws.

Checkpoint 10.4 [empty controls]  
Are there still commonly used User Agents that have problems with this?  How
do we decide when an "until user agents" clause has been met?


CSS Techniques
technique # 3, units of measure:
What about the x-small, small, medium, large etc CSS font sizes?  I've found
that these are much easier to use than ems (ems are very large, and it's
difficult to get precise layout with them).  These work pretty much the same
way as <font size=n> tag in HTML, so they will be intuitive to authors used
to font tags.  They also resize when the font-size is changed in the browser
(I've tested this on IE4 and 5, and Netscape 4.7 on Windows).

Technique #11 Layout
Does anyone have an example of an accessible use of absolute positioning?
I've had a lot of trouble getting absolute positioning and resizable fonts
to play nice.  I think we might need to do some specific techniques and
examples for absolute positioning.

HTML Techniques
6.3 Keyboard access
Accesskey seems to only work on items that have a tabindex (hrefs and form
elements by default, but span, div etc only when tabindex is defined.)  Is
this behavior defined in the standards, or is this just an IE5
implementation detail?  We may want to note this somewhere.

Received on Thursday, 17 August 2000 17:46:58 UTC