Our websites for this class have to meet Priority One accessibility standards. I didn’t know what those were so I decided to write a post about them. The first Google article I found was for the w3c, which is probably as it should be. However, trying to decipher those seemed a bit overwhelming so I looked for a site that had them broken down a bit. Found one! A site called The HTML Writers Guild has their own interpretation of the Priority One checkpoints and they seem to mirror the w3c standards but are easier to understand. Here’s their list followed by my explanations:

• Provide text equivalents for non-text elements.

Use alt, longdesc, etc. for images, imagemap areas, multimedia, etc.

• Don’t rely solely upon color.

Color useage is encouraged but you should also use strong tags or something else to identify text marked by a color change.

• Identify language changes.

Use the LANG attribute (and probably the SPAN element) to mark language changes. An example is:

<span lang=”fr”>Cette phrase est en français</span>.

• Make sure pages are usable without style sheets.>

Use of CSS is encouraged but you should check to make sure your pages still present well (and in order) when the CSS is turned off.

• Update equivalents for generated content.

If you have dynamic content, make sure images and other related items are in synch with the content.

• Don’t make the screen flicker.

Period.

• Use plain, understandable English.

If you use a technical term or jargon, provide a reference link.

• Use client-side imagemaps, not server-side.

“Server-side imagemaps may be used in addition to client-side maps, but should never replace them. A text equivalent list of links should be provided for all imagemaps.”

• Use HTML 4.0 table markup on data tables.

This one is a biggie and I’m not going to detail it here. In general, though, it means using stuff like THEAD, TBODY, COLGROUP, CAPTION etc. You can read about it in the HTML 4.0 Specification.

• Frames should have NOFRAMES and TITLEs.

(If you use frames)

• Don’t rely solely upon scripts and applets.

An example here is that if you’re using client-side validation for forms, make sure you also have a server-side script for users with JavaScript turned off.

• As a last resort, make an alternate page.

Try to avoid this if possible. The author of the HTML Writers Guild site noted that often, alternate pages aren’t updated like the original one, so they tend to get out of synch.

Ok, so what seems to work is for me to use these posts to explore some of the things I feel dumb about. Helps me play catch up and not feel so out of synch. So . . . RSS. Until a few weeks ago, I didn’t have a clue what it was except that somewhere, I had heard that it stood for Really Simple Syndication. I think. There. I’ve said it. I haven’t a clue. Let’s learn about it.

When you enter RSS in Wikipedia, the article starts like this: “RSS is a family of web feed formats . . . “ That sort of made sense but I wanted to dig a little deeper so I followed the link to “web feed”. Ah. Neat article here. I learned the following:

• If you’ve got content (which, I guess, means anyone who has anything on the Web) – as a content owner, you can “syndicate” that content. (Here’s a fun tangent – I tried to look up “syndicate” on Wikipedia and the article wasn’t helpful. I was about to leave Wikipedia for Miriam-Webster when I noticed a little thing in the side bar that suggested I look up syndicate in the Wiktionary! What a great name! That entry wasn’t totally helpful either but basically, it seems like syndicating content just means that you distribute it.)
• Once you’ve syndicated your content (which I’m not sure how to do but that will be a different article), then a user can subscribe to that content.
• The user signs up to receive the content with something called an aggregator (also called a feed reader or a news reader).

Feed readers. Some stuff to learn here:

• It’s like getting an email except that you don’t have to give them your email address (which makes it safer).
• Personalized home pages like My Yahoo, My MSN and My AOL use feed readers to present your news, weather, stock quotes, etc.
• There are other web-based tools that are made just for feed reading. A popular one is Bloglines. I think the Netvibes thing we’re using in class is maybe a feed reader plus other stuff?
• Firefox has a feed reader built into its toolbar called Live Bookmarks; IE 7 has a similar one called Favorites
• You can also get desktop feed readers that you download (e.g., Newsgator and Feed Demon).
• Attensa is a feed reader for Outlook

