[Mailman-Developers] Accessible DOM manipulations

[emf]

Brad Knowles wrote:

> I would much prefer to do this without JavaScript.  Because you can't
> guarantee that you know the way that page would be rendered

Can you help me understand the basis for this claim? I have looked into 
the matter somewhat deeply and this works in every browser I have come 
across that supports JavaScript:

document.getElementById('foo').style.display = 'none';

An intelligent layout allows you to minimize the amount of page 
rejiggering that goes on when you display text.

Visual tests using Greasemonkey allow you to see all the visual states a 
page can get in (including different sized displays) to ensure you don't 
get into an unpleasant corner.

Perhaps you mean to say that the variety of CSS implementations prevents 
me from knowing how a UA will render the page. Strictly speaking, this 
is true; pragmatically speaking, there exists suitable CSS that works in 
all current browsers that I know of.

> if you send
> all sorts of "hidden" text that isn't shown until such time as someone
> does something to make it appear,

The document with all the hidden text shown will be something like a 
"full detail" view; after all, I've promised the page will work fine 
with JavaScript off.

> and you can't control what kinds of
> mailicious cross-scripting attacks people may throw at you,

I am unaware of any cross site scripting (XSS) attacks that can occur 
when a linked-in stylesheet uses the event model to alter the style of a 
element.

Perhaps you are referring to the approach of using some mechanism 
(XMLHttpRequest or naive furl() type stuff) to fetch new bits to go into 
a page. This definitely a risk, and one I'm disinterested in playing with.

I intend to use XMLHttpRequest to fetch JSON messages like "preferences 
saved" from the server. These messages will be carefully scrubbed and 
come only from server-generated translations, rendering them an 
improbable source of XSS.

I also intend to use it for one-way communication where the client 
informs the server that something has changed via JSON. As with all form 
submissions, each JSON submission will have to come with the appropriate 
hashcash-esque validation element to be considered to come from the user.

The UI benefit that drives the above choice is that I can provide the 
user with the UI state of the web app at the last time they used it, no 
matter what machine they come from.

> it's best to simply not send anything that the user cannot currently see.

I'm not sure I understand this principle.

Most people have internet bandwidth that is inferior to the rendering 
speed of their browser, and a monitor that is smaller than most page 
content; some people (like those using screen readers) have essentially 
a 2d/linear monitor.

This suggests that sending fewer, "larger" chunks is preferable to 
sending many smaller chunks when the user will be aware of the load 
time. The way modern rendering engines work makes 'hidden' text *much* 
faster to load during initial page rendering than it would if it were 
all displayed.

One use case is where the new user clicks on all the help buttons to 
learn what's going on; a delay rendering help increases exploration cost.

Another one is the way people read on the web. Nielsen [1] and many 
others in the usability field have shown that people scan, looking for 
key words, rather than reading. The fewer words the shorter the seek 
time and the more likely the user will do an exhaustive search of the 
page for what they're looking for.

[1] http://www.useit.com/alertbox/9710a.html

When it comes to screen readers, text *is* space; sighted individuals 
can skip big swaths of text with a single saccade, but a blind user must 
give voice to enough of the text to hear where they're going.

This makes scanning text both temporally and cognitively more expensive 
than it is for sighted users.

As screen readers *do* respect hidden/shown elements, I can 
significantly improve the user experience for them, while making life 
easier for visual uses as well.

On somewhat of a side note, I have heard a certain amount of antipathy 
towards JavaScript in this forum. I know it was unpleasant in the late 
'90s, but it is much better and more cross-browser these days.

I'm fairly certain that *some* author-initiated manipulation of a user's 
experience of a node set is obligatory in any conceivable Web; the only 
alternative I can see to using JavaScript or another interpreted 
language would be using something like XSLT, a horror that I shrink from 
even contemplating.

~ethan fremen