Heal Your Church WebSite


Teaching, rebuking, correcting & training in righteous web design.

Using PHP to aid in accessibility issues

In case you didn’t notice, the new RBC site employs tableless design. One of the original objectives of slugging it out this way was to make it more accessible to text-only browsers such as Lynx, while degrading with relative sanity to fossilized dino-browsers such as Netscape 4.78. Of the later, good success, though there is are one or two color issues I still need to manage. Of the former, not so good.

Because of the multiple, redundant and generally copious navigation I employed, because I choose to run navigation across the top as well as to the left … as opposed to the right column, someone viewing the page with Lynx is going to have to scroll through quite a bit of navigation before getting to the compelling content. And as Mark Pilgrim said on day 10 of Dive Into Accessibility, and I quote, “Scrolling sucks.

As a result, I’ve employed a stop-gap measure as suggested by Mr. Pilgrim on Day 11: Skipping over navigation links. That is, I have a hyperlink that is visible to browsers that don’t do CSS, such as Lynx. This link allows viewers to jump to an anchor tag on the page placed just above the content section. Still, this solution bothered me.

PHP to the rescue. As I explained in an email recently, using PHP for your output with MT gives you the best of both worlds. You get the massive text processing power of Perl to build static pages. Static pages that can then take advantage of the incredible server-side scripting capabilities offered by PHP. The downside is it means having to learn two languages. If that is a problem, I would suggest perhaps implementing Brad Choate’s MTPerlScript plug-in.

The point is, whatever your preferred programming poison, if your server-side scripting language gives you the ability determine the user browser, then with a minimal amount of code you can at least comment out stuff that only gets in the way of your text-only browser buddies. Here are two examples of what I mean via Delorie’s Lynx Viewer Page.

  1. the (OLD) About Us :: Overview page without any PHP processing for the Lynx Browser
  2. a Test Page WITH PHP processing to comment out copious, redundant navigation blocks

Now obviously, I need to create just a bit more PHP to include sectional/category navigation for Lynx users, but then again, I also need to consolidate a recent spate of PHP programming I’ve been adding to my pages. None-the-less, it’s nice to share and so here is how is what I did on my test page. First, at the top of my page, I declare some global variables and some functions I’ll use throughout the page.

Remember, it is good programming practice to assign once instead of evaluating often. In other words, regular expressions are more expensive to process than evaluating a boolean variable for TRUE or FALSE values. In this case, I create a variable named $GLB_isLynx which is the result of a regular expression evaluation of the $HTTP_USER_AGENT environment variable. I then create two functions, one to start a comment tag, the other to end:

<?php
$GLB_isLynx = eregi(“^lynx”, $HTTP_USER_AGENT);
function SCOM() { global $GLB_isLynx; if($GLB_isLynx) { echo “\n<!– \n”;} }
function ECOM() { global $GLB_isLynx; if($GLB_isLynx) { echo “\n –>\n”; } }
?>

I suppose I could have used PHP’s get_browser() function instead of evaluating $HTTP_USER_AGENT. Then again I suppose I could have just created two more globals to represent as string variables SCOM and ECOM. But remember, I’m going to need to put some alternative navigation in my code, so in my case, a function works better. That and I can later expand the function will allow me to pass a variable of which block I’m commenting out so I can get behavior specific to a section.

The rest is easy. I go through the code and encapsulate your blocks as needed. For example, here is how I keep the search form from showing up in Lynx:

<?php SCOM() ?>
<form class=”frm” method=”get” action=”/mt-search.cgi”>
<label for=”search” accesskey=”4″>Search this site:</label>
<input id=”search” name=”search” size=”16″ />
<input type=”submit” value=”Search” />
</form>
<?php ECOM() ?>

I know, I know, so much geek stuff lately and not enough site reviews. And not like I don’t have a whole stack of them waiting … which I do. Heck, I still owe Andrew Carreaga some stuff (yo ‘A.C., I didn’t forget). That said, hang in there while I finish up healing the Redland site. After all, who wants advice from a guy who doesn’t practice what they preach?

Now it’s your turn. Have you viewed your site in Lynx? Do you use or know of any other text-based browsers I should add to my simple PHP code block? If so, leave a comment.

5 Comments

  1. I’ve been reading the site for a while, but this is the first time I felt strongly enough to write. I’m working on a rewrite of a church website right now and have been learning about CSS and accessibility issues lately.

    Please do not do user agent sniffing. What happens if a few years down the road there’s a new version of lynx that parses css and chooses to handle positioning? As a new Safari user, I occasionally get hit by websites that do user agent sniffing and refuse my browser even though the site works fine if I fake the user agent string.

    The alternative is to place your header and navbar below the main body of the page. In your stylesheet absolutely position them to the top and place wide enough margins on the body to accommodate them. That’s how I’m planning to handle my new site.

    Oh, and here’s a stylesheet I found that can approximate how lynx will display http://www.w3.org/Talks/2001/0507-CSS-Sydney/lynx.css

  2. I know it will probably mean you have to go and recode a whole bunch of stuff (I assume you have templates though), but I’d have to agree with Greg on that one, sniffing for user agents is not the answer. Even I have developed sites in the past that are now coming back to bite me in the backside because I was to specific about what user agents I wanted to see my site.

    Anyhow, I know there is another Lynx clone called ‘Links’, but I can’t recall what the user agent string is for it…

    Opera 7 also does a good impression of text-browsers with its custom stylesheet feature.

  3. Thanks for not forgetting me! I’m hangin’, I’m hangin’!

    Andrew

  4. I think it’s extremely useful to make your page friendly to text-based browsers. Their is nothing more frustrating than having only a text-based browser and coming to a page with no “alt” tags, no navigation system that doesn’t rely on javascript, and nothing but images for their site content.

    Other browsers you might want to sniff for are links and w3m. You might consider using the Net_UserAgent_Detect PEAR class which would simplify determining if a browser is text-based and has certain capabilities.

  5. Question: Who still uses text-only browsers? And why in the world would you want to?

    I’m all for compatibility and all, but I’m inclined to say grow up and get a real browser when you start talking text-only browsers.

    Then again it may be because of the purpose of my site. My site produces Christian videos you can watch for free online. I guess there would be no point to visit my website with a text-only browsers. My content isn’t text.