Malarkey has posted an interesting article about…well, semantics and design…over on his “Stuff and Nonesense” blog. He has some interesting thoughts about when to place images in HTML as opposed to CSS, and the impact of design on the content you are presenting. It’s a good read and, as usual, the visitor comments are just as interesting.
I just finished a 12 hour day getting this site re-fresh ready for launch. It was my first real stab at a CSS-only flyout menu and I’m really pretty nervous. I know that older browser support will be spotty (or non-existent), but it should function in all current browsers and platforms. I’m pretty happy with it, but could probably use an expert review. I mean, in some ways I am an expert, but that just scares me sometimes. I mean, if I’m expert in any aspect of this wild and wolly internet then how the fuck is it still even running?
My main responsibility was the flyout menus under “ideas” and a bunch of image chopping and HTML cleanup. Please, by all that is holy, do not run an HTML validation on this page. We had nothing to do with the core HTML and I would dearly love to spend 10 hours just combing through the code getting it all up to XHTML snuff. Just seeing the thousands of occurances of
Maybe I’ll just FTP to the server on my own time while nobody is looking and just…
shhhhhhhhhhhhhhhhhhhhh
I swear, the next time I hear someone ask a client “How accessible do you want your site to be?” I’m going to scream. There is this misconception pervasive throughout the web-dev-consulting-design field that, at some point, you have to sacrifice design or function in order to accomplish some nebulous holy grail of accessibility compliance. For more on compliance, what it is, and what it should be check out Malarky’s post, “Wearing badges is not enough.”
It’s understandable. Prior to the availability of CSS, this was more or less true. These days, there is no excuse to build a site that is not accessibile. Really…It’s not some twisted fundamentalist in me that’s saying that. It’s just the me that codes HTML and CSS. It’s the part of me that spends hours turning a Photoshop design into a streamlined, zero-to-sixty in less than five seconds, complete with a wheelchair lift and assistive steering controls, rocketship of a web site.
Here’s where we shoot ourselves in the foot everytime: The part in the development process where the design gets turned into HTML templates which are, in turn, dumped into a content management system (don’t even get me started on what those things do to my beautiful HTML) by a developer who has neither the time, inclination, or desire to keep an eye on what happens to the code, has become an afterthought. The role of HTML-coder is the first thing to be outsourced. Usually to a designer or developer who cuts HTML in their spare time to help pay the bills. The reason that this happens is simple. Most folks start working on web sites doing everything. They design a site, cut it up, and build it out. As they get more experience, they specialize. Usually in programming, design, or the part I totally don’t get: strategy. Coding HTML is a rung in the ladder that most people see as an inconvenience to overcome rather than a skill to master.
This is where I am now. I’m under orders to freelance out the HTML work at my company. If we were a little bigger I could probably make an arguement to keep it in-house. We’re not, so I can’t.
It’s a fucked up catch-22. I work at a compeny small enough to maintain a culture that I find rewarding and healthy. One in which I’m not just a cog in a machine. But at the same time, the cog that I care deeply about isn’t valued. I’m still trying to figure out how to make it work. More later.
Also of interest from Mr. Malarkey on this subject:
On a shoe-string
Panning for gold
And from A List Apart:
What Is Web Accessibility?
