<object>tag, will be under scrutiny for patent violation. As Ronaldo Ferraz put it, HTML supported the <object> tag by that point, so how come Microsoft couldn't come up with examples of prior art? People have been saying for years that the U.S. patent system is broken. Interesting to think that it took a lawsuit to prevent the
<img>tag from being deprecated in XHTML 2.0.
Ian Lloyd is a member of the Web Standards Project and runs a site about web accessibility called Accessify. His full-time role is senior web designer/developer with Nationwide Building Society, a UK-based financial services organisation which, despite the protests below, doesn't do a bad job of making its web pages accessible and standards-compliant.
Designing for the Future, and the Training Gap
How do you encourage unenthusiastic developers/mark-up authors to adopt forward-thinking web development methods?
How do you engage people who consider their work on the web as just that: 'only work', something that pays the bills but doesn't exactly leave them beside themselves with excitement?
I am but one individual in a team of many (in my place of full-time employment) and I am from a strange breed - I have a passion for the web! What happens when you are part of a team that is not as uniformly enthusiastic to learn?
This is a problem that faces many IT managers and standards advocates working in the corporate sector. Though we're doing good things in adopting accessibility practices and optimising our code, it's still very difficult to get a site to conform to all the major standards in the real world. Why is this the case?
Learn from Textbook Cases
Andy King's book Speed Up Your Site includes numerous tricks and tips for committed web developers. Jeffrey Zeldman's Designing With Web Standards is a tome of practical, well-thought-out techniques. Both not only explain how to improve the way we develop sites for maximum efficiency and future-proofing, but they also clearly detail why the problems exist in the first place.
These are just two books among many that have made me think and re-think about how I build personal sites and company projects. I devour the content of these books and regurgitate it - metaphorically speaking - wherever I can. Sometimes these tips and tricks find their way on to the corporate work, but invariably they're resigned only to my personal work.
Most of my learning happens on the toilet. Sorry! As unappealing as that is, that's where I pick up most snippets of information (they say that the seat of learning is Oxford but I beg to differ - it's the downstairs loo). Because I have a passion for what I do, I've made it my business (no pun intended) to learn how to construct table-free page layouts, make pages accessible for keyboard-only users, provide different views of a page through alternative style sheets, and more. I don't have to. But I want to make things work better, faster and cleverer. But we're not all like this. Most people would rather read a newspaper on the toilet. Or maybe nothing at all. But that's quite enough of our potty habits for now. Shall we move along?
Individuals Lead the Way
It's true that most corporate sites fall way behind the personal web sites of mark-up and standards gods and goddesses (e.g. the aforementioned Zeldman, Owen Briggs, Ben Henick, Simon Willison, Dan 'Waferbaby' Bogan, Jeremy Keith to name but a few personal favourites among many).
This is because it's far easier for an individual to introduce a novel or clever way of doing things - there are no committee decisions (and therefore no split decisions or arguments). As well, no matter how progressive and forward-thinking the company you work for (and I believe Nationwide qualifies here), there will always be an issue with introducing 'new' methods. Let's just overlook the fact that many of the methods that I've alluded to are actually a number of years old (CSS2, hello?) - it's all about perception. If other people, and by that I mean 'corporates', are not doing it, then it must be new, right?
Look at just a handful of the things happening on these forward-thinking personal web sites:
- Totally CSS-based page layouts
- Gone are the tables that were never intended for layout purposes (tables are for data, folks - layout grids are an abuse of the mark-up, an abuse that we've come to live with and accept a bit like an irritable auntie with an equally irritable terrier that visits every weekend). Now we can view such sites on a PC, a handheld device, using a screen reader and more, and we get the added bonus of quicker-loading pages.
- More usable forms
<legend>elements are supported by most modern browsers, and in the right hands they can make a form far more usable and accessible. And they're definitely semantically sound.
- Data tables that work
- Using elements like
<tfoot>, and attributes such as summary, scope, ids and headers, data tables become meaningful to blind users accessing the content with a screen reader (rather than a jumbled mush of words and numbers).
Training is the Weakness
Let's assume, for example, that browser support is not the issue, that you've taken a stance and agreed to support browsers that support web standards (while not completely turning your back on the older browsers). Let's assume you've already said that your company is going to focus on getting things right for IE5+, Netscape 6+ (or Mozilla/Gecko derivatives) and Safari. Now inadequate browser support is no longer an issue. You should be able to do things right, right? The browsers you've settled on are up to the job so what's stopping your company from moving forward? One word - training.
You may have a few individuals in a department that have a passion for doing things according to the relevant standards and as efficient as possible; but you are equally as likely to have a whole group of people - probably a much greater percentage - who do not share that passion. They may have learned HTML five or more years ago and are still using the same methods (tag soup) that they always have. Every team is different, but here are some that you may identify with:
- Fear of change - they know where they are with the 'old school' methods
- They believe that the new methods are more complicated
- They don't understand semantic mark-up (in fact they have never even heard the word 'semantic' before)
- Their job is just a job and learning new things is either a bore or an intrusion into their personal free time (they just don't get that whole toilet-seat-learning thing).
- They see themselves as 'back-end' people who would rather spend their energies optimising a SQL query than worrying about how the results might be rendered on screen, since "that's for the UI guys to take care of..."
But perhaps the biggest reason is:
- No-one's told them or shown them how.
And if we are indeed talking about people who otherwise won't actively go out and learn for themselves, not only can you discount the likelihood that they'll take a book home, you can also rule out them picking up new techniques from reading the weblog of an influential and knowledgeable individual. Perhaps you even know people who have been working on the web in one way or another for a number of years who would respond with: "What on earth is a weblog?"
When Simple Mark-up Causes Maintenance Woes
When I look at the mark-up on a well-conceived site, I understand the structure intuitively - "Ah, I know what that
<h1> means… Ah, so that nested
<ul> is the sub navigation" and so on. Editing such pages is - or at least should be - much easier than hacking away at one that relies heavily on the placement of
<td>s for layout. Although the page may be 50% smaller than its old-school counterpart, and it may be simpler to edit, what happens when someone else wants to maintain the page that has been so carefully crafted?
Here's where I begin to fly in the face of common consensus - it being that if you code to web standards, it makes for easier maintenance of your site to those joining a project later. My experience has, thus far, shown the opposite to be true. It pains me to admit this.
No matter how simple the mark-up is, cleverly crafted pages can leave some people struggling. "Er, what are all these
<div> thingies? I don't get it ... why can't we use a table like everyone understands?". And just wait until they get a load of the Box Model Hack in your CSS file (or any other CSS hack, for that matter)! It's not unknown for sites/web pages to go far forward in terms of standards compliance, only to be brought back down a level because the new, simpler methods are not properly understood by those who may need to maintain these pages.
Change Come from Within
From my experience though, once people do finally 'get it', they wonder why they didn't do things more simply before. There is a definite 'Eureka!' moment, but if the person or persons concerned do not want to learn, you may never reach it. So they have to be told, enlightened - it needs a push on your part rather than a pull on theirs. But that's not easy either.
Enforced training is not always gratefully accepted though (unless it involves a trip abroad and a nice expense tab, of course) and often the training is hideously outdated. The techniques described in Zeldman's, King's and other people's books are not taught in any residential training that I have ever seen. The latter are still stuck in the old school "Let's give 'em
<font> tags and nested
Bottom line is - there are still too many people who only understand the old school methods of web design, and only when these people can get enthusiastic about adopting new methods will we be delivered to the promised land of perfect mark-up.
No Easy Solution
"So train them yourself!" I hear you screaming at the page. Perhaps it should be up to individuals to lead the way after all, but this may not be possible for a number of reasons:
- no time to train (everyone's busy)
- no skill in training (it doesn't matter how knowledgeable you are if you bore everyone to death)
- someone more senior than you doesn't want to hear it from an 'underling'
- it's just not a sexy and exciting topic for a lot of people!
Perhaps we need to send uninitiated developers to a 'Designing with Web Standards' boot camp (are you listening Jeffrey?) and leave them in the hands of a capable trainer who can be trusted to enthuse and inspire others to greatness. Any training course today is liable to be of the "Here's a
<font> tag, use it to make nice red text" variety - and that doesn't help anyone.
So what's the solution? Unfortunately, I don't come with the answer, only my very evident frustrations.
One comment I received prior to publication was that "it has to come from the top down". If management says this is how it should be done, and there are financial gains for doing so (a higher annual pay raise, for example) then you've got one big incentive right there.
The dream of writing mark-up based on standards is not a pipe dream, but it can be a nightmare getting other people to follow suit. I just hope that venting these frustrations might spark conversation among passionate people on the web about what can be done. In the meantime, if anyone can prove me wrong about the standard of training available (particularly in the UK) then I'd love to hear from you! I could fill a room with developers who are not yet up to speed on these new techniques - just don't bore them to death in the process, yeah?
The text of this article ©Copyright 2003, Ian Lloyd, all rights reserved. Everything else falls under this site’s standard license.
Jason Kottke has written a thoughtful piece on the difference between standards and semantics, and if you're just learning this stuff by way of my site (heaven forbid) or some of the many others out there, it's worth your time to read it and consider his points.
Let me start out by saying that Jason is absolutely correct. You are allowed to use
<font> tags in your valid XHTML. You are allowed to continue designing with tables. As long as you lowercase your tags and watch your nesting, there is nothing stopping you from building your XHTML sites without a lick of CSS.
But if this is all you're doing, you are like the driver of the VW Beetle carefully pulling to a stop at the light, failing to move for the Mack truck barrelling toward him at 120km/h. Sure he's following the letter of the law, but the light was put there for his safety. He's completely missing the spirit in which it was written.
The W3C has a commitment to backwards compatibility. XHTML is meant to work back to 4.x and older browsers. (Which is debatable given the 2.0 issue, but please, let's focus.) This requires a certain amount of support for deprecated elements. Tables will always be with us, because they were created for tabular data; you will be able to author table-based sites for years to come. But stay with me now, here's where it gets tricky.
XHTML is a clean slate: it's HTML, but it's XML. It's the best of both worlds, but it's halfway between. HTML has a long and ugly history of visual hacks, proprietary extensions, and general abuse. The browsers that support it are lax, overly tolerant, and encourage sloppy coding. XML, on the other hand, is defined by a tight set of rules; it is structurally complex, rigidly demanding, and doesn't offer any presentation cues whatsoever. It is completely reliant on external styling, and in this case that styling happens to be CSS.
The move from HTML to XML requires a huge shift in developer mindset. There are a lot of obstacles to overcome yet, not the least of which being solid browser support. We've only started down the road, and XHTML is how we'll get there. Here's the path, in 3 steps:
- XHTML allows for easy introduction to proper coding methods by weeding out bad techniques, while requiring no more than a simple change in syntax. Drop your tags' case, watch your nesting, and close everything. Easy. The first step is one which most are willing to make because it requires the least.
- Once developers latch on to this, they will realize sooner or later that the next step is to move toward a separation of content and presentation. This is where most are stuck today, and until the baseline browser moves up a generation from 5 to 6 (or 7), there will generally be dissent and lack of cooperation. Some are aware of this step, some aren't, but it's the next big paradigm shift and it has already started happening en masse.
- After making the prior transition, the next step is full-on XML rendering, which is going to be a real doozy. Validating only your home page and allowing lax code on other less-prominent pages is a practice that will have to stop. What happens when the switch is flicked between HTML rendering (which, chances are, is how your site is being parsed right now) and XML is that if you have an error in your code, just the slightest little bug, your site won't render at all. You will see a happy little error message, and that will be that until you fix it. Seems a bit harsh doesn't it? Well, consider that programmers have been dealing with compile errors from sloppy code for decades; welcome to their world. Not only does your own code have to pass muster, but code from third parties and external sources must play ball too. This one will take years, folks.
Standards, as Jeffrey Zeldman notes in the highly recommended Designing With Web Standards, are a continuum. You've gotta get on the bus sooner or later, but once you do there are a lot of stops along the way. You've made the transition to XHTML? Great! How's your separation of content and presentation coming along?
Don't stop with the easy stuff, this is one rabbit hole that goes real deep.
You've got help along the way - hey, I'm just finding out about this stuff myself. I don't have all the answers, but the more I read the further I go into Wonderland. There are a lot of very knowledgable authors publishing on the subject, and as long as you keep learning, sooner or later we'll all get there.
overflow: auto;on each comment block (
.comments-body) I finally ended up using
overflow: hidden;Any URIs longer than so get chopped at the right of the comment block, the magic number being around 60 characters. Why
auto? After all, the latter would add scrollbars, ensuring truncation doesn't occur. But the more I thought about it, the more I realized that truncation was exactly what I wanted. URIs are the only bits of text within
.comments-bodythat could possibly be affected, so why not truncate? It's cleaner looking, enough of the link shows up for the user to get the idea, and they'll still get the full URI in the status bar. Otherwise I'd have to live with ugly vertical and horizontal scroll bars in any comment block that needed them, and that just looked odd. Which just goes to show that there's always more than one way to tackle a problem.
I can't sit still, and not because I'm excited or restless. I'm uncomfortable.
The human body wasn't built for the long hours the average white-collar worker puts in front of the screen daily. A lot of ink has been devoted to the subject of keeping yourself healthy while in front of the computer, so here are a few personal notes on the subject.
RSI, or Repetitive Strain Injury, is something you're most likely familiar with. Long periods of typing or even using the mouse cause sore tendons, and without proper care your hands and arms can become almost unusable.
The funny thing is that it comes and goes. I've seen reports that suggest it may not be permanent. My own experience has been that as long as I'm not over-doing it and pushing myself beyond a comfort limit, the pain will ease over time. Long stretches of intense work obviously further the problem, but a few moments of rest after a marathon-length e-mail and the odd break away from my desk throughout the day go a long way toward healthy joints.
But a recent problem that I'd never encountered prior is, for lack of a better term, numb ass syndrome. I just can't sit in one spot for long. I go back and forth between crossing my legs, placing my feet flat on the floor, hunching over, leaning back, and just about everything in between. No positions are comfortable. The only remedy is a good long walk.
It didn't used to be like this. I've recently changed some habits, and the unfortunate result is that I end up stuck in a chair for far longer, and with far fewer breaks. My saving grace used to be half-hour long excursions to get lunch around the noon hour. I've been taking fewer of those, and I'm paying for it.
Some quick Googling reveals the following tips for relief of numb ass. As well as these, I'll be making a point of getting out around noon of every day for at least a few minutes. We'll see how this goes.
- Avoid sitting for prolonged periods of time, as this causes postural strain.
- Take frequent breaks to stand up and stretch.
- Place both feet flat on the floor when sitting.
- Avoid crossing your legs - this habit can lead to an imbalance in the pelvis.
- Sit back on the chair. It is very important that you give your back the proper support.
- Adjust your chair so that your knee is slightly higher than your hip. If your chair is not adjustable you will need a footrest.
- Don't sit in a chair that is too large, too high or too low.
- Avoid leaning forward with your back arched. Work toward not being a slouch.
We, the undersigned, request that the developers of JAWS® for Windows please provide us a free/cost effective, stripped down testing alternative. This will lead to more websites being tested to suit your software, resulting in an increased audience and hence increased requirement for JAWS.
Signed. I suggest you do the same.
DMXZone publishes an interview with yours truly (goofy head shot and all), and thoughts on rich-text web-based editors.All things considered, I think my photo came out okay . That's right, I got the DMXZone treatment that we're all coming to know and love. Bruce Lawson asked some great questions, and I think I managed to give some rather thoughtful answers in my interview. Go read a few scattered thoughts on coding CSS, the on-going success of the Zen Garden, and Comic Sans MS. Meanwhile, Molly may be over-doing it just a tad, but colour me flattered. § A recurring thought of mine that might be worth consideration, if you're a coder: there exists a graphical, rich-text editing component by a certain software giant out of Redmond that comes bundled with its flagship browser. This component has caught on like wildfire thanks to its price and universality. Many large-scale content management systems, weblog tools, and other web-based applications use the component to allow a familiar Word-like editor for their, well, less-than-technical clientele. The problem with this component is that no matter how well-intentioned a page author is, they are shackled by the markup that it spits out. And it's ugly. Oh, is it ugly. <FONT> tags, unquoted attributes, the whole nine yards. Alternatives exist that allow customization of the code, but they're pricey and can't compete with a free component in this space. A CMS vendor already charges a certain price; adding an extra $159 per license just for an editor is not an option. It occurs to me that an open-source, hackable version of this component would be an incredibly Good Thing for broader standards adoption. Offering it free for commercial purposes would ensure consideration, and if it were easily hackable for custom purposes, it might be integrated in a heartbeat by a huge number of very expensive and well-deployed software systems. I can't give you any leads for Google. I don't know what the component is called, and I can't remember who provides alternatives. I'm sure someone reading this site knows what I'm talking about and can fill in that gap. My point however is to say that if an open alternative existed, a lot of people would be very happy, and the creator might see a very large amount of indirect benefit as a result. It's just a thought. § ]]>
On Netscape Navigator 4.x and the Zen Garden
A reader asks:
I was looking at the (beautiful) designs in the Zen Garden a moment ago and thought I'd throw Netscape Navigator 4.8 at them. Nothing! (So far as I can tell) The textual content was all there, of course, but not an iota of style.
Is there any prospect of getting a version of the Zen Garden page to 'inline' the styles so we can see how 'backwards compatible' they are?
(I have sites where a significant number of the visitors are locked in to NN4 and other old browsers…)
A responsible designer considers his/her audience. If a big chunk of your users run older browsers, you'd better make sure you're giving them something to look at.
In the case of the Zen Garden,
@import prevents NN4 from trying anything foolish. It thinks it knows CSS, but it just can't keep up. So I (unabashedly, and unapologetically) serve up an unformatted XHTML document to NN4.
Well, I happened to have the Garden files loaded in front of me when that e-mail came in, and wouldn't you know, I got curious myself.
Here's what you do: load a design, any design. In the URL, you'll see 'cssfile=/0xx/0xx.css' plus some other junk. Change 'cssfile' to 'nn4', and the style will then be pulled by a
<link> as well as an
It's not pretty. You'll notice some of the designs won't even start to apply themselves - NN4 chokes on the Box Model Hack, so its CSS engine seems to die when it encounters an instance of it. Don't even bother trying any of this in a standard-compliant browser, it'll load the same stylesheet twice and really make a mess of things.
I'm always sorry to hear about anyone stuck supporting this relic; sometimes I'm forced to as well. As Zeldman points out in DWWS, transitional layouts are still very necessary in real-world situations. Netscape Navigator 4.x is Mostly Dead, but if we learned anything from the Princess Bride, it's that Mostly Dead also means Partly Alive.
Despite mainstream sites and their continued misguided efforts at being 'backward-compatible', the consolation is that NN4 usage is at all-time lows and rapidly fading. According to Upsdell, current usage is hovering around 1% and shrinking, down from 3% a year ago. If that's not insignificant, I don't know what is.
I'm currently subscribed to www-style, the W3C's mailing list for CSS development. CSS-3 is being developed this very moment by engineers and programmers. Why aren't a few designers involved in building a language meant for style? I honestly don't know. Maybe none of us were ever asked. Maybe none of us ever volunteered.
Mike Pick started a wish list today with linked text boxes and alpha-channel runarounds, two features he'd like to see carried over from the print world. Both are logical to the designer, and already work in existing software applications. Here, then, are a few more to add to the pool.
Visual design is all about proportion. If I have to guess at arbitrary values for text blocks of varying lengths, I can't properly design how they relate to each other. I may want
#elementTwo to be 500 pixels high because
#elementOne is, but if the user has a different default font size than what I designed for, my plans go out the window.
If I was able to apply
height: inherit(#otherElement); to a specific element, the problem would be solved.
Better Vertical Alignment
vertical-align property has been around since CSS level 1, but it's currently a poor concept in general use. You may only apply it to inline elements (and later, table-cell elements) — we need block-level vertical alignment too, guys. Why can't we apply it to both?
Credit where credit is due: CSS handles type really well right now.
letter-spacing attributes and
first-letter selectors go a long way toward addressing what designers traditionally do with type. But since there's always room for improvement, here are two things I wish to see addressed. Compare the following:
It's possible you're scratching your head and wondering the difference, but trust me, typography geeks will see it. You may only see one intended effect, but there are two problems (assuming the size is the same!) with this demonstration.
The first is that I have no idea which font the top word renders in. Theoretically, you should be seeing Helvetica. But if you don't have it installed, chances are you're seeing Arial instead. The fact that I have to guess at this highlights a big problem. Typefaces are important, and to some designers, having to dish up Arial as a substitute for Helvetica is almost as reprehensible as serving Comic Sans as a substitute for Caslon. This problem isn't really the W3C's to solve, but someone has to figure it out.
A proprietary solution exists in Microsoft's WEFT, but when was the last time anyone actually used it? Thanks to licensing issues involved in embedding fonts, the whole process of selecting a character subset from a font that's actually safe to embed is almost onerous enough to invalidate the method.
The second problem with the above example is something the CSS working group can address. Notice the difference in spacing between the two words? The top is loose and looks about as good as setting type with any imaging program before adjusting. The second is tightly-kerned and far more refined. In Photoshop, as with any high-end design program, I can adjust the space between each letter individually. Yes, this is important.
While kerning in the style sheet would quickly become a burdensome task for any longer passages — and really, who kerns body text? — I should at least have the option of adjusting my display text; that is, my headlines. A possible interface might look something like
kerning(5): -10, +5, -20;. The first value would apply to the space between characters five and six, with the subsequent values affecting those between six and seven, and seven and eight, respectively. Units could be percentages of an em, or for maximum obfuscation they could be full em values (and the designer would just have to put up with three-digit decimal values).
What do you want to see out of CSS? What kind of functions do you find in traditional design software that you wish existed in CSS? If the list grows to significant proportions in the comments, I'll consider submitting some of these to www-style.
Nic Steenhout is a long time disability rights activist. He has been the director of a Center for Independent Living for several years. CILs are non-profit, non-residential advocacy and service organization operated by and for people with disabilities. He has been interested in web accessibility issues since images first came in the picture (pun intended).
Accessibility on the web raises questions, disagreements, and passion. Let me tell you why I personally cannot compromise on accessibility.
First, let me point out that I am a person with disabilities. I have several disabilities, but the most obvious is that I use a wheelchair. I do not have a vision disability, but have more than a handful of friends, employees and consumers who do. I cannot help but draw parallels between my experience with brick and mortar stores’ lack of access, and my friends’ experiences on the web. I can’t get in the building, they can’t get into the website. Different, yet similar. Let’s continue.
It’s Your Responsibility
Why is accessibility important to you, the designer? In many cases, it’s the Law (for US based companies, at any rate). While there is currently one case creating a precedent against the Americans with Disabilities Act applying to US based online businesses, this will likely change in the near future. The spirit of the ADA is not being followed by judges who see it as a brick & mortar law, when it is in fact a civil rights law. The disability community is working hard to push one that would represent that aspect. But the ADA is only one law that addresses online presence; there is also Section 508 (of the Rehabilitation Act). I won’t go into details of that, but basically if the group you are working with receives federal funding, they had better be compliant.
If you’re only the designer, why does it matter if your client insists on a non-accessible site? Consider this: in brick & mortar lawsuits it’s common practice to sue the owner as well as the architect, contractor, and anyone else involved in construction of the building. It’s only a matter of time before non-accessible sites will start being named in lawsuits. You can bet that as the site’s designer, you will be named in the suit as well. You have a responsibility to make accessibility happen; don’t ask your client, chances are they don’t even know what you’re asking about. If you develop solid habits when you design, it’s easy to make a site comply not only with priority 1, but WAI priority 2. (Priority 3 is much more finicky, but not impossible) Feed your clients accessible websites, perhaps even despite what they think they want.
…but it’s such a small market! It’s easy to dismiss accessibility concerns with a statistic. You may have good eyesight, but how's your Vision? Approximately 10 million people with visual disabilities (blind and low-vision) live in the US alone. And the market share is growing, especially considering many folks prefer to shop online for products and services. An accessible web site is so much easier than fighting with transportation and figuring out a product at the store. Also consider that these 10 million people have family and friends who will often patronize a particular business because they know it’s more accessible to their loved ones with disabilities. And let’s not forget we live an aging society where soon a large percentage of people will have vision issues.
You Don’t Want to Consider Accessibility!
But how can we consider all cases? Some debaters are fond of using extreme imagery of folks with multiple and very significant disabilities (e.g. Deaf and Blind and paralysed “from the neck down”), arguing they will never receive the full experience that someone without a disability will. Of course not, but frankly we people with disabilities grow tired of other folks shrugging off their responsibility by using the extreme example. A little goes a long way, and making no attempt at all in this direction because “you can’t please everyone” is an excuse for the idle.
Okay! I got your attention, put that flame thrower back in the closet! Seriously, we say we’re all for accessibility, as long as we don’t have to work too hard at it. That last bit is unstated, yet comes through loud and clear in most discussions. In fairness, it is indeed a lot of work to go back into a site and retrofit for access. Just like it's difficult, time consuming and costly to remove a 28" wide door and replace it with a 32" wide door. Had the proper width door been planned for from the beginning, well, you wouldn’t have had the problem to start with!
One major issue stems from the fact that more and more frequently, we don’t have the option of seeing products at a “real” store. Products or services are only accessible online, which means a person cannot visit the physical store. Without that option, a site that isn’t accessible shuts out a whole lot of people. And whether consciously done or not, that is discrimination.
As my good friend Dan Wilkins says: A community that excludes even one of its members is no community at all. Of course, this is not a question of community, but one of business. I would argue that without the community supporting the business, there is no business. But that’s another discussion.
Challenges to Consider
I was asking Denise, a colleague of mine, about the problems she encounters on the web. She pointed out that sites using Flash don’t let her go anywhere. And while there may be more accessibility features in the most recent versions of Flash, it’s still not really an accessible technology. She was also telling me that a number of sites have a splash page with one big graphic, and no alternate text or anything to give an inkling as to what she is supposed to do from there.
What I found very telling is that when I asked Denise if she could give me a few websites that she found particularly non-accessible, she couldn’t. Because if it’s not accessible, she moves on to another site! (and promptly forgets where she was). These companies never had a chance to even showcase their products to her.
Drawing another parallel with brick & mortar, I’ll tell you about Pete. Pete was my car mechanic in Illinois. Pete is probably one of the best, most affordable, and honest mechanics there is. A gem. But Pete’s garage was not accessible. It had one step in front of the entrance. It’s not much, only 6". A mere step for you who are walking, you won’t even notice it. Yet it means that I can’t get in. And in the middle of winter, when it’s -20°F, or in the middle of summer, when it’s over 100°F, having to wait outside is not only unpleasant and inconvenient, but can be outright dangerous.
I asked Pete to put in a ramp. He then asked me, “why should I put a ramp in? You’re the only customer I have in a wheelchair.” I asked him why he thought that was. Of course if your potential customers can’t get in, you won’t have them as a customer! He agreed to build the ramp. And when he did, I recommended him to all my friends. Pretty soon, his customer base increased by nearly a dozen people. Not bad for investing $300 in cement.
The point of this is that while you can track who visits your site(s), you cannot track if they have a disability or not. So you can’t excuse accessibility by claiming you don’t have any blind visitors. But you can rely on the fact that if you build it, they will come. Word of mouth is big in the disability community.
Spreading the Word
Of course, awareness is a big problem. The issues surrounding the need for web accessibility seem to be a closely guarded secret. Frankly, before I landed in this wheelchair, I was blissfully ignorant of accessibility issues. I am not faulting anyone who doesn’t know about the issues for not fixing their sites. But the moment one becomes aware, one must think about starting accessible/universal web design.
I also fault people with disabilities in all this. If accessibility is such a secret on the web, it is in part because we don’t speak up enough. I have no compunction telling someone when their site (or restaurant, or…) is not accessible, but I find that a majority of other folks with disabilities aren’t that vocal. If more people took the time to email site owners with faulty design, we would see the word and requests for accessible sites grow.
On the other hand, having been on the receiving end of the rejection that usually follows my requests for accessibility, I know that it is difficult to keep on advocating. Typically, email asking for a site to be more accessible are either ignored, or sent canned answer like “thank you for bringing this to our attention, we’ll look into it.” Months later, of course, they haven’t changed a thing. It’s a brush off. Every once in a while, we get an outright we don’t care about it, shove off (in so many words or not).
I probably could go on and on and you wouldn’t be the first one to rightfully accuse me of having diarrhea of the mouth/fingers. Let’s draw this to a conclusion for now. Here are a few parting thoughts/recap:
- Making accessible sites is not that difficult.
- Even if you opt to only fulfill WAI Priority 1, you’ll have a site that is at least usable.
- Making accessible sites is the right thing to do.
- Shunning (on purpose or not) people just because they have a different way to do things is bad, and you’re not bad people.
- Making accessible sites benefits everyone.
- There are more and more people surfing on devices that need a little help, like PDAs, cell phones, etc.
- Making accessible sites brings in $$$.
- In today’s market, I cannot accept the argument that a market share is too small to be worth catering to, especially considering the very low cost of building accessible sites. Every dollar in sales is important to today’s companies.
- We must pass the word about accessible/universal design.
- Until more and more people demand accessible sites, and more and more designers demand tools providing accessible design features, it won’t happen on the scale it really needs to.
For more on the subject, here are some sites of interest:
- SitePoint on Accessibility
- W3C’s Web Accessibility Guidelines
- Section 508 of the Rehabilitation Act
- A List Apart on Accessibility
- Web Page Backward Compatibility Checker (which can give you an idea of how your site looks on text only browsers)
- Dive Into Accessibility
- Building Accessible Websites by Joe Clark
- Designing with Web Standards by Jeffrey Zeldman
So… That’s that for now.
The text of this article ©Copyright 2003, Nic Steenhout, all rights reserved. Everything else falls under this site’s standard license.
File this one under goofy fun.
One of the more interesting ideas popping up in discussion of the Zen Garden has been standardizing a set of markup for weblogs. Since the data types contained within a weblog are pretty consistent across the board with few deviations, a central repository of CSS-based design would be possible. You could design a style sheet for my site without ever having seen it, if our markup matches.
While this wasn’t a goal in either project, a quick bit of inspiration last night led me to try loading some Zen Garden .css files into this site to see what would happen. I’ve made a couple of small changes to mezzoblue’s
ids to better illustrate this effect, but each change was in an effort to move to more meaningful names:
#linkList, and so forth. The fit isn’t perfect due to wildly different data, but hey, it ain’t bad for hijacking style sheets which were never intended for this purpose.
Anyway, enough theory. Take a look:
- arch4.20 (original)
- Wicked Grove (original)
- Gothica (Original)
- Atlantis (Original)
- White Lily (Original)
And a couple of non-official Garden designs that work in this context:
In Defense of Fahrner Image Replacement, my first article for Digital Web Magazine has been published. Feel free to discuss in the comments.
Particularily good comments in the past 24 hours:
#6 — “Most browsers are configured not to print background images, so your headers may come out blank in the print (this is also true of people who surf the web with images disabled in their browser). The first can be solved with a print stylesheet (does IE5/Windows support these?) but the second is a bit nasty.” — Simon Willison
#12 (on a new FIR variant) — “The best part is that this technique works in JAWS (tested, and approved), and there is no additional hacks or markup needed in your HTML or your CSS. The text-indent takes care of it all.” — Mike
#25 — “Regarding the recipe example: the first person I thought about on the accessibility side was not the blind user who is read to, but the low vision user who may be using a visual browser and text zoom” — Ed Nixon
#33 — “There are a significant number of people who for good reason surf without images. The primary reason is just download speeds over slow connections (which I hear quite a bit from English and other European surfers) and the over abundance of images on the web. Then there's privacy concerns, filtering, and lastly those people who can't take advantage of visual media.” — Michael
#39 (on solving real-world problems before the theoretical) — “What's the point of discussing which materials to use for building homes on Mars if we did not yet figure out how to get there in the first place?” — Didier Hilhorst
#42 — “…let's just say that JAWS and Windows Eyes are currently the top two screen reading applications on the market. As having a near monopoly, they are free to to handle things just about however they want. […] Getting their software to play ball with CSS is *way* at the bottom of their list, and that is a problem.” — Nic
#53 — “I'm posting this comment from Lynx right now. It's a beautiful thing when even a text-only browser has full access to my site, and it's actually usable.” — me
There’s good news, there’s great news, and there’s Amazingly Great news. The good news first.
mezzoblue’s conversion to an XHTML/CSS layout would have happened eventually, but it was rushed for a specific reason: I’m getting paid for it.
Which leads to the great news. We all lamented the loss of glasshaus when their parent company went belly-up. Useful titles like Cascading Style Sheets: Separating Content from Presentation became hard to find, and we lost a valuable resource.
Apress is picking up the pieces. Right now, at this very moment, the original authors of Separating Content from Presentation are hard at work revising their original drafts, and a second edition is expected out later this year.
And this is how the two are related: I am contributing. mezzoblue is my case study, and this site and the process of building it will be included in the second edition of the book. More will be posted as it develops.
And speaking of writing assignments, later this week my first article for Digital Web will be published. As the coordinator of a project that relies heavily on the Fahrner Image Replacement technique, naturally it’s near and dear to my heart. It gets its fair share of bruising from detractors, so my article goes a long way toward explaining why we need it, and how to work around the problem spots.
Which leads to the Amazingly Great news. We may have finally beat the accessibility problem, and dropped the superfluous
<span> all in one shot.
Two great minds, Seamus Leahy and Stuart Langridge have each independently come up with a solution that relies on
overflow: hidden; to hide the text. For the sake of a name, I’ll tentatively dub this the Leahy/Langridge Method, although Todd and Doug should be credited for their initial work. FBLL Method anyone?
A quick box model hack ensures these work in IE5+, but further browser testing is necessary. These look super promising, and both should be credited for their original thinking.
(to be fair, Seamus approached me two weeks ago, so he was First if anyone’s counting. But let’s not go there.)
Can I share something with you?
It’s a bit of a dirty little secret.
So there’s this guy, see, and he created this project. And lots of people liked the project, and he became known for the project. And all was well, except that he was living a lie.
See, his project involved this new-fangled technology that some people like and others don’t and some people are afraid of and others aren’t. But he wasn’t even using this technology himself, except in the ‘bad’ way that he was trying to free everyone else from!
Okay, so there’s only so far I can take the figurative speech. Mezzoblue is now CSS from the top down, with minimal, as - semantic - as - it - gets - while - still - looking - as - good - as - it - does markup. This has been on the backburner for a long time, and should explain the relatively infrequent posting of late.
What, you assumed it was all along? You’re not alone, most did. But it wasn’t. It was as old-school as they come. Have a look, if you don’t believe me.
I’ve fixed some things, broken others, and generally this whole site is in a state of transition right now. You’ll still find some pages on the old code base, but I’m getting around to it. While I can’t exactly claim to be re-designing in public, I am on the hook for a few loose ends yet.
- Fahrner Image Replacement heavy, especially the top header.
- Your load time should be faster; I’ll have to crunch numbers, but I believe I've dropped from a 100k+ home page to around 65k — 75k, after considering all the external files. Not quite half, but not too shabby.
- Image improvements here and there. You should be noticing this by now. I’ve solved some of the problems bugging me, and done some close work on the type and alignments.
- XHTML 1.0 Strict. Comments pages won’t be expected to validate, but the rest of the site eventually should pass with flying colours.
- View my source. Go on. Live a little.
- Or view it unstyled.
IE6, Firebird, and Opera 7/Win give me thumbs up, but your mileage may vary. Any nit-picks (especially Mac browsers) should be accompanied by URLs to screenshots, please.
There. One more black spot coming off my record. I’m getting dangerous with this stuff.
On constructive criticism, and XHTML 1.1 vs. MIME types.
It’s great having people pick apart your work with unsolicited advice, isn’t it, Andy? And by great I mean it’s as much fun as having your eyes gouged out with lobster forks. And by fun I mean cringe-inducing.
As a veteran of the odd “doing work for the Common Good and being taken to task after doing something wrong” paradigm, all I can offer is a sense of solidarity, and these words of advice: At the end of the day, if you change one thing to make one person happy, you will inevitably have changed the very thing another was perfectly happy with.
And a word to those who are quick to hit the Contact button. On any site. Honey first, to make the vinegar go down easier. Don’t drown your message in unpleasantness, or it will go unheeded. §
While there are purportedly no real-world benefits to using XHTML 1.1 in 2003, it can’t hurt to start experimenting now.
What I want: a way to serve up
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" /> selectively to browsers that can handle it. I’d like both ASP and PHP variants. I tried someone else’s PHP on the Zen Garden a month or so back, but I never got it working properly; does anyone have a link or two on this? §