homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / WebmasterWorld / Accessibility and Usability
Forum Library, Charter, Moderators: ergophobe

Accessibility and Usability Forum

Simple Accessibility Tricks
Four Easy Accessibility Practices

 1:27 pm on Jul 24, 2007 (gmt 0)

I have a site I'm developing. In the past, I have always eschewed most of the "leading edge" tech in favor of tech that will degrade to older/less capable browsers.

However, recent -dare I say it?- Web 2.0 advancements have raised the bar on usability. In particular, the Google Maps API [google.com] is a wonder.

Okay, so for the new site, I am going to pull out the stops. XSLT/DHTML/AJAX etc. It is running very well. It has increased the usability of our site by a huge degree.

Not so accessibility or degrading to older tech. I often say that the single biggest thing that you can do to improve accessibility is to support older browsers.

Now, it's important to me to put code in to help degrade well.

I have given up on small files. I do my best to keep things efficient, but page size is no longer the #1 driving factor. Usability is #1. Accessibility is #2, and page size is #3. In order to support older browsers, #3 should be closer to #1, but I can't cripple the site for the 5% of users that will hit it with IE5.5/Win98, or IE5.2/MacOS 9. IE6/XP is my big target.

I don't have much trouble with CSS, as long as I keep it fairly mainline CSS 2.

That covers the basic philosophy of the new site. Bells and Whistles oh boy, but qualified bells and whistles.

Now, the tricks:

TRICK #1: Using <noscript> and JavaScript to segregate a <form>.

I have a <form> that has a fancy DHTML set of popup menus that update incestuously (in this case, you select a county, and the towns popup populates to towns in that county).

