Thursday, March 28, 2024

Accessible JavaScripting From The Ground Up

As great as it is, JavaScript is probably one of the most commonly abused and overused technologies in web development. In this article, I hope to help you implement JavaScript without tears and guide you in the basics of good scripting practices.

The key point to get across when discussing accessible JavaScripting is that it is always the JavaScript that makes your documents inaccessible to begin with. I know that might sound strange, but it’ll soon start to make sense. An unlimited number of sites have very serious accessibility problems caused because they didn’t account for the large number of users who have JavaScript disabled in their web browsers.

Usually, the reason these sites get put up even though they have fatal design flaws is because the creators and/or owners of these sites don’t realize there’s a problem. They look over the work with their one and

only browser, and of course with JavaScript enabled, and they see that everything appears to function as they expected. Then it gets put online where it then festers until it gets replaced by some equally useless tag-soup abomination. If someone had have bothered to check the work in a browser with JavaScript disabled then all sorts of problems would have been apparent for all to see: navigation menus and even content vanishing without a trace being the most common and serious of problems.

The problem almost always comes from the original document itself being inaccessible. Then some JavaScript is added to provide vital elements–such as site navigation and document content–to complete the document and provide accessibility to the site and its contents. Here’s the most recent example of bad web design I’ve had the misfortune of encountering that becomes utterly useless without JavaScript (note that it is the absence of JavaScript here that is causing the problem). In general, it’s a pretty rough piece of work, but it still more-or-less gets the job done as long as JavaScript is available and enabled. On the other hand, If you don’t have JavaScript available or have the audacity to have JavaScript disabled (as I do until I white-list a site as safe to allow JavaScripts to run from that site), then it just turns into an entirely useless one-page-wonder that’s useful to neither people nor processes (such as search-engine indexing) because it’s left completely devoid of all site navigation.

A much better approach is to create your document in a standard fashion without any JavaScripting at all, then use JavaScript to replace the HTML-based menu with your all-singing, all-dancing, JavaScript-based super menu. This way, it’s the JavaScript that creates the menu, which doesn’t matter because it’s about to stick an alternative menu there anyway, and the HTML menu is accessible by default: no JavaScript — no missing menu problem!

It’s a pretty basic principle–but a very important one, because it’s applicable to almost every piece of your JavaScript that’s going to manipulate your document structure and content. Obviously not all applications of this principle will be quite as crucial as ensuring the availability of menu navigation and/or document content. That said, it does help to keep things looking a bit nicer and sometimes less confusing when applied to less vital elements of your document.

The sight of elements collapsing in on themselves because they have no content provided to them by JavaScript and thus ruining the layout of a document is seldom a pleasent one. Clicking on links several times before eventually realizing that they’re never going to do anything, or searching for the submit button to a form only to find there isn’t one because the form is supposed to be submitted by JavaScript once the user has chosen an option, will inevitably cause confusion that soon turns to frustration.

So in the case that you have a link that uses JavaScript for its href attribute, have JavaScript generate the entire <a> element so that if JavaScript is not present, the user isn’t left with a dud of a link. If you have a table filled entirely with data generated or retrieved by JavaScript, have JavaScript generate the entire table that contains the data too. If you must insist on removing the submit button of a form because JavaScript is annoyingly going to do it automatically, then have the submit button there in the HTML and then remove it with JavaScript. Some people like to call it graceful degradation; I just think of it as stopping for a second to use a bit of common sense and checking that the document makes sense with or without JavaScript. It only takes a second to stop and think about what you’re doing and it’s likely to have a significantly positive impact on your site’s accessibility.

Doing something as simple as sticking to (or at least attempting to stick to) a basic document template and one simple aim can help to reinforce the practice of implementing JavaScript with accessibility built in from the ground up. Take a look at the following document template.

<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
	<head>
		<title>Document Title</title>
		
		<meta http-equiv="Content-Type"        content="text/html; charset=utf-8">
		<meta http-equiv="Content-Style-Type"  content="text/css"                >
		<meta http-equiv="Content-Script-Type" content="text/JavaScript"         >
		
		<link rel="stylesheet" type="text/css" href="wherever.css">
		
		<script type="text/JavaScript" src="wherever.js"></script>
		
	</head>
	<body>
		<p> ... Document content ... </p>
	</body>
</html>]]>
	

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Popular Articles

Featured