Re: javascript accessibility

On 23/4/04 9:24 am, "Jens Meiert" <jens.meiert@erde3.com> wrote:

>> I don't entirely agree with this. I view JavaScript as a
>> means to provide convenience rather than exclusive function.
> 
> It's not convenient to write out parts of a document if they are crucial but
> not present for UAs being not capable of or not using JS. It's bad coding
> style, too.
> 

I agree that writing actual content with JS is a heinous crime, but as a
tool to provide a convenience I think it is most valid. I meant of course
convenience to the user in terms of the sophistication of the site widgets.

>> However one of the most accessible ways I know to do it is
>> have JavaScript generate the elements which are providing
>> that functionality.
> 
> It's a difference whether you /generate/ them (elements) or whether you
> /hide/ them until a specific event occurs (e.g., via CSS). The latter is
> more elegant (though not inevitably good), so I disagree. (My conclusion is
> a bit global, but generally applies.)
> 

It depends on the context, I am writing a script for the techniques
submission form which will hide elements which in a drop down menu according
to a selection from a previous menu. However in the mark-up all the items
exist for all users because everyone needs to see them, with JS enabled or
not.

However if you have some functionality which JS can do without a page
reload, then I think it is reasonable to use that (such as saving using
WebDav to talk to the server in a browser WYSIWYG editor). As long as, of
course, the functionality is still available to all users via a server
mechanism.


>> For example if you have a button which links to
>> javascript.this.print(); then if it is also generated with
>> JavaScript only the people able to use it will have it
>> included in their content.
> 
> Well, if you use JS to offer functionality only available with JS, it might
> be okay (if you really limit your scripting efforts to this specific action
> and don't 'generate' all buttons with JS, for example). By the way, this
> example 'limps' since you seem to copy browser functionality.
> 

I think it is more than okay, I think it is extremely important to not show
users navigation or page controls they can't use. As for a limping example,
I think my point was any JS used on a page should be duplicate, either from
the browser or the server.

>> In this way I think it is
>> extremely valid to provide redundant or more convenient
>> functionality which is also provided by some other server
>> or user agent function.
> 
> I disagree. It might be pretty convenient if you can print a document
> pressing one of fifty buttons available in a document, but hence, what do
> you print? (I exaggerate, I know.) -- And 'valid' are many approaches in Web
> development (though not most right now), but that doesn't mean they are
> useful or reasonable.
> 

Implying that using JS is the same as bad UI design is silly. Having an icon
which simplifies people's model of site interactions (such as the very
common action of printing) is a good thing, at least if it is used site wide
(I work with content management systems).

You can create bad usability (and are probably more likely to in some areas)
with the minimal available tools in plain HTML. An example being overly long
line lengths for reading without using max-width in CSS. Adding widgets and
features which makes sites rich in interaction is not a bad thing, it just
needs to be done properly.

Regards,

Tom Croucher
Research Assistant
University of Sunderland

Received on Friday, 23 April 2004 07:39:14 UTC