Use of DOM for dynamic pages accessible?

[Stephen Philbin]

Hi folks. Just been siffing around the DOM tree to see what fruits it may bear and was struck by a most disconcerting thought. The javascript DOM API (I'm guessing that's the correct name which I should refer to it by) appears to be the only one capable of resizing elements and altering content after the page has been rendered. Personally I consider flash to look rather cheap and tacky, so I rather liked the idea of being able to use a standards compliant method of coding that would allow me to do such things with my pages. Then I got that horrible thought. If it's javascript based, then that would mean that it can not only be turned off, but would contravine accessibility laws and guidelines, would it not?

The thing I was rather looking foward to using the DOM for was to have several partial news stories listed and have the user be able to click the desired story and the column shrink to almost 0 height, then expand back to original height with the desired article now inside it. But if someone disables javascript, then it'd all go "a bit wrong" to say the least, am I right? Would a screen reader be able to use the DOM too? So that it could see the change in page content and read that to the user? or for every such page that implements the DOM in such a dependant role, would I have to make an entirely seperate page for accessibility?

It would seem such a waste to see such a potentially exciting part of web design get thrown out the window because it doesn't work with users with extra needs or have javascript disabled.

Anyone care to discuss or advise on the subject?

[Vladdy]

Browsers with JS disabled or not implemented, such as text browser, will certainly not able to recognize any JS commands.
The key to accessible scripting is making sure you are using JS to manipulate EXISTING content. In order to make your example accessible you have several options:
1. Simple but may not be optimal:
HTML page contains complete text of all articles that can be seen by those with JS disabled. Using the page onload event, you add an element after the first/second paragraph of each article that says "Read the rest" and use its onclick event to show/hide the rest of the article.

2. More complicated, but reduces bandwidth:
HTML page contains first few paragraphs of each article with the link to a separate page representing complete article at the end. That becomes the default behaviour for JS disabled browsers. When JS is enabled you use bode onload event to replace those links with an element that is consequently used to show/hide the rest of the content and then upload the rest of the content in the background.

[Stephen Philbin]

Ah some good ieas. Thanks for the suggestions man. I think I'd better give both a test to see which one would work out best in the end really. I still want each story to be able to be bookmarked by URI too which I would imagine is going to cause me a considerable amount of trouble too. I think I've got enough to get started and experiment around a bit first though.

[David Harrison]

When making a DOM script like that, you have to lay down the basic HTML first then build the script on top of it.

Take this for example, I made it for someone on the forums a while ago. The HTML is pretty simple but then with the aid of some onclick commands and some nifty DOM-ing, a thumbnail viewer is created (not too dis-similar to the preview article viewer you're after).

[toicontien]

You may be interested in the following A List Apart article: Let Them Eat Cake (http://www.alistapart.com/articles/eatcake/)