Archive for the ‘Web Standards’ Category
« Older Entries |Usable Accessibility
Tuesday, April 14th, 2009
Many times focusing on standards and guidelines puts the focus on the technical aspects of accessibility, and the human interaction aspect is lost. This problem can be avoided by adopting the broader definition of accessibility as a guiding principle. Instead of focusing only on the technical aspects of accessibility, it is important to recognize that usability is also an important aspect of accessibility. Consciously addressing ‘usable accessibility’ helps clarify the difference between what meets minimum accessibility standards and what is usable by people with disabilities. Shawn Henry
Following my trail of articles I read through this morning to find this quote:
- Accessibility is more than "possible to access"
- Usable Accessibility: Making Web Sites Work Well for People with Disabilities
- Accessibility Primer for Usability Specialists
There were all pretty good reads, if I had to pick 1, I’d say definitely read through the second one, it covers all the bases for you.
I think when building a site or application with accessibility in mind my thoughts are usually something like” "I’ll do the best I can to make this easy for the blind to access, but essentially there’s only so much I can do, it’s gonna be tough". I understand the need to get out of that mind set, maybe investing in a screenreader is the answer?
I’m not entirely sure quite yet how to create a better user experience for a disable user. Especially since I still can’t get the damn mac voice thing to function in a useful way. Hopefully that answer will come sooner rather than later.
Tags: accessibility, quote, ui, usability
Posted in Web Standards | 2 Comments »
Web Standards and the Shower Curtain
Wednesday, April 1st, 2009
Have you ever bought shower curtain rings and wondered if there were enough in the package to fit your shower curtain? Probably not.
Why is that?
Its because the shower curtain industry has standards, just like the standards we’re trying to implement on the Web. At some point in the process of creating shower curtains, an industry leader made a decision as to how many holes would be in that shower curtain. It filtered through the industry and became a standard so you, the consumer, didn’t have to worry if there were enough rings to hold up your curtain. There are. And it’s because of standards.
Barriers to Entry
Think of the millions of different industries out there that would be in a constant state of confusion if there were no standards set. Every time a new player would come into the business, they would be reinventing the wheel for their product (sound familiar?).
Unfortunately, the cost of entry to the Web is very low. It’s available to everyone, whether you’re aware of Web Standards or not, you can get in and do whatever you want, go to blogger, WordPress, Google sites, etc. There’s no real governing body saying No, you can’t put up a Web site with invalid code
. Honestly, nothing happens if you use crappy code, you can still get a nice looking site that’s all decked out in tables and font elements.
The barriers to entry are so low for the Web that no one needs to be aware of the standards. This is a culture that needs to change.
Accountability
Up until, maybe a month or two ago, I was a huge pusher of education for the client, cram as much knowledge as you can into their heads. But I’m starting to lean the other way. Where does the education need to stop and where does the industry take over in enforcing standards?
User-centric design is such a big deal right now, but we’re not bringing it into our business model. We design our sites with the user in mind. What does the user want? What will they being thinking? Where do we want to guide the eye?
We all know that the user average doesn’t care about paragraph tags, blockquotes and divs. But guess what? 95% of the time, the client doesn’t care either. And you can say that caring about that is the cost of having a web site, but it’s really not. Not with barriers to entry being so low. A small company doesn’t need to know this to be successful.
I just had a very educational back-and-forth with some system administrators (server guys) where I truly felt like a client with the attitude of: I don’t care about the innards of the server, I just want it to work. And it was finally pretty clear to me about how a client, who is not Internet savvy, and just wants a Web site to work. They truly don’t care, they just want it to work.
The Ideal Client
The ideal client, wants to learn about the XHTML code we’re using to build the site. They’re curious as to why it’s best practice to separate out a presentation layer. This is great when they actually want to be educated, I love these clients; unfortunately, they’re few and far between.
Don’t get me wrong, I’m not saying the education is a bad thing, I think it’s great and I’d love it if clients cared about semantics and proper document structure. But the reality of the situation is that we need to pick our battles and move some of the burden off the client and back onto us (the developer).
The CMS
Content management system and the developers need to take on most of the burden. This is where the code is produced, this is the output, and this is where the choke point is. Most content management systems I’ve come across are still outputting multiple line breaks instead of paragraph elements (they’re elements, not tags). With how far we’ve come in Web Standards, its not acceptable anymore to just be proud that you’re not using tables for layout. The best one I’ve seen, so far, has been WordPress (my CMS of choice). But the vast majority of “easy” CMSs are still outputting awful code.
A client should not be asked to do any more coding than they have to do in a Word document, unless they want to or there’s an error in the CMS.
The Problem with Themes
The problem I have with WordPress/MovableType themes and default templates is all the extra code included to make things flexible. Code inserted completely for presentation purposes.
The first 5 lines of code in the body of a default MovableType Blog:
<div id="container">
<div id="container-inner">
<div id="header">
<div id="header-inner">
<div id="header-content">What I cut it down to before I start coding
<div id="branding">If we’re going to make the barriers to entry so low that anyone can use these open source CMSs, we need to build them better out of the box. The same amount of theming can be done with half the amount of code.
What clients should know
There are certain things that a client needs to be responsible for when managing a Web site. Anything having to do with the content, properly floating images left and right, bold & italics (if there’s no WYSIWYG editor), maybe some light positioning, things like that. They need to be educated on accessibility and how necessary alt text is when they’re inputting an image into content. They need to be educated on relevant topics that they’ll deal with on a day-to-day basis, not the importance of a DOCTYPE and making fewer HTTP requests (these are burdens of the developer).
The point of this
What am I ranting about? Shower curtains? The point I’m trying to make here is that there are certain standards that we, the Web team should share with the client, but they don’t need to be experts. If they were, they wouldn’t need us. Inform your clients about Web standards, let them know they exists, answer any and all questions they have, and correct any misconceptions, educate them as much as they need. The Opera Web Standards Curriculum is a great resource for any client to have, maybe giving them that should be our newest standard.
You’re the client, you don’t need to think about how many rings there are in your shower curtain, it just works (ok, maybe you’re the user, but you get the point).
P.S. There’s a big learning curve with the Internet and it’s even harder since it constantly changes; you’re clients are not stupid, they’re just confused.
Now if we can only agree on spelling it “Web site” vs. “website” we’ll be in business!
Tags: business, content management, design, ui, Web Standards, Web Standards Curriculum
Posted in Web Standards | 5 Comments »
Centering an Image
Tuesday, January 6th, 2009
<div align="center"> is deprecated.
It’s been deprecated for a long time, but it keeps creeping up for things like center aligning an image.
Another popular way to do this is to wrap an extra div around the image and set the text alignment to center. This creates (as you might know, I hate), an added layer of XHTML code that you really don’t need.
.image-wrap{
text-align:center;
}This goes back to one of my pet peeves about using too many divs. Here’s what I came up with:
CSS
#content-main img{
display:block;
width:auto;
margin:auto;
}That will center your image, and of course you can add a class in if you don’t want all your images centered.
Just a quick tip today, as I’m getting back into the swing of things after vacation. I hope everyone had a good holiday season.
Tags: CSS, xhtml
Posted in Web Development, Web Standards | 6 Comments »
Header and Footer in the Semantic Web
Thursday, November 20th, 2008
A couple years ago I read through Andy Clarke’s Transcending CSS and it really made me think about semantic naming conventions I had otherwise taken for granted. By now, most of us (at least people reading this blog) practice using semantic markup and meaningful class & ID names. But can we do it better? Probably. There’s always room for improvement.
Andy’s book was (still is) filled with many techniques that I hadn’t seen before. I had fallen into the trap that many designer/developers fall into. I was doing things just because I had seen other others doing it and assumed it was the best way. This is why most people still use <div id="wrap"> even though it’s usually unnecessary.
I’m mainly talking about semantic div naming. Specifically "header" & “footer”. I’ve had a while to think through this, so bear with me here.
Basic semantics
The basis of the semantic web is to look at content first, and then decide which element to use, based on that content. Using a list for navigation rather than a paragraph with line breaks (for a brutal example), using an h2 instead of regular bold text, things like that.
Semantic elements extend beyond just XHTML, it extends into your class and ID names. We’ve all seen articles telling us to use names like "error", rather than "red" and "highlight" rather than "yellow". These names are more meaningful and leave room in the future changing the CSS behind them, while still keeping them meaningful.
The same principle should be applied to ID naming, but for some reason, it hasn’t fully taken off. We’re using names like "header", "footer", and "sidebar" in our every day development. On the surface they’re fine, but in the long run they can really hinder future design changes.
What information can be gathered from these div names?
Header
From the name alone, you can tell that this element is at the top of the page. From experience we can assume it also contains some kind of information about the site (name, logo, tagline, etc.). But it’s definitely at the top of the page.
Footer
Footer tells us this is located at the bottom of the page.
Sidebar
The name "sidebar" contains no information about what it contains, just that it runs along, either the right or left side of the page.
The popular way
<div id="header"></div>
<div id="nav"></div>
<div id="main"></div>
<div id="sidebar"></div>
<div id="footer"></div>What if you want to put the logo somewhere else? Maybe your copyright and contact information isn’t stylish at the bottom of the page anymore? Or you just want to move that sidebar where your "footer" is? You’ll have to rework the markup, move code around and waste time. This takes a valuable function of out CSS, you should be able to completely redesign the layout of your site without touching the markup (unless you want to add stuff, of course). That’s the true power of CSS.
Advanced Semantics
Andy Clarke proposed that we actually look at the content contained in these divs before give them labels and lock them into a role that could change in the future.
Andy’s suggestion
<div id="branding"></div>
<div id="nav"></div>
<div id="content">
<div id="content_main"></div>
<div id="content_sub"></div>
</div>
<div id="site_info"></div>My edits
I’ve made some suggested changes to this code, I’ll get into the why of that in a little while, but for now, here’s how I changed it:
<div id="branding"></div><!--/branding-->
<div id="nav"></div><!--/nav-->
<div id="content">
<div id="content-main"></div><!--/content-main-->
<div id="content-sub"></div><!--/content-sub-->
</div><!--/content-->
<div id="site-info"></div><!--/site-info-->What information can we gather from these div names? (Let’s just look at the 3 we’re talking about)
Branding
Logo, tagline, topics, information and graphics that brand this as an individual can be found in a div named "branding". Best of all, it gives no positioning–relevant information, so in the future (or present) this area can be moved and modified in any way. As long as the content stays meaningful to branding information (which is not usually something that changes in a redesign/realignment), all will be well on the web.
Content-sub
This is old "sidebar"; "content-sub" is labeled as secondary content, it can be positioned anywhere, and will most likely continue to be secondary information in relation to "content-main". And both are contained in a div labeled as "content". You can always add more elements in there like "content-level-three" to accommodate a growing site. But, I find that "main" and "sub" usually cover everything.
This will clean up your style sheet as well:
#content{}
#content-main{}
#content-sub{}Site-info
"Site-info" replaces the old "footer". The footer usually contains content about the site: archives, copyright, maybe a contact link, etc. And there’s no rule that says that information needs to be at the bottom of the page (there isn’t, I checked). It’s fine if it’s there, that’s where mine is, but in the future if you want to move it the div name will stay semantic and meaningful.
The changes I made
I made some changes to Andy’s code for a few reasons:
- I can never leave well enough alone.
- I always close out my divs with a comment telling me which div got closed so there’s no confusion in the future.
- The underscores: I switched out the underscores with dashes because I came across an article about using underscores in CSS.
In old browsers the underscore in ID and class names had to be escaped like:
p.urgent\_note {color: maroon;}Or there can be some bad layout problems. Now, this is a big "Who give a crap" in today’s web since no one uses these old browsers anymore, but I see it as a small change to my CSS to make it slightly more degradable just in case some strange user comes by. And it’s really no extra work to do this, which makes it even better.
Closing
I’ve been using this technique for a while now and I love it. When I did my last redesign, it was just a straight style sheet swap. I don’t know if anyone remembers what that looked like, but this is totally different. It was very simple, fast and I hope some readers out there give it a try.
Thoughts? Want to tell me I’m wrong? I’d love to here it.
Tags: andy clarke, CSS, semantics, xhtml
Posted in Web Development, Web Standards | 18 Comments »
Clickable Labels
Monday, October 20th, 2008
In form design, there are many things you can do to improve usability, many of which have to do with label placement. I won’t go into the depths of it, but Chris from CSS-Tricks.com wrote a good article about placement, not too long ago. Read Chris’s article here
Why read this?
This reason I’m sitting down to write this is to share a bit of usability I’ve come across on certain sites as I scour the Internet. Letting users know that a form label is clickable and will activate the associated form field.
This first came to me at the WDN conference in Vancouver last January, while I was listing to a Q&A session after a talk by Derek Featherston, accessibility guru. Somehow the topic of users not realizing that form labels are clickable came up. And it got me thinking.
Background on labels
For anyone who doesn’t know; this is the proper syntax for a form field and it’s label.
<label for="name">Name</label>
<input type="text" id="name"/>Matching the label attribute "for" to the input attribute "id" will allow a user to click the form label and activate the corresponding input field.
There’s no real problem with doing that, it’s great, but the general public has no idea has that this functionality exists. And it can be very useful, especially when dealing with check boxes or radio buttons.
Secretly educating the user
How do we get this feature pushed to the user. You can’t send out an e–mail to 50,000,000 users informing them that they can click the text next to a form field.
Adding in features (or letting people know that they are there), needs to be done in a way users will notice in their every day usage and it has to feel like a natural addition. So, we ask ourselves — what would make a user think something is clickable on a web site?
This:
The code
label{cursor:pointer;}And even maybe add something like this in:
label:hover{color:#777;}Those code snippets will help bring clickable labels to the public (in compliant browsers, of course), letting them know of this little UI enhancement most web sites have, you could even go as far as to make you labels appear like links (but that might be a bit much).
Conclusion
Labels are already clickable, but Joe the Plumber, Internet user, has no idea, he just hates filling out forms and miss-clicking all the time. The hit areas of these form fields are already bigger than they appear, but now it’s time we let our users know it, and make sure it comes naturally to them.
Tags: CSS, form, ui, xhtml
Posted in Web Development, Web Standards | 5 Comments »
This Week in Links 9/24
Wednesday, September 24th, 2008
Opera Web Standards Curriculum
Ever since Opera accepted that no one uses their browser for general browsing they’ve been huge activists for the semantic web, and this yet another example of what they’re doing to help the web evolve and educate the masses. Kudos to Opera. This should be required reading for all new developer/designers and even clients.
jQuery How To’s
This is a great list of specific things and how to do them with jQuery.
Fluid
Fluid app is something I’ve been looking into for a little while now. I normally wouldn’t put this up here, because it’s a mac–only application; but it seems really neat. It creates desktop apps from web sites, like a bunch of little stand alone browsers in your doc. It does a similar thing to Google Chrome, by modularizing your web apps so if one crashes everything doesn’t fail.
Digital Web Magazine
I don’t know exactly how this site evaded my RSS reader for so long, but it’s a very informative ‘zine about the web. When I first saw it I read through a few articles and really liked what I saw.
Hngry
Hngry is the lunch time app we all wanted, but are too lazy to build. It’s very nice, but it needs a lot more data.
Tags: apache, desktop, htaccess, jquery, lunch, mac, opera, training, zine
Posted in News, Web Development, Web Standards | 2 Comments »
A New Breed of Microformat
Monday, September 22nd, 2008
Because I’m a web dork (nice way to start a post, huh?), I was poking around YouTube last weekend and decided to crack it open in FireBug.
I was on YouTube’s MayerMusic channel fiddling around with the video info section and notice that some of the info was wrapped in a quasi familiar class “vfacets”. This appears to be some sort of Microformat; but none that I’ve ever seen.
After seeing that, I decided to do a little digging (digging = 5 mins of Googling), and eventually found a pretty undetailed page about group examples of Microformats.
Generally, I find that Google’s front end development is a disgrace to the Internet (no offense…), but it seems like they’re buying into the concept of Microformats. With that in mind I thought I’d talk about how Microformat groups could be used.
Usage
Many of us are familiar with the most common types of Microformats (hCalendar, hCard, hReview, and XFN). There are also many that are still in draft form like hResume, geo, and rel-directory. However, it seems that a new type could be emerging for grouping information.
The link above listed out 4 examples of major sites using Microformat groups: YouTube, Magnolia, Linkedin and Flickr. I really like how Google (youtube) is marking it up though, so I’m going to get in to that.
YouTube vEntry markup
<div class="v120vEntry">
<div class="vstill">
<a href="/user/spoiledmilk"><img src="2.jpg" class="vimg"></a>
</div>
<div class="vtitle">
<a href="/profile?user=spoiledmilk">spoiledmilk</a>
</div>
<div class="vfacets">
<span class="grayText">Joined:</span> August 02, 2006<br>
<span class="grayText">Videos:</span> <a href="/profile_videos?user=spoiledmilk">21</a>
</div>
</div>In marking up user information they are using:
- ventry as a wrapper
- vstill for the user image link
- vimg for the image itself
- vtitle for the user’s name
- vfacets for, what seems to be, general information
I’m wondering why Google is going with this. In the past I think it’s safe to say that they don’t really do things like this unless they’re planning to use it in something they build. Not to take shots at Google, but they don’t really do things for the greater good of the web community (correct me if I’m wrong).
Consistent user tagging
The basis for using something like a vcard class is to let the browser, user, spambot, or software know that a page contains contact information (and your now beautifully marked up e–mail address). This same principle applies to Google’s vEntry.
Let’s consider that Google is building a large social networking platform; I know that the main complaint I have with all these new networking sites is that you have to constantly rebuild your contact list. Marking up a member’s information in a consistent way would aid in search and ease the pain of finding those Twitter followers (for example) we all love so much. Or even for building some sort of Internet phone book.
What are they scheming?
What’s Google planning? What else can be done with this new microformat? Did I completely miss a huge glaring detail here?
Maybe this isn’t even Google code, it could be left over from when they bought out YouTube. I guess we won’t know for sure until we can pick apart Google’s brain and find out what’s going on in there.
In the mean time, watch out for this new Microformat, I have a feeling they’ll be popping up in other Google sites as well.
Tags: google, mayermusic, microformats, youtube
Posted in Web Development, Web Standards | 3 Comments »
This Week in Links 9/10
Wednesday, September 10th, 2008
Evernote
Evernote is a program to help you remember things. Think of it like a post-it not that you wear on your forehead all day.
Microsoft CSS Vendor Extensions
It looks like Microsoft IS actually doing work on IE8, They just beefed up their CSS support. It actually looks pretty promising so far. Looks like their goal is for full CSS 2.1 support and then branching into CSS3.
Measuring SEO: why rankings are worthless
A pretty good read from Yoast about what you should really be focusing on with SEO.
A List Apart
New issue of A List Apart this week, always a must read.
10 Principles of the PHP Masters
Another on from NETTUTS about some tip and best practices while working in PHP
Tags: a list apart, alexa, internet explorer, links, php, seo
Posted in Browsers, News, Web Development, Web Standards | 2 Comments »
Styling Your Body
Monday, June 2nd, 2008
Diving into the depths of CSS involves much more than just mastering selectors, properties and semantic (X)HTML, it has a lot to do with knowing when you need extra elements (span, div, etc). What do I mean?
Since CSS layouts have exploded into the mainstream of web design there have been few designer/developer types who can say they haven’t seen id="wrap" or id="container"; in fact, most of have been using it for years and it’s a bit of a standard now. Meanwhile we all seem to forget that there’s a lovely element we rarely use… html, the proud parent of body. All parents like to see their children succeed, but html has been depressed for some time now. Why? Because it’s child isn’t being put in in the 4th quarter, it’s being taken out in the 8th inning, not being used to it’s fullest potential because of this smug little punk on the block called "container" (or "wrap", for short).
No one forgets that body and html are there, they just forget they’re a stylable elements, everything can be manipulated with CSS, (remember?). So rather than doing something like this:
#container{
width:60em;
margin:0 auto;
}Try filling out your body like this:
body{
text-align:left;
width:60em;
margin:0 auto;
background:#fff;
}And then style that proud parent html (at the top of the style sheet)
html{
background:#ccc;
text-align:center;
}There you go, you cut just down on an extra div you didn’t need. This technique will work in 95% of the web sites out there. The only case it wouldn’t fly is if you need to put content spanning the whole top of the browser window (with a center aligned page). With 95% of page load time happening on the front end, every character you can shave off counts. Since there’s very little semantic benefit to a having html body div#wrap, it’s usually an easy choice to cut out.
Not only is it an easy choice the drop, but it’s a seemless integration. You essentially move all the layout properties up a level (move #wrap to body and body to html). There’s usually little to no change for the user and few things to fix.
Tags: CSS, design, tips
Posted in Web Development, Web Standards | 21 Comments »
For a Beautiful Web
Thursday, March 12th, 2009
Every so often as I meander around the internet I find little bits of geek-dome brilliance in the markup of a site.
This morning, I was reading For A Beautiful Web, a site put out by Andy Clarke. This site, by itself is a great resource, but that’s not why I’m writing this.
I left a comment on a recent blog post, and since I had also just written a custom style for this site with Stylish, I noticed that the comment I left looked a little funny. It looked like the style I just wrote for a blockquote. So I investigated.
Sure enough:
Not only a blockquote, but a dash-o-microformatting too.
Anyway, I thought this was a brilliant addition to blog comments, and it makes perfect semantic sense, and I really hope it catches on. I love it, great job Andy!
P.S. If anyone wants to meet up at SXSW next week DM me (or e-mail me), I’ll be there for all of the Interactive and some of the movies.
Tags: comments, microformats
Posted in Web Standards | 5 Comments »