EvoBloggito

Oops! There Goes Another Accessibility Mistake

Author: Ray Gulick; Published: Jan 29, 2009; Category: Accessibility, CSS, Design/Development; Tags: Accessibility, CSS; One Comment

I’m not an accessibility “expert,” though I care about the issue and do my best to create accessible websites. However, I read a lot of web design/development information, and sometimes in my reading I pick up a trick without thinking through all of the accessibility angles. A classic example is how I’ve routinely (until now) implemented the Gilder/Levin Method of image replacement to place logos in the page header. The reason I settled on using the G/L method in the first place, by the way, is that it is supposed to be accessible. And it is, if properly implemented. Here is the HTML markup as it’s normally recommended:

<h2><span></span>Company Name Goes Here</h2>

I won’t bother with the CSS, because that’s not where the problem lies. The problem is in the HTML markup. Using a head tag (<h2>) in the page header turns out not to be such a good idea. The reason given for doing this is the supposed SEO benefits: Google will give the information high priority because it’s enclosed in a head tag. However, some of my SEO friends tell me there is little benefit to having the same heading on each and every page of a website.

But the real problem is that enclosing the company name in the h2 tag interferes with the document hierarchy. A semantically structured document has a single h1 heading first (in the "content" part of the webpage), followed by lesser headings. Including headings prior to the h1 heading interferes with the ability of people who use assistive technologies to make sense of the document.

So what’s the solution? Instead of using a head tag to enclose the company name, simply subsitute a div tag. Maybe it will cost you slightly in SEO (there’s a lack of consensus on this point), but it will definitely make your pages more accessible. I think it’s a good trade-off:

<div id=”logo”><span></span>Company Name Goes Here</div>

Paying Attention to Website Accessibility

Author: Ray Gulick; Published: Jan 17, 2009; Category: Accessibility, Business, CSS; Tags: Accessibility, CSS; 3 Comments

Web accessibility has to do with making websites accessible and usable for everyone, regardless of abilities or disabilities. Most of the techniques for making websites accessible are easy to do and don’t take much time, but many websites are minimally or not at all accessible. There are laws in place to ensure that public and commercial buildings include access for disabled people, but in the US, there are no laws requiring commercial websites to be accessible, yet (Britain has had such laws since 2004). US government or government-funded agency websites are subject to Section 508 of the Americans with Disabilities Act, but I’m not aware of any agency that has lost funding due to non-compliance (if you know of a case where penalties have been applied, please let me know).

I don’t believe there is a conscious attempt to make websites inaccessible. I believe the problem is simply a lack of awareness of what accessibility means to disabled people and how easy it is to make websites accessible. Also, older approaches to web design (for example, the old slice-and-dice method promoted and enabled by Fireworks) resulted in particularly poor accessibility. Those types of approaches were meant to make sure a website looked the same to everyone in all browsers, but they left out people with perceptual disabilities, making some of the information "inaccessible" to them. Website accessibility does not mean the site looks the same to everyone in your audience: it means the information is available to everyone. What good is "looks the same" to a blind visitor?

The first step toward accessibility is to build websites that are standards-compliant. Good, clean markup with all style elements defined in CSS is fundamental. Second, semantic markup is a great help, and the use of XHTML is a start in that direction. These days, thankfully, you cannot credibly promote yourself as a competent or professional web designer if you don’t use CSS/XHTML. If your website was built that way, you’ve taken some steps toward accessibility, and I would consider that the minimally acceptable approach. However, there are still a remarkable number of websites built with CSS/XHTML that use fonts specified in absolute units (pixels) as opposed to relative units (ems). This will not be a problem as IE6 passes from the scene, but that will be a while.

It gets a bit more complex when you attempt to enhance the user interface with jQuery or other javascript. None of the online accessibility validation tools I’ve found seem to be able to recognize the difference between obtrusive and unobtrusive javascript, or whether or not the page is dependent on the javascript to reveal information. So the page is given a warning, at best, or failed (most of Evo’s websites get less than spotless accessibility evaluations for this reason). Even Google Analytics code on the page triggers a warning or failure. It’s tempting for developers, with these kinds of results, to quit caring about accessibility.

But it’s best to use these tools for pointing out potential problems to evaluate, rather than take the results at face value. In the above example, further investigation may be in order with the Firefox Web Developer tool, turning off javascript. If doing so makes content on your site unviewable, your site is utilizing javascript in an obtrusive, inaccessible manner. Not good. However, if all content remains viewable, and only presentation is affected, the chances are javascript is not affecting accessibility.

10 jQuery Plugins We Really, Really Like

Author: Ray Gulick; Published: Dec 15, 2008; Category: Accessibility, CSS, Design/Development, jQuery; Tags: Accessibility, CSS, Design/Development, jQuery; No Comments

It wasn’t that long ago that javascript was considered a "kiddie" programming language, used mostly to inflict annoying browser behavior on website visitors. Then, AJAX came along, using javascript to process client-side requests. Suddenly, javascript was useful. jQuery has been described as "javascript that has grown up." Following are our current favorite plugins.

Thickbox – accommodates images (singly or in galleries), Flash, text, iframes, and AJAX, making it perhaps the most versatile of existing modal window scripts. Recently, there’s a Dreamweaver extension to further simplify implementation.

PrettyPhoto – another modal window that’s almost as versatile as Thickbox; we also like it because it’s so… pretty!

Watermark Input – unobtrusively allows hints in form fields that disappear when the user puts his cursor into the field.

jTabber – tabbed boxes that allow you to display hidden content on request, without reloading the page.

Superfish Menu – based on the suckerfish menu, this is a highly configurable menu system that supports IE6 and is accessible.

Scrollable HTML Table – like good little developers, we only use tables for displaying tabular data these days: this plugin allows you to fit a very long table into a short depth, scrolling it from top to bottom.

Colorize – another table plugin, this one for alternate coloring of rows and changing the color as you hover over each row.

jCarousel Lite – scrolls through images, highly configurable; we used this plugin for our portfolio presentation.

jqZoom – we haven’t had an opportunity to use this one yet, but it’s very cool; lets you "magnify" areas of an image.

s3Slider – another plugin we’re dying to use; maybe the coolest slide show effect ever.