Whew. Ok, now I just need to sign up for some (aside from what we did for Netvibes) and practice using them so they become old hat.

I need another personal post – helps me clear out my brain and focus. Life is very intense right now. The septic tank at my office decided to die and since the owners of the building are planning to sell, they opted not to fix it. This meant that the 8 of us who have called the place home (me, for over 20 years) are suddenly in the position of having to scurry around and find a new place to practice. Moving to commercial office space is a lengthy process. Once you find a space you like, you give the owner the specs you want and it typically takes around 2 months for them to get the necessary permits and build the place out. Two months in the old office with the possibility of no water or plumbing isn’t a viable option; two months of not seeing clients isn’t a viable option. So, Anne and I decided to move our offices to our home temporarily.

As a result, this week has been a week of rapidly changing hats. We go look at commercial office space to try to find a new permanent home. Then we swap that hat for our Home Depot hat as we go into fix-it mode to try to convert our home into temporary office space. Then we don our therapist hats as we go see clients. And the interior designer/architect hats as we make tentative drawings of how we want our new space to look. In a few hours, we’re going to go hire a couple of guys off the street to come help us move furniture. I’m not even sure WHAT that hat is. And of course, there’s my student hat that I just pulled down over my ears as I began to write this post. And the beat goes on . . .

A couple of times this week, I thought of writing Aarron a whine email telling him all of this and asking him not to expect great things from me this quarter. I still pretty much just want to whine about it all. However, in my nobler moments (which are few and far between right now), I’m trying to see this as an opportunity to learn something I’ve never been good at: how to work smarter, faster, with less “fat”. Get more (and perhaps better) work done in a smaller amount of time. I’ve never, ever worked quickly. I meander around a lot to get from A to B. For example . . . well, ok, writing this personal post. It doesn’t have to be done. It’s not part of any assignment. I’ll still write my two non-personal posts for this week. But it helps me. Gets me in the right track. So . . . is that fat or something essential? Hmm. Maybe I need to remember that fat – for all the bad press it gets – is an essential nutrient. At least it seems to be for me.

Here’s a trip: I was interested in learning more about how to make a URL more findable and when I Googled it (findability URLs), the 7th entry down was from Aarron’s blog! I read through his articles and found the general guidelines about URLs – i.e., adding keywords to your URLs make them more findable. I also found specific info suggesting incorporating the title of a blog post into the URL, and instructions on how to do that with WordPress. However, what I was interested in is something Aarron had mentioned in class that I didn’t catch – it was something about why you use hyphens in a URL as opposed to underlines.

Hmm. Back to Google. . . this time, try: findability URLs hyphens.
Success! I found an article (‘Google test: hyphen and underscore’) that explained exactly what I was curious about. Here’s what I learned: If you separate words with hyphens (in either a URL or the body text), Google registers each word as a separate keyword. Thus, Google would see ‘red-rose’ as having ‘red’ as a keyword and also ‘rose’ as a keyword. However, Google reads an underscore as a way to connect the words. So red_rose would be seen as a single keyword: ‘red_rose’. Yea! I learned something!

Hey! I at least just found out how to make categories for my blog! Awesome! Ok, so now on to what I just learned that I thought was totally cool.

I’ve been reading about how search engines don’t spider JavaScript. That’s been sort of a meaningless, no-context, ho-hum statement to me. However, I just found this article on SitePoint that livened it up for me and suddenly transformed it into something that’s REALLY cool. The article is ‘Avoiding the 5 Most Common SEO Mistakes’ by Johnathon Smith. In the article, he provides a real-life example of a site that gathered hot “deals” from around the web and aggregated them in one place. It was a great site but because it was coded with JavaScript, no one was able to find it. What the author pointed out (which was brand new info for me) was that if the web developer had coded the same thing with a server side language such as PHP, the aggregating would take place on the server, leaving the page with spider-legible HTML. Now THAT’S a concrete example that brings it alive for me.

I have been having horrible writer’s block on these posts. Being an “I wanna understand it” person at heart, I’ve spent some time trying to figure out why. Here’s the deal:

1. I feel totally out of my element in this class. I feel like I’m back in 33 RPM-land while everyone else in class is spinning CDs and DVDs.
2. The assignment specifically says we’re not to write personal posts and that’s what I do best.
3. The whole point of this course is to learn about findability and we’re supposed to use the techniques we’re learning to make our blogs more findable. To be honest, with the state of my learning at this point, I’d really rather hide my posts so no one CAN find them. (It’s probably not a coincidence that I titled my blog ‘To Find or Not To Find’.)
4. In short, I feel dumb, not up to the task, and that there’s no way in heck I can play catch up quickly enough to come up with anything important to say that wouldn’t be old hat to everyone else in the class.

So that’s what’s tying me in knots.

Now. I also know what DOES work for me. What works is for me to find something that sincerely interests me. It may well be kindergarten level compared to where everyone else in the class is but if I don’t worry about that and just write about what I learned, I’ll be fine. And I’ll learn stuff. The stuff I most want/need to learn. AND . . . I do want to learn about findability. I have a web application I’m hoping to market some day and heck YEAH I want people to be able to find it. So to be honest, I pity the person who finds this blog but maybe I can think of just using it as a vehicle to learn things I’m sincerely interested in learning.

There. 343 words of sheer personal indulgence to help me break through my writer’s block.

I was first introduced to HTML around 1995 or ’96 through some tutorial types of courses offered by America Online. Tables were used for layout and the font tag was applied liberally. Although CSS got an occasional nod, the topic of accessibility was almost completely ignored. If anyone dared ask about it, they were told that it was very complex, unsupported by browsers and in short, not worth messing with. My, how we’ve changed.

Andy Hagans has pointed out that accessibility is an important factor in findability. If a person who is physically challenged in some way can’t make sense of a website and find what they need, chances are that a search engine would not be able to, either.

The accessibility standards are presented in priorities:

Priority 1 checkpoints. These must be followed or one or more groups will find it impossible to access information on your site.

Priority 2 checkpoints. These should be followed or one or more groups will find it difficult to access your information.

Priority 3 checkpoints. These may be followed to improve access for one or more groups.

To be honest, the accessibility standards still seem complex – or at least, lengthy. However, with increasing browser support for the standards, it behooves us as web developers to roll up our sleeves and get a bit dirty as we figure out how to apply these standards to our sites.

Reference: W3C: Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0

To Find or Not to Find

This is a rather odd time. I find myself in a class on the topic of findability at the same time I’m trying to build an application that will hold sensitive data that specifically needs NOT to be found. Using the maxim that often one learns the most about a thing by trying to figure out how to avoid it, the posts in this blog will meander around in both territories: to find, or not to find. And if, perchance, I happen upon some outrageous fortune along the way (preferably without the slings and arrows), so much the better.

That said, a logical place to begin seems to be with a discussion of Web standards. Without this common foundation, neither findability nor unfinadability has much of a chance. The following steps are essential for good Web standards:

• Include the correct doctype: Doctype stands for Document Type Declaration (DTD) and its purpose is to tell the browser which version of (X)HTML was used in coding the page. It must appear at the top of each page and be exact in both spelling and case. The W3C has a list of recommended doctypes.
• Keep the following elements separated from one another:
  • Structure (HTML, XHTML, etc.)
  • Presentation (CSS)
  • Behaviors (JavaScript, PHP, etc.)
  • Content
  • This practice includes avoiding inline styles and inline JavaScript event handlers as much as possible. (The latter is called unobtrusive JavaScript.)
• Validate all code. Make sure all code you write is well-formed and passes the W3C’s validation tools.
• Use meaningful terms for id and class names. For example, using divs for the layout of the various sections of your page and giving them ids of header, leftNav, mainContent, and footer makes the structure of the page clear, just from reading the names of the ids.

This list is only a beginning but it’s an important one. Following these rules is essential to content that can be found as well as content that should remain hidden.