afongen

Two things.

First, this spring’s WebAIM accessibility training is now available for purchase on CD.

Second, Mark Pilgrim’s much-and-deservedly-vaunted “30 Days To A More Accessible Weblog” series is now accessible as Dive Into Accessibility.

Both super resources.

A vulnerability in PHP means you should upgrade now. Uh, now. Either that or disable POST entirely.

Well, I made it. O’reilly’s Open Source Convention. Cool. There is, as expected, a wireless connection in the meeting areas, so I look forward to scanning the blogs to see how others feel about the thing.

Travel tips for the untravelled: curb-side luggage check-in is a service for which one should tip. Make sure the airline staff give you the right boarding pass. And yes, I’m proud that you remembered to bring a toothbrush. Now for the kicker: toothpaste? I hereby apologize to the fella who sat at breakfast with me before I had a chance to buy some. At least I wasn’t too talktative. As if I ever would be that early in the morning.

The weather here is great, and it’s clouded up a bit today, something with which I’m more comfortable than sunny, clear, blinding skies. I got out a little bit yesterday, for a walk along the bay (unless it’s called something else), but otherwise I was kinda wiped out all day. I don’t know why, maybe cuz I hardly slept this past week. Pity, too, since I had some work to do, something that will have to wait until later today after the tutorials. Damn. I had very much hoped to have that done by now so I could enjoy all my evenings more. At least I can sit on my room’s balcony and code.

There’s a couple here with an infant, pushed around in a little Jeep stroller. Cute as the dickens. And makes me all the more aware that I’ve left my pregnant wife at home. But Kiara would be bored silly here unless she had someone to hang around with. Maybe next time.

I’m excited for my first tutorial, which starts pretty soon, Mastering Data Structures and References in Perl. This is something that I feel like I understand pretty well, but I don’t really grok. Many of my tutorial and session choices were made with just that in mind,

I do plan to write more about the conference as I go, but I need to set up a better way of doing so. That something else that I’d hoped to do last night instead of sleep. ‘Til later, then.

You probably won’t hear from me again here for a couple days, until I’m able to get hooked up at OSCON. That’s right, I’m goin’ to California. If you’re in San Diego over the next week, drop me a line, maybe we can get together for a beer or coffee or a conference or something.

I’ll be blogging the conference, just cuz. Seems like a better way to take notes than I usually do. It also strikes me as a good excuse to finally play around with blosxom.

Cirque du Soleil are coming to Minneapolis. Theirs is a truly phenomenal show. If you ever have the opportunity to see them live, do go. It’s expensive but it’s worth it.

Day 27: Using Real Headers. In all the training I’ve done, accessibility and otherwise, for some reason this is one of the hardest things to get people to understand: using markup for structure. For example, using headers to identify, well, headers.

I’m not sure why. I think that at first it may be a fear of the default style in most browsers for the <h1> and <h2> elements, but demonstrating how easy it is to use CSS to control the appearance of headers does little to alleviate the hesitation to use those elements.

I think it also has to do with a lack of understanding of how documents — writing — can be structured, period. Years of experience using word processors as little more than typewriters hasn’t helped. Neither have the increasingly powerful desktop publishing and layout features in word processors, emphasizing how a page looks rather than how the content is organized.

Until I learned HTML, I never used the outline features in MS Word, or even the headers or styles. I saw them there, but they never seemed useful or even interesting. Every paper I wrote was an unstructured document. If I decided to change the appearance of the headers, I had to painstakingly change each one and hope that I was consistent. Ugh. HTML opened my eyes, and now every Word doc I create is in outline form.

(I had never used tables in a word processor, either, until I discovered them in HTML. I’m a better word processor user because of my work on the web.)

I’ve found that this has improved my writing, too: structuring a document’s content encourages me to structure my ideas more coherently. In academic papers, in documentation, in white papers . . . in all these things I write, coherent thought and communication are essential. They’re the whole point.

None of this, I’m afraid, helps people understand what seems to me a rather basic concept: using markup for structure. What will it take?

Teaching people to write clearly, I suppose. That’s a good start. I’m not sure how much I agree with what Brendan O’Neill has to say about blog writing, but it is worth consideration. I’ll try to post something more on this soon.

In the meantime, back to the point: use markup for structure. Structure everything you write. The two are intertwined.

For those who have been asking (and even those who haven’t — sorry about that, Paul), I’ve posted ultrasound pictures. For those who don’t know: yes, Kiara’s pregnant.

There’s a new look for perl.apache.org, the home for mod_perl. Should be much easier to find what you’re looking for now. I never did find information about mod_perl 2.0 on the old site, but it’s just a click or two from the home page now.

Congratulations and thanks to all involved.

Lately I’ve been doing a lot of accessibility training for web designers and developers, as well as the odd group of faculty. When I first started preparing for these training sessions, one of the challenges was to come up with a set of guidelines that make sense not only to people who live and breathe XHTML and CSS, but also to a much broader audience that may include department secretaries using a WYSIWYG editor like Dreamweaver to maintain a web site, non-technical faculty adding online content to the courses they teach, administrators who oversee web sites but don’t maintain them, and so on.

The W3C‘s Web Content Accessibility Guidelines 1.0 might make sense to web developers with a solid foundation in HTML and CSS, but face it: it’s a complicated document that relies heavily on several other associated documents. You have to be familiar with them all before any one of them makes sense.

The US Section 508 standards are okay, but they do ignore several important areas and rely too heavily on assistive technology. As a result, under Section 508 it’s considered acceptable to require JavaScript to access content, as evidenced by the training section of section508.gov. This is misguided and wrong.

I’m quite fond of the State of Illinois Web Accessibility Standards, and have in fact adopted them (with permission) as the basis of the guidelines that I drafted for work. I like the format in which guidelines are presented, and my experience with using this document in training has shown that it can be understood and used by a variety of people with different levels of knowledge about web standards, which is the point. So far so good.

The W3C has released another working draft of their Web Content Accessibility Guidelines 2.0. Even as a working draft, this is a much more accessible document than its first-version predecessor. It does not rely so heavily on a particular technology (HTML) and is geared more deliberately to a broader audience. “The overall goal,” the Guidelines state, “is to create Web content that is perceivable, operable, navigable, and understandable by the broadest possible rande of users and compatible with their wide range of assistive technologies, now and in the future.” The guidelines are then grouped under those five categories, with specific checkpoints and clearly defined benefits for each.

I like how version 2 is shaping up. It will, I think, prove to be a much more useful and broadly applicable set of guidelines than version 1. Now I have to start thinking of ways to incorporate elements of WCAG 2.0 into guidelines for work. Can’t wait until it’s released in its final form.

Back in January, I got email from VeriSign customer service that “your VeriSign domain name registration for lscmetalfab.com and others … are up for renewal soon.” This was a lie:

1. lscmetalfab.com is not my domain. I had in fact never heard of it until VeriSign prompted me to renew it.
2. The domain was not in fact due to expire until November, eleven months after I received the email.
3. The other domain listed in the email, afongen.com — which I haveregistered, as you may have noticed — was also not due to expire anytime soon.

I contacted VeriSign and they told me, “We will look into it. If you receive any further notices for this domain, please disregard them.”

Right. I forwarded the message to the contacts for lscmetalfab.com, so they would know that VeriSign was screwing up like this. By a bizarre coincidence, this company happens to be in the same city where I was living at the time.

Well, guess what? I got another renewal notification today, this time warning me (a “Valued VeriSign(r) Customer”) that my domain afongen.com and others are about to expire. Another lie.

1. I am no longer a VeriSign customer. I moved my registration over to PairNIC a couple months ago.
2. afongen.com doesn’t expire until November 2003. I will renew it long before then.
3. They again listed lscmetalfab.com as a domain that I have registered.

Grrr.

So I’m going through the same rigmarole, only this time I can tell VeriSign that I am not a VeriSign customer, so why in the world are they contacting me?

I haven’t really been using spam filters lately, but I think that I’m going to set one up and route any messages from verisign.com, networksolutions.com, nsi-direct.com, etc. to /dev/null. On the other hand, these are rather amusing.

And if you’re from Linders Specialty Company and happen to be reading, consider VeriSignOff.