"Jim Ley" <jim@jibbering.com> wrote in message
news:3f101358.182836154@news.cis.dfn.de...[color=blue][color=green]
>>I have often wondered how an aural browser would implement
>>the dynamic DOM level 2 interfaces (createElement, appendChild,
>>and so on). What should it do if a text node was inserted?
>>Suddenly blurt out the text, start reading the document
>>again from the beginning or ignore the insertion?[/color]
>
>I think it should ignore the insertion unless it happens to
>be reading that element, consider a form where you insert text
>to indicate that a field might have been incorrectly filled
>out an ("are you really 70ft tall?" say) will allow the user
>if reviewing the form to hear the indication.[/color]
It occurred to me that the aural browser could announce the change in
the document ("a script has modified the document" or something). It
would have to know that the inserted node would modify the text but
might be able to offer the user the opportunity to re-read just the
containing element or one of its ancestors to provide context without
having to start afresh from the beginning. That would only sensibly
apply if the affected elements had already bean read, and interrupting
its current output mid-paragraph would not be a good idea.
In the event of a form submission being aborted by a validation script
the user is still going to have to be told that it has happened in order
to know to go and review the form. Clearly implementing JavaScript in
aural browsers is something that needs a lot of thought (and input from
the people on the receiving end. If clean degradation was common
practice (rather than just recommended) they might decide it wasn't
worth the bother).
[color=blue]
>I generally believe though that there's no reason to generate
>content with script, just to move it around, the above style
>of messages (what misguided people generally use alert for)
>is the generally the only time it's appropriate.[/color]
To stand a chance at cleanly degrading the content must be in the HTML
and not the JavaScript. That became self evident as soon as I took on
board the need to consider every aspect of a script including its total
failure. I deeply regret all of the scripts that I wrote before I knew
any better, If I had known then ... [etc] I would have been able to do a
good job of them instead of just doing what I was asked to do. Still,
the only way to avoid the regret would be to never learn anything new,
and at least I now don't have to repeat my past mistakes (just spot my
new ones :).
[color=blue][color=green]
>>My strategy is to have an external CSS provide most of
>>the styling for the ULs but to use JavaScript in the HEAD
>>of the page to write out a STYLE section that introduces the
>>critical CSS. Obviously in the absence of JavaScript the ULs
>>retain their externally specified (or default) display
>>characteristics so clean degradation is achieved.[/color]
>
>Risky, since you're rendering the content invisible with CSS,
>before you've checked you've got the ability to render it
>visible again with javascript.[/color]
I realise that it is risky and needs very cautions handling. I never did
intend to write out display:none; or visibility:hidden; at that point
(really a job for onload). Mainly I was thinking of position:absolute;
as there are browsers that do not facilitate setting that onload and
less dynamic browsers like Opera <= 6 won't re-flow the rest of he
contents if you switch the position properties. However:-
[color=blue]
>Have you seen my (now very old) approach?
>
http://jibbering.com/accessibility/[/color]
I had looked at your menu script before but that was a timely reminder
because I was just not thinking of putting the menu HTML in any other
place but the top of the page. But if I follow your example and pace the
menu HTML after the contents it will not be important if the rest of the
content does not re-low when the position = 'absolute' settings are
made, as a bit of blank space at the foot of the page on a few browsers
is not a high price to pay in exchange for the extra safety. That leaves
the only reason for writing out a STYLE tag as an attempt to support
dinosaur browsers like Netscape 4 and I wasn't convinced that was worth
all of the extra code and branching if the page can be navigable under
any circumstances.
I also really like the link to the same page with a query string to give
the user the option of disabling the menu themselves. That is such a
good idea that it would be stupid not to use it. It might also prove the
only answer to the point that David raised about screen readers working
with IE.
Richard.
