Far Too Long... and Far Too Busy....

I'm back on it, though. And I will begin writing again soon... I hope :)

Web Standards, Accessibility, Section 508, Usability and Business Goals - Bringing it all together.

It seems at times there is a disconnect or misunderstanding of just how to balance these areas of Web Development. In my experience I have seen accessibility consultants tout the finer points of accessibility when asked for a section 508 evaluation and do so with a lack of understanding of the company's product. Such paid for advice often leads to a quandary on the hiring company's part as they strive to comply with section 508 requirements (because they have or are persuing government-connected contracts). It's not always the case where a company has a User Interface Engineer on staff, let alone one who understands these subjects well enough to see that they are integrated into the Web system successfully without sacrificing or threatening business goals. Maybe I'm wrong. Maybe these cases are rare - that would be a good thing. Either way, it's valuable to explore how all of these parts of a system relate to one another.

First, Web Standards. What are they - exactly? And why are they important? This section question is easily answered by looking at just about any other industry. A familiar example is the international effort to standardize traffic signs, in particular shapes and colors. The creation of a Web standard specification (http://www.w3.org/) in a nutshell provides a system that can make the Web "cross-user-compatible." Users with special needs benefit, search engines bots can more easily index the Web, developers are provided a foundational framework that allows a greater potential for creativity and invention. The list of benefits goes on and on - its many points the subject of another day. For more reading, I highly recommend The Web Standards Project Web site (http://www.webstandards.org/).

A subset, or a benefit, depending on your view point, of Web standards compliance, then, is accessibility. "Accessibility" is an umbrella term for the effort to allow for a greater ability to access the functionality and benefit of various systems such as buildings, public sidewalks, or the Web - the system we are talking about here. Though accessibility is a term when used that invokes thoughts of aiding persons with special needs or disabilities, it is a mistake to think that such efforts do not, in the end, benefit all. This has commonly been referred to as the "curb cut effect" and, in the sense of the Web, the "electronic curb cut effect." When, back in the 1970's, city municipalities began making street corner curbs accessible to persons in wheelchairs, it was eventually found that many others benefited e.g. persons pushing strollers, roller skaters, etc.

Accessibility guidelines (http://www.w3.org/TR/WCAG20/) have been written by a consortium of persons of the Web Content Accessibility Guidelines Working Group (WCAG WG) (http://www.w3.org/WAI/GL/). These recommendations cover the whole of "all things accessibility." The focus of their efforts is to make Web content more accessible to a wider range of users with special needs and disabilities. These recommendations can be considered comprehensive. While in a perfect world it would be wonderful for every one to comply with these guidelines, they have yet to be adopted in total into law. For now they remain guidelines. That being said, various laws have been put into place by various countries (Section 508 in the U.S. and DDA in the UK for example) who base their regulations on these guidelines - if not directly, then indirectly. Since any focus I have on compliance with accessibility laws concern section 508 compliance, that is where I will focus my discussion here in regard to legal compliance.

To review for a moment, then, section 508 requirements fall under the larger umbrella of accessibility guidelines in their entirety. When trying to incorporate compliance into your Web system, it is important to understand this distinction.

How does usability fit into the above painted picture? This is a tough question to answer. Usability vs. Accessibility is a huge subject that has been, and continues to be, debated for some time. Some say that one threatens the other dependent on the particular application of each. For instance, if using Flash to render a particular set of content makes things more "usable" but may threaten the accessibility of the content, which should take precedence? This debate is outside the scope of this article to answer in any definitive way, but I think I can help pull it into a context that makes the decision making process a bit easier.

In all of the research I do online regarding Web standards, accessibility including legal compliance and usability matters, I rarely see these subjects discussed in the context of business goals. Certainly no one would argue against the fact that an accessible site increases your potential user-base, or that a Web standard site not only aids accessibility but aids better search engine friendliness, or that a usable ("user-friendly") site helps ensure user retention - these are all business "reasons" for employing these strategies.

I drew a picture above where accessibility is an umbrella to legal accessibility requirements i.e. 508 compliance. If we continue this metaphor, let's just say that Web standards is an umbrella above the generally equal (and sometimes competing) subjects of accessibility and usability. In my opinion, then, business goals is the umbrella above all of these. Let me try to explain what I mean.

You've built a site on good Web standards practices. The site is very user-friendly and your user testing has shown so through hands-on user feedback. Now you are testing the site for 508 compliance and over all accessibility. You have a potential government contract, which of course demands you are compliant with regulations. So you have hired a contractor to perform an audit and you are now staring at her report which reveals a number of holes. Now you have to figure out how to move forward to fix these holes by retrofitting the solutions into your existing site.

So which do you fix? Well, the 508 non-compliance issues are a must. What about all of the other accessibility issues? Here is where I leverage business goals. Before answering this, you need to ask a few more questions:

How much expense will it require to address accessibility issues that are not compliance related? How will fixing these affect the usability of the site (which you have already determined is high)? Are the issues pointed out by the hired contractor focused on a single assistive technology (e.g. Jaws reader)? It is a mistake to focus efforts on a single assistive technology every bit as much as it is to focus on "pleasing" only one browser. The key here is cross-technology compliance or the "highest common denominator" you can achieve to make everyone happy. Will fixing these issues, in the end, present a potential for increasing sales or our user-base (i.e. the potential for more sales)?

This list of questions should be tailored and added to for your particular scenario. I hope the point has been made clear though. Whenever you make decisions about your site, its content and its functionality, you should always filter them through this line of thought. The biggest point I am attempting to make is that we should keep the scope of our decision making always inclusive of the larger goals of the business - to increase business. If we don't, we run the risk of shoring up our online presence with weak girders that can threaten its stability and bring our business crashing down (okay maybe just make it suffer).

User Preference Layout

You can find the demo for this article on bulletproofpixels.com. It would help to take a look at the demo before reading.

A good prerequisite to the material I present here is the article "Adaptive CSS Layouts" on Smashing Magazine. When I write entries that include full fledged examples like this one, I tend to make some general assumptions about you, the reader. In other words, my details don't always get as granular as some would prefer.

The afore mentioned article presents great ideas in creating fluid layouts and is a highly recommended read. Another very recommended read on the subject of layouts is the article "Fixed vs. Fluid vs. Elastic Layout" also found on Smashing Magazine. It was this article that got me to thinking of maybe a different approach to a UI that could be selected by the user with a single click and adapt not only the layout scheme (fixed vs. fluid) but also at the same time the font size. I left 'elastic' layouts out of the equation because in my opinion this method's caveats are too problematic to be real-world practical. Of course more time spent working on the pros and cons of this method might reveal a bulletproof strategy - the subject of another post maybe?

My idea is really a simple one, and no doubt has been tried before. But, whereas other articles tend to focus only on the layout and general content (paragraph text), I wanted to try my idea including other forms of content that presented a bit more challenge, as I am faced with such granular details on a daily basis.

The basic premise is this - choose several schemes that include a layout type (fixed vs. fluid) and a font size that is a good fit for each layout. For my purposes, I chose the following scenarios.

Two fixed widths, drawn from current statistics of browser resolutions in use at the time of this article, then a fluid layout that would lend itself to the mercy of the user's particular resolution. For an added challenge, I wanted to include a layout optimized for mobile devices as well. While my mobile version does not necessarily follow convention (e.g. the use of an "m" subdomain), I draw an assumption that the site is far less complex in its functional requirements and content types than might be more realistic.(For the record, bulletproofpixels.com uses this simplified strategy due to the simplicity and small quantity of its content.) The particulars of each of these scenarios are:

• Accessibility Level 1 - Content width fluid based on a resolution higher than 1024x768 (57%)
• Accessibility Level 2 - Content width of 1024 pixels based on a 1024x768 resolution (appx 36%)
• Accessibility Level 3 - Content width of 800 pixels based on an 800x600 resolution (appx 4% - I group all laptop resolutions in this area bacause I believe there is a trend toward more and more people having either both a desktop system and a laptop, or only a laptop due to their versatility)
• Mobile Version - Content width fluid with content layout optimized for viewports down to 233 pixels in width

The transition from one layout to another is accomplished by simply changing the class name on the body tag. I set up dependencies in the CSS to switch the appropriate declaration values for each scenario. Because the class name switching is accomplished using JavaScript (jQuery to be exact), there were a couple of additional dependencies I had to create to make sure the page is fully functional without JavaScript enabled and also avoid presenting content that is useless without it. For this demonstration this includes the left column expandable link list arrows and the accessibility bar itself. In regard to this and the fact that, without JavaScript enabled, the user may not select another layout, the default layout can be adjusted in the body tag class attribute to accommodate your particular user-base needs. One could also provide a server side solution as well that can be removed by JavaScript (allowing a more robust solution to maintain the functionality all around).

With CSS disabled, the user will get the raw content in a "naked" UI. For optimization in this scenario, the source is ordered such that the user will get the primary navigation, the main content, then the ancillary (left column) navigation and content (in that order). One caveat I left in my demonstration page is that with CSS disabled and JavaScript enabled, the user will still have the left column and accessibility controls available which do not function correctly. The fix for this is to construct these elements dynamically and add them to the DOM with JavaScript, but I did not want to take the time to write this code for this demonstration. In a real world application, however, I would highly recommend doing so.

One of the more interesting explorations was scaling the images on the page for each layout. While this may not always be either desired or practical, I could not resist adding this challenge to the mix. Except for the mobile verison, the masthead logo was left at a fixed size so its scaling would not rob the primary content of real estate in the view port. The only other images on the page include the small arrow bullets in the left column, which are functional, and the Coca Cola advertisement in the left column. I felt the arrows were important to scale because they are not only visual cues but are also independently functional. If a user has a need for enlarged content, it should be assumed that increasing the size of small functional elements would also be helpful i.e. and accessibility issue to address.

Also, before I forget, I should mention how I achieved the equal height, properly scaling left and right columns (in particular the background color of the left column. Since the column widths are percentage-based relative to the width of the parent container, all I had to do was (rather arbitrarily) come up with a possible maximum width I would expect the page to ever be viewed in (3200 pixels wide won). Next I created a background image (to be repeated on the Y axis) divided by the same percentages as the column widths. I then set its positioning to the same "left" position as the left column. Voila - instant equal-height, non-content-dependent columns.

Keep in mind that what I present here is in some ways math-intensive (everything is percentage based) and requires some amount of gradual tweaking to get things "just right". To accomplish a similar strategy successfully, there should be a lot of up front thought and planning. I suspect it would be near impossible to retrofit an existing site with these features.

The most fun here was the unanticipated (though it should have been) effect of scaling the cola ad. It's width is set in the CSS (the width and height image tag attributes were not used, which in reality is a usability issue related to performance - if there are a lot of images on the page, this strategy is probably not a good idea) as a percentage of the parent container. If you have the browser expanded to the width of your monitor and select mobile, the results are interesting. Shrinking the width of the view port to its intended size for the mobile setting adjusts the image accordingly of course.

You may view all of the supporting CSS and jQuery in the head of the demonstration document. I hope this post has been enlightening and inspires further improvements to these ideas. Thanks for reading.

Notes of Note

While researching a solution for IE's (6 and 7) inability to recognize the disabled attribute on an option tag, I ran across this proposed work around on Harry Baily's Blog. It is the best solution I could find - and I read through many. For my application I opted to simply let IE be IE (i.e. imperfect) as I felt this was a lot of overhead for my concerns. You may (and probably do) feel different. I just tend to draw the line trying to get IE to fall in line with "the rest of the world." :)

I also recently was asked to help debug a particularly strange bug in IE8. I will spare you the details as it was occurring in a proprietary CMS, but suffice it to say, this one's important. I also won't bore you with all the "whys and wherefores" regarding the new strangeness Microsoft has blessed us with in IE8. Simply put, force IE8 to behave as IE7 and spare yourself yet another host of stress with this meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Credibility vs. Repulsion

repulsion [ri-puhl-shuhn] noun

The feeling of being repelled, as by the thought or presence of something; distaste, repugnance, or aversion.

Are Web users ever really "repulsed" by a Web site? Hard to say, but I would guess they can be - I am. Based on many conversations I have had with others on the subject of Web sites, I know I am not alone. I have spent large chunks of time scouring the Web looking for that site that offers for sale that "hard to find item" I have been searching for and, after finally finding it, taken one look at the site and typed google.com in the address field of my browser and hit enter to get away as fast as I can - as if I could sense some deadly disease rearing its ugly head and taking a bearing straight at me through the ether of the internet.

Why would I - or anyone - have a such a reaction? If I come to a site with intent to spend my hard earned cash on anything, I want to know the site is credible. If I come to a site that, despite the energy I have expended looking for just such a site, reeks of a lack of credibility in just the aesthetic look and feel alone, I am certainly not going to stick around long enough to bother even considering doing business with that site.

In another scenario I find myself perusing through the navigation menus only to find that I don't really understand enough of the labels to get myself pointed in the right direction. Of course, there is always search instead of browsing navigational elements, but that is another entry for another time...

Or how about when you land on a site, are immediately impressed, getting a little excited as one nearing the end of a long journey to a destination of certain satisfaction, and once you start digging into its architecture you find yourself completely lost in a sea of content not only unfamiliar but wholly unrelated to what you were intent on finding.

So what do all these scenarios have in common - aesthetics, information organization, navigation? In a nutshell these are core usability considerations.

This post is not meant as a comprehensive tutorial on usability, and I do not claim to be an authority on the subject, though I will claim I feel know a thing or two on the matter. To keep things as simple as possible, I'll just share a few thoughts on the following features of a Web site. This is a limited list of what could be considered important aspects of usability, but I have found that the principles cited below are by far the most neglected or misunderstood by would-be Web designers.

Aesthetics

Use limited visual stimuli:

• Reduce competition between the content the user is seeking and the designer's goal to create a visually pleasing and creative UI.
• Judicious use of whitespace to help the eyes relax.
• An organized page format/layout.

Navigation

Criteria that answer important questions:

• Orientation - where am I? Breadcrumbs are the universal norm.
• Routing - how do I get to where I want to go? Use universal drop down menu systems or local navigational structures.
• Intuition - is there a consistency that allows me to intuit what my next move should be? Create a proper and consistent classification (taxonomy) of labels - the same things are referred to in the same way no matter where I am within the architecture of the site.
  
• Fini - will I know when I have arrived? Present a clear end-point and avoid dead links or link rot.

Architecture

Take care to establish "the right" architecture:

• Use systems that your users will tend to be familiar with.
• Categorize information into no more than seven top level logical units. Make sure each collection acts in a modular fashion - inter-identifiable information.
• Establish a hierarchical outline of the information and create a consistent system of vocabulary and labeling across site structure, page structure and navigation.
• Create a site structure that is not too shallow (too many and too long sub menus) nor too deep (too many layers, too many clicks). For large sites, this is quite a balancing act - but one that requires serious thought.
  

These three areas are just the beginning of creating a usable Web system. But it is these features of your site that will make or break - and quite quickly I might add - your credibility in the eyes of your users.

Series: IE's HasLayout Part 2

"Where's the content??"

Probably the single biggest clue that you are dealing with hasLayout issues is content that appears and disappears or a portion of the UI that is out of place.

To debug if and where the problem is, you can begin by adding the following rule to your CSS:

* { zoom: 1; }

If the issue goes away, then you are more than likely dealing with a hasLayout issue. The next step would be to remove the above and systematically add the zoom: 1; to the suspected elements. Once you find the culprit, put the zoom declaration in a separate IE CSS file and use conditional comments to source in that file just for IE.

"Who are the suspects??"

An absolute positioned parent container (a div) shrink-wraps to its child content. This is the expected standard behavior and is the actual behavior for IE 6 & 7 and Firefox. But things change if the child element has layout applied:






Normally we are looking for cases where we actually need to apply hasLayout to correct a problem, but there are cases where the opposite may be true, as in the above example.

High on my list of "run-ins" is the next example. I often have need to position parent or ancestral containers relative in order to position child elements absolute within that container. Problems occur when you might have an ancestor positioned relative that has grandchild element inside a floated parent. I know this sounds odd when stated like this, but with CSS layout, I find it occurs quite often. Here is what it looks like in the "big 3":



Apply hasLayout to the outer container and here is what you have:



One residual effect as you can see is the outer parent container now forms a layout box around its content. This is inconsistent, of course, with the standard (as the internal floated element has not been cleared) but in most instances you would want to clear the floated elements, thus gaining the box around all of the content resulting in the same conditions.

And there you have it. A short series, but this should be enough to help you be on the watch for bugs related to this problem as you develop.

Series: IE's HasLayout Part 1

This has been one of the most confusing and mysterious challenges I have had to face. It is not a 'one size fits all' type of issue. Each time you create a unique interface, each time you come up with a neat way to solve a layout issue (design personnel are great for providing these!) this hasLayout creature seems to rear it's ugly head.

I develop strictly in Firefox and only after getting everything completed and validated in FF do I QA my work in IE (6 and 7). About eighty percent of the time I run into issues here. And I would say about sixty percent of those ultimately wind up related to hasLayout.

To begin this series, let's gain some background. There are two type of elements - (1) those that arrange and size their own contents (e.g. buttons and images) and (2) those that rely on a parent (or ancestor) element to do so (e.g. div's and p's).

Those elements that have layout are responsible for sizing and positioning themselves and possibly any children - they do not depend on ancestor elements. A short list of the most common elements that have layout by default are:

• body and html (in standards-compliant mode)
• table, tr, th, td
• img
• hr
• input, button, file, select, textarea, fieldset
• frameset, frame, iframe
• objects, applets, embed

But the focus of this series will deal with those elements that are without layout in our work that require layout to "behave".

In the next entry in this series, we will look at some of the hints you can look for when this is the source of problems in IE.

Visit Bullet Proof Pixels!