Getting the Word Out On Web Standards and Accessibility October 20, 2006
Posted by ptvGuy. Comments: 6 comments
…otherwise intelligent business people are entrusting their entire web presence to such as these…
Let's face it, we live in a world where any high school kid with a semester course in "web design" (if even that much training) and a copy of Frontpage can hang out a virtual shingle calling himself (or herself) a "webmaster." Factor WordPress into that with its five-minute install and innumerable themes and you have a job title glutted with people who don't know the first thing about what they're doing. An amazingly large number of otherwise intelligent business people are entrusting their entire web presence to such as these. The general public's lack of knowledge in this area only serves to exacerbate the problem.
Without any foreseeable way to prevent this practice from continuing and growing exponentially, those of us who care are left with the onus of attempting to educate these fledgling webmasters about the need for good coding practices, accessibility, and web standards. I know, many of you have been doing that for years already, but this is an ongoing problem requiring constant reminders.
To help out in this endeavor (and to provide professional web developers with yet one more way to stand out from the crowd,) I've created a document called the "Declaration of Standards Compliance." The style and wording may sound a little familiar to you.
When in the course of online events, it becomes necessary for web developers to ensure access to the content over which they have so meticulously labored and to assume among the powers and tools available to them, the basic responsibility to ensure proper markup and accessibility, a decent respect for their site’s users regardless of their browser, platform, or possible disabilities requires that they should declare their document type for proper page rendering and their assent to basic web standards.
–ptvGuy, Declaration of Standards Compliance
…need for web standards and accessibility cannot be understated…
Now, before anyone gets in an uproar and thinks that I am perhaps mocking the document upon which this is based–The Declaration of Independence–I'm not. I don't know of a clearer way to outline an ongoing problem and then express the need for action and the conviction to carry it out. As a pure study in writing, it's one of the greatest essays ever written. I humbly borrow from the masters.
The need for web standards and accessibility cannot be understated. If you're putting content out there for the world to see, use, and interact with, then there is a certain underlying responsibility to do it correctly. That requires some extra work and study. Fortunately, the web is full of people willing to share that knowledge. I've put together a list of such resources on my Anal Coding page to serve as a beginning point. The very abundance of this information made freely available to everyone everywhere is what makes the practice of bad coding so pointedly shameful.
…standards are themselves evolving and subject to change…
One important thing to remember, however, is that the web is not a static technology. It is constantly growing, expanding, and evolving. New people, ideas, and technologies will come along and suddenly change everything we've taken for granted. (That may even include the aforementioned high school student.) The standards, therefore, that guide us in the creation of accessible and well-coded pages are themselves evolving and subject to change.
I encourage you to read the document itself, comment on it, and, if you agree with it, go to the declaration page and find out how to become a signatory of this important declaration and thereby further get the word out on the need for web standards and accessibility.
Thank you all, code well, and good night.
- << First
- < Previous
- Web Accessibility
- Next >
- Last >>
Beta Testing and the New PBS Web Modules October 4, 2006
Posted by ptvGuy. Comments: add a comment…new web content modules and the need for beta testers…
The recent spate of new web content modules coming out of PBS (and beyond) has me thinking about the need for beta testers. For those of you that may never have given it a try, beta-testing is the process of testing something out before it's ready for release to the general public. It can be quite interesting whether it's software or a new web module. It gives you a chance to not only critique someone else's work, but to sharpen your coding skills and offer suggestions for refinement. It makes you a part of the work. The biggest kick for me, however, is getting to play around with all the newest toys before anyone else even gets to see them.
Testing is a process of executing a program or application in the intent of finding errors. With that in mind, testing can never completely establish the correctness of arbitrary computer software. In other words, testing is criticism or comparison, that is comparing the actual value with an expected one.
–Wikipedia, Software Testing
Basics of Beta-Testing PBS Web Modules
…have noticed the recurring use of common words for CLASS or ID element names…
There are a few important things to remember when beta-testing PBS modules for your station site. The first and most important of these is to test it on a working version of your actual station website as it would run under normal conditions (although in a nonpublic area protected from search bots and perhaps requiring a password to enter.) The idea here is to see how it functions on a real station website. The PBS Interactive in-house alpha testing should have already covered how it works under other conditions.
It must be allowed to interact with your usual station CSS in place on the page. No matter how narrow and focused the CSS for a new module may be, there may still be unforeseen interactions with already existing styles. That's exactly the kind of stuff that PBS Interactive is looking for and needs to learn from your feedback, and that's exactly why they have to have beta testers. I, for instance, have noticed the recurring use of common words (like "description") for CLASS or ID element names which virtually guarantees problematic interactions with already existing styles and script triggers.
…picked their beta testers from a wide selection of stations…
The module should also be tested under the normal coding restrictions (or lack thereof) imposed by your site's primary document type declaration. To make the modules as cross-platform, cross-server, and cross-browser compatible as they can possibly be, they need to be tested under differing document types. Ideally, the people at PBS Interactive should have picked their beta testers from a wide selection of stations representing as many different document types and servers as they possibly could to get the widest possible testing results and thereby eliminate the most possible errors. Therefore, the minimum testing that should be performed from our end is simply to set it up on a regular page of our site. We're, of course, always welcome to test more beyond that.
The Process of Beta Testing
I don't know how others do this–and I'd love to hear–but I generally start out by implementing a new web module in its raw state (no code or style modifications) in the widest possible section of a page. I usually pick a single-column page layout for this (no sidebars) in order to get a good 700 to 740 pixels of width to play in. A site with a non-fixed-width (or "liquid") layout will, of course, have variable outcomes for this. I do this even if the module is actually meant to be narrow sidebar content.
The idea here is twofold; first, to see if the module even works, and second, to see just how wide the module will go. After looking at the results of that–and assuming it works–I check the code and CSS to see if there's anything in place that restricts the module from going even wider. Playing around with the Pre-K Block Module, for instance, shows that it can be used not only as sidebar content as it was originally intended, but also as a variable-width page filler wherever needed. That gives me a nice new tool for balancing out low-content pages.
The next test I do is to implement the module into a narrow, restricted space. The easiest way to do this is by putting it into a table and deliberately setting the width too low (like 10 pixels) and the border to zero. If your CSS has predefined table element padding and margins, then this experiment may require the creation of a specially named CLASS for a non-padded table that will have to be defined in your style sheet.
…followup module states must also be taken into account and planned for…
The point of this test, of course, is to get a minimum width for the module—usually the width of the widest single element like a graphic. I personally think that every web module should have the minimum and maximum widths spelled out in the documentation. It makes it easier to plan layout and placement. Everything after this is just about playing around with the CSS and coding to either fit it in better with your site's style or run further experiments.
My general last step is just to put it into a page with other content, style it to fit, and get an idea of the full visual and content impact of the module and, of course, what it does when a user intereacts with it. Some of the modules take users offsite, some open new content windows, and some (like the TeacherSource Monthly Theme Module and the Schedules Module) open out on the same page from a small space initially into larger pieces of content. These followup module states must also be taken into account and planned for (as many stations discovered after implementing the Schedules Module.)
Some Final Words
…shortages of staff and time are already impacting development of new content…
Although most of the PBS member station websites routinely rely on the content they receive through PBS web modules to fill out their own sites, there is quite often a shortage of station web developers willing to help out in the beta-testing phase of their development. That's too bad since shortages of staff and time at PBS Interactive are already impacting development of new content. It's in our own best interest, if we're to remain relevant in the 21st-century, for us to be a willing part of this important aspect of content development.
Meaghan Zimmerman of PBS Interactive sums it up best:
BETA testing is a vital part of the process of building and launching modules for stations. Our thanks and appreciation go out to those stations who continue to volunteer when asked for their time. The more BETA testers who volunteer, the better the results.
–Meaghan Zimmerman, Senior Associate, Station Services, PBS Interactive
Thank you all, code well, and good night.
