As most of my readers know, one of the things I do is make themes and templates for WordPress web logs and stand-alone sites. The themes and templates I make are accessible, universal, standards-compliant, and strictly valid. I take a lot of pride in what I produce and I try to turn out nothing but the highest quality stuff. Once users download the fruits of my labor, my responsibility of quality control ends and the users take the reigns. That’s when things sometimes go awry. But in many instances, it’s not the users’ fault.
Can’t Blame the Users
Users don’t purposely try to destroy the quality of what I produce, but in the process of adding third-party code snippets, add-ons, and plugins, things can sometimes get pretty messy. As I wrote, it’s not the users’ fault per se, they trust the code they get from the various providers, the weak link is that the code they download and install per the instructions, in a word, sucks.
Time to Make it Right
This is a request to anyone who provides code snippets, plugins, widgets, or add-ons on the web. This would include anyone who provides plug-and-play code to the general user. It’s time to update, to upgrade, to get with the program, and pull your head out of your… [Pop!]. This has been brewing for a while and this is, well, a rant. I’m tired of it and a bit frustrated. One careless coder pumping out nothing more than a few lines of code can adversely affect thousands of sites and make thousands of combined hours of extra work for developers committed to doing things right. A few minutes of extra effort on the part of the original producer is all it takes to get it right, yet, for some reason, it seems that’s asking too much.
The Back-Breaking Straw
As I noted this has been brewing for a while. What pushed me over the edge, so to speak, was a adding PayPal order form to a soon-to-launch blog I’ve been working on recently. The site owner generated the form code (or regurgitated might be more apt) at the PayPal site and sent it to me by email. As soon as I saw it I was shocked by the poor quality. It was a form that was going to be installed on an Extensible HyperText Markup Language (XHTML) site, yet it was only provided as loose HyperText Markup Language (HTML). I had to fix that. Additionally, it had no fieldset, no legend, no closing tags (as required by XHTML), no labels, even a deprecated inline attribute (
border="0"). Oh, and it was laid out with included table markup. I was stunned, but being it was something I was installing on one of my projects I was obligated to fix it. I made it accessible and valid. I recognized it for the garbage it was, and being that I know this stuff, I was able to make it right. But it’s something I shouldn’t have had to do.
What PayPal Doesn’t Know
The form markup from PayPal came with select options (a pull down) so buyers could select a quantity. The options were left open,
<option value="1">1, which is fine with HTML but not XHTML. I fixed that by closing them:
<option value="1">1</option>. This made it valid, but the quantity didn’t work. I didn’t know why so the client asked PayPal tech support. They got back to him quickly and stated “the options can’t be closed” as I did and went on to explain that the code must be inserted “exactly as is produced on their site.” What?! I knew that was an inaccurate response. For troubleshooting purposes I pasted the generated code and it didn’t work either, as I suspected. I dug into it to find the real cause. I determined the quantity didn’t work because an incorrect name attribute was supplied. They had
name="on0" and it needed to be
name="qty". Once I did that the form was accessible, valid, and proper, and amazingly it worked.
Different Flavors of Markup
It bugs me that even though there’s a ton of XHTML web sites on the web, most providers only offer their code in one flavor: typically just HTML. Why? How hard would it be to offer it in both X and HTML? Are they afraid they’re going to confuse people? That’s probably it, but I see that as a weak excuse at best. People running web sites need to learn what document type is being declared. And if PayPal or whoever doesn’t want to confuse them, then they should attempt to explain the difference — or at least show how site owners can tell so they know which code block to choose. I typically offer my stuff in multiple flavors so users can choose the right thing. For example, my contact form script has a variable in the configuration that totally changes the form’s elements to be valid with either mark-up language used. Doing this allows people to be valid and proper, without them having to dig into the code to make it right. One small effort on my part equates to huge benefits Internet wide.
Other Way-Too-Common Problems
I’m not trying to pick on PayPal. I see all sort of problems out there and I’m done naming names. Forms just happen to be one I see often and this PayPal issue was a lot harder than it should be for a copy-and-paste bit of code. It was aggravating. Aside from forms missing their elements, here are some other issues I see a lot:
- Please no border="0"
- As I mentioned previously, the form’s submit image had the border attribute. This doesn’t make me want to party like it’s 1999, but it reminiscent of that era. Style sheets rule and they’re all over the web. If the style sheet removes the linked image border then it doesn’t need any help from that attribute. And it probably does remove the border as that’s most common, but if it doesn’t, maybe the web site’s owner wants it that way. Same thing applies to all sorts of code blocks that contain imagery. Stop using the border attribute.
- Really old font-color="gray"
- Like I just wrote, let the style sheet do the work. Font tags are deprecated. Stop using them. If you want to be helpful — which is apparently the case since you’re tying to color my text — please do it by providing a class or put your script in ID’d container that I can refer to or inherit from. Also, since this might be for people who don’t know this stuff, provide an explanation and some example styles.
- Save a tree, ditch a data table
- Want to do your part to save planet Earth? Help the environment by not cutting down trees to make a bunch of worthless tables that have no place on most modern sites. I get tired of having to pull out a claw hammer to de-construct tables. If your code produces tabular data then you’re doing users a service, otherwise find another way.
- SoMe non-lowercase CODE
- I wrote “non-lowercase” because that best describes CaMeLcAsE and UPPERCASE. Markup should be written in lowercase. Writing things like
<P></P>, or worse, a mix of lowercase and uppercase, has no business being on a contemporary site. Same goes for scripting events and whatnot. Please develop proper and consistent practices.
- Where are the missing attributes?
- I see this a lot on image markup. The width and height attributes are missing. They are still legal, still useful, and actually enhance site performance. If the width and height is specified, the browser knows what space allocation is needed for the image and can properly render the page before all of its content is downloaded. Also be sure to include the alt attribute but don’t be too quick to offer alt text. Seldom does it enhance the user experience so you need to understand how this attribute’s text is delivered to users who need it. More info is available in my The Alt and Accessibility article I wrote a while back.
- A trial link separation
- If your plugin or add-on code contains a bunch of links, please make sure they’re properly separated. This was something I experienced recently, and I won’t mentioned the maker or the plugin, but I had to fix it. It wasn’t hard because I have some knowledge about the scripting language used and web accessibility, but I shouldn’t have had to fix it to begin with. There are a few basic rules which help retain inherent web accessibility, so try to gain understanding of these and make your code compliant.
Help Spread the Word
In my comments please share some of the atrocities you’ve seen that I may have missed. And more importantly, please help me spread the word so the guilty see this or hear about it. You can do this by referring to this article, or simply blog about it yourself. If a significant number of voices sound off, maybe the guilty parties will hear the plea and maybe spend a few moments making their stuff right. This will go a long way towards making the web in general a more standards-compliant and accessible place.