Of course, if you have no JavaScript, this set of popups won't work, and you need to present an alternative set that won't be quite as slick (I haven't written it yet, but it will be a big-ass popup with a long list of all the counties and towns -yuck).

So, how do you present this alternative?

<noscript>, of course.

But the problem is that the useless DHTML popups will also be displayed, delivering an awkward user experience.

We may be optimized towards fancy browsers, but we don't hate our non-JavaScript users. We are happy to have them here, and we need to show them.

Here's how I get this:

<div id="javascript_stuff"
...fancy stuff...
...non-fancy stuff...
<script type="text/javascript">

TRICK #2: Seed Text

A good accessibility best practice is to "seed" a text input with text, such as "Enter Search Text". The onclick handler removes this, as well as onfocus and onblur. onkeydown is also used, although I don't know if I need it with onfocus. Here's an example (dumbed down to make it easier to understand):

<input type="text" name="text_input" id="text_input" value="Enter Text" onclick="if(this.value=='Enter Text')this.value=''" onfocus="if(this.value=='Enter Text')this.value=''"
onkeydown="if(this.value=='Enter Text')this.value=''" onblur="if(this.value=='')this.value='Enter Text'" />

The <form> onsubmit handler will check to see if the contents are "Enter Text", and will not submit if so.

The problem with this, is that it you don't have JavaScript, then you have a text input with valid text in it. The <form> onsubmit handler doesn't get triggered, so you can accidentally search for "Enter Text".

It's very easy to fix. Thusly:

<input type="text" name="text_input" id="text_input"
value="" onclick="if(this.value=='Enter Text')this.value=''" onfocus="if(this.value=='Enter Text')this.value=''"
onkeydown="if(this.value=='Enter Text')this.value=''" onblur="if(this.value=='')this.value='Enter Text'" />
<script type="text/javascript">
document.getElementById('text_input').value='Enter Text';

TRICK #3: Using Session Cookies to Tell the Server About the Client

One of the nice things about JavaScript is that it knows all about the client environment. The server, however, is bereft of clues. There's all kinds of code written for servers to read tea leaves to find out about the client.

I won't give demo code here, as it would be too restricting.

Simply declare a session cookie using JavaScript in one of the site landing pages that puts together client information. The server can view this information at its leisure, and use this information to craft its output.

TRICK #4: <noscript> Buttons

This is simple. Many <form> elements are designed so that doing something like selecting a new popup value submits the form.

The problem is that the submit is a JavaScript process, so scriptless browsers are kinda screwed.

Here's how you can deal with that:

<select name="my_switch" onchange="this.form.submit()">
<option selected="selected">Select One</option>
<option value="1">First One</option>
<option value="2">Second One</option>
<noscript><input type="submit" value="GO" /></noscript>

None of these are perfect techniques. A truly determined user can hit the site with NN4 and see a work of cubist wonder, or a Lynx user can be cheesed off at it (I suspect Lynx users spend a great deal of time griping about "kids these days, with all them durn graphics and whatnot.")

They just help, and they are easy. Little things like this can make big differences.



 3:46 pm on Jul 24, 2007 (gmt 0)

I usually use the noscript just on the form tag itself and use js to write its own form tag.

Then use trick #4 when there's a select in the form.


 3:51 pm on Jul 24, 2007 (gmt 0)

Excellent post!

I am so glad that your post has taken the approach it has, and not what I was afraid of finding when I read the "featured thread" subtitle with regards to supporting old browsers.

What you have posted above is exactly the way of dealing with old or unknown useragents -- make sure things degrade well.

Way too often (especially in the JavaScript forum) I see people pull their hair out trying to get a particular script to work in an old browser. Hey, if the browser is really old, chances are that a very very limited number of your visitors will be using it. In these cases, making sure the fancy functionality works is really not worth it. Instead, provide an alternative way of accessing the information, or make sure that your fancy stuff degrades well and/or is usable without access to "fancy" stuff like JavaScript.

Now, if I may ... there is but one problem with one of the accessibility tricks -- combining display: none with <noscript> may very well result in a screen reader presenting both sets of content to its user! In cases where I have fancy functionality depending on JavaScript to work as intended (and where non-fancy stuff is included by means of <noscript>) I tend to not opt for hiding the contents using display: none. Instead, I write the fancy contents completely using JavaScript -- either by means of innerHTML or by modifying the DOM.

Just something to think about.


 5:34 pm on Jul 24, 2007 (gmt 0)

Instead, I write the fancy contents completely using JavaScript -- either by means of innerHTML or by modifying the DOM.

Thanks for the kudos!

Each of these approaches has some drawbacks. Usually ones that are fairly obvious.

This was something I used to worry about, but it seems that using fancy CSS display tricks may be the best way to accomplish what I want. Apparently, screen readers honor display: none and apparently not. [webmasterworld.com] You just can't win. I would think, that, with all the Web 2.0 stuff out there, screen readers are JavaScript-aware, and they will execute DOM construction.

Bernard Marx

 5:41 pm on Jul 24, 2007 (gmt 0)

I don't know whether this part is an opinion or a question.

I have heard tell of the use of proxies in corporate environment that disable scripting by stripping out script from responses from the internet. If such scenarios do indeed occur (that's the question, btw) then the content of NOSCRIPT won't be displayed - since the browser itself is script-enabled.


Most cases of conditional display (Tricks #1 and #4, say) can be accomplished by the judicious use of contextual CSS selectors:

.isScript #myElm{display:none;}
/* ...and all other display specs for elements */

Then in the script file of your choosing:

document.getElementsByTagName("html")[0].className = "isScript";

The hiding/display of elements has been decided before they even are parsed.

This way, there's no need to litter the document with little script blocks directly after sections that need to be hidden/displayed if script-enabled. Equally, one can do away with NOSCRIPT blocks too, because the logic can work both ways.


 5:44 pm on Jul 24, 2007 (gmt 0)

That's a good trick!

One thing that I've wanted to do is be able to detect screenreaders [webmasterworld.com].

As I suggested, I'll lay odds they can render JavaScript, so I can't depend on <noscript>. Your trick would work for that, if I can detect the $#@! screen reader.

Bernard Marx

 6:25 pm on Jul 24, 2007 (gmt 0)

@media aural {
... something smart ..

Can this have any uses?
Hide/display, of course, but it also provides a way for script to find out if active.


 6:51 pm on Jul 24, 2007 (gmt 0)

@media aural {
... something smart ..

There was some discussion of this. I'll have to experiment. One issue is that I don't have access to screen reader software, so I rely on hearsay a lot. I know that there is a time-bombed demo of JAWS, but I'm waiting until the site has been developed further before I start the ticking.

We had an issue detecting a print rendering (I don't remember the thread well enough to call it up, but someone wanted to change content, based upon its being read for printing).

I think the consensus was that it can't really be done. I don't know if this would be bound by the same restrictions.


 8:08 pm on Jul 24, 2007 (gmt 0)

What about display:none and considerations of search engine spammer/black-hat detecting algorithms?


 8:27 pm on Jul 24, 2007 (gmt 0)

What about display:none and considerations of search engine spammer/black-hat detecting algorithms?

Good question. I haven't a clue. Maybe you can share your opinions on the matter? I don't really wory too much about these types of things.

I use display:none in a comment spam filtering thingy, but that's pretty much it.

I'm just thrilled to death that we're even having this conversation, let alone it being above the fold. The A&U Forum [webmasterworld.com] tends to be a bit quiet, and I think that this is important stuff. From an SEO standpoint, I have it on good authority [webmasterworld.com] that good accessibility==good PR.


 8:39 pm on Jul 24, 2007 (gmt 0)

Maybe you can share your opinions on the matter?

I apologize for the brevity of my previous comment. One should never write comments when being in a bad mood.

My opinion is that I welcome that search engines try to detect black hat practices, but that I am worried some pretty valid and good techniques might be seen as black hat by a fully automated process. I myself use - rather successfully - a combination of display:none and JavaScript to prevent spam harvesters from prying email addresses from my sites. So basically each and every page has one instance of display:none in a JS context on it.

However I never liked it, but I am lacking a better tool for that purpose. My sites and pages do good in the major SE's though, so obviously using that technique did not raise a black-hat flag, or at least did not push me past the threshold. But I don't know what multiple display:none instances might cause.

On the other hand display:none is a pretty old black hat technique. I'm sure there's more sophisticated ways today, so maybe the SE's are a bit more lenient with it nowadays? But then again - what better to stop wannabe black hats dead in their tracks as to severly punish the oldest tricks in the repertoire?


 8:45 pm on Jul 24, 2007 (gmt 0)

That's a good consideration, and thanks for bringing it up. It won't make much difference in my own work, as I do fairly obscure sites that don't really care about SEO. However, this is definitely something others who know more than I can address.


 10:58 pm on Jul 24, 2007 (gmt 0)

in my experience the unique content outweights display:none issue.

we use external CSS(display:none as a div class) and JS(onmouseover) to display Product IMAGES as well as specifics about a particular product(again unique to every product) = no problems at all, over 200+ distinct pages rank for long tail keyword combinations as #1(Google and MSN, Yahoo is getting there, but man they are so polluted that I don't mind it at all)

if browser does not support JS they get to see first image of the product, NO CSS the info is displayed as a long column.

I think that the people that are using screen readers are aware of this issues for a while now and don't mind it at all as long as they get the "meaty" stuff. If I reading the numbers correctly here 90% of people use browsers that are NONE screen readers, then out of that 10% that is left get to deal with the 90% of the websites that are none SCREEN READER Compliant, if you will….


 10:30 am on Jul 25, 2007 (gmt 0)

I was also thinking about this last night, as I was working on the DHTML content for this site.

display:none is used EVERYWHERE. It's the secret sauce behind a lot of JS flyout menus, and many DHTML techniques rely upon it.

I don't see how it could be a useful consideration in PR calculations.

Global Options:
 top home search open messages active posts  

Home / Forums Index / WebmasterWorld / Accessibility and Usability
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved