TheAccessPond.com

As my wife Laura can attest, I’ve been burning the midnight oil recently working on my secret project that involves a lot of Adobe ColdFusion.  I’ve been an on-again-off-again CF author for some time, first working with ColdFusion 4 (or was it 3?) back in 1998 when I put together the CAVNET site for my friend Marc Dubin (send him–not me– the hate mail for not keeping it up-to-date since he left the Department of Justice).  I haven’t coded anything recently in CF 8 and boy has it changed.  And, it has me rethinking some of my ideas about accessibility.

For those of you who might not know what it is, ColdFusion is used on web application servers to do much of the magic that we associate with Internet web pages.  It’s used for querying databases and creating content that then magically shows up on your browser when you go to Amazon to buy a book or Alaska Airlines to book a flight.  CF is kinda like PHP or Active Server Pages.  The neat thing for techno dummies like me is that CF is super-easy to use.

In fact, potentially too easy… which gets me to New Accessibility Thought Number One: “Accessibility Might Get Harder as Tools Get Easier.”  In CF, it’s ridiculously easy to do things that would otherwise be really hard.  Use a <CFCHART> tag and your data gets magically transformed into a JPEG, use a <CFDOCUMENT> tag and your printer-ugly HTML suddenly becomes a beautifully formatted Acrobat file that you can e-mail to your client.  Sure, there are a million and one attributes that each tag can take– and these all affect some little part of what comes out– but I ultimately have no idea how this stuff works.  Worse yet, I have no idea how it will work with the different AT’s out there.  Now don’t get me wrong: I think Macromedia (and now Adobe) are industry leaders in accessibility.  But, from working on the “other side” of accessibility for so long, I also know that solutions are often a matter of rolling up your sleeves and playing with the code and seeing how a screen reader hits it.  Now, when I hit View | Source  in IE and see what CF created, my head spins looking at the code that I have no control over (if you don’t believe me, try an innocent-looking <CFTREE> control in your CF template and see what shows up).  Then again, my dad has the same complaint about his new Toyota and not being able to fix it like his good ole Ford.

At the same time, my recent foray to the other side of the techie world has me babbling heretical New Accessibility Thought Number Two:“Retrofitting Ain’t That Bad.”  When you create a new building and forget to put in a ramp, retrofitting means calling out the jack hammers and making some really costly repairs.  In most HTML and CSS, it isn’t that bad provided that the design isn’t that dynamic to start.  The techniques are well-understood.  Here comes the real heresy, however– in the mock-up and brainstorming phase, accessibility sometimes gets in the way.  Why put an alt attribute on an image if I’m still so early in the design phase that I’m not even sure I’m going to keep the image at all?  Why put headers and id attributes in table cell tags when I’m not even sure how many columns and rows the table is ultimately going to have?  I can’t believe that even the most die-hard, accessibility-oriented web developers out there make their rough drafts fully accessible– and it’s precisely because they know that retrofitting some things are just going to be really easy later on.

No Comments »