vanderwal.net

Accessible persona

I was reminded today of Marcus a persona in Mark Pilgrim's Accessibility tutorial for Weblogs (and anybody else interested). Marcus is actually a real person (as pointed out by Mark), which drives the persona home. This may be my favorite example currently for accessibility.

At work we constantly get outside developers turning over non-accessible sites or applications. The client I work for is put through the painful task of explaining what needs to be done to meet Section 508 requirements. The teeth pulling the client goes through is shameful as the outside contractors want every single item spelled out and they want to know why (they usually have built the application or site through reusing a previous product built by somebody that is no longer there and that way they can do the job cheaply and make a better profit, had they built from the beginning knowing and understanding the requirements it would have been easy and inexpensive to do). Often times I am asked to help define what needs to be done and why something fails compliance, usually as a sanity check (accessibility has been an area of strength for four years or more). The regulations are very broad and do not define the exact actions that should be avoided (this is the correct approach to allow for technological improvements).

Marcus is a great example to have on the shelf as much of the information I work with during the day is public information that the taxpayers paid for, whether they are sighted, physically able, have their hearing, or not. We know that there is a decent number of users that come to government sites from publicly available systems (like in libraries) that have technology that is nowhere near current. These people should be able to get to the information and use the information and applications around it as others can use it. Marcus is usually what we see as worse case scenarios using Lynx, but also what we think of as our baseline. Knowing Marcus exists and is really helps greatly.

There is also a benefit side to building accessible information, it is future ready information. The information that is fully accessible is ready to use with no (or is rare cases slight) modification on mobile devices. This is the wonderful thing about building accessible information. One of the first steps is building information that validates to a standard. The next thing is separating style from the content by using style sheets, which make it easy to over ride any style that is problematic or to easily allow for scalable styles. This two helps create information that is future compatible. Accessible information can also be easily reused in from its presentation as it is built to standards that ease.

Accessible information is also structured properly. Structuring information properly is far more than how it looks, it is how is marked up. A header on a Web page has an "h1, h2, etc" tag around it, which eases the ability to build a table of contents or use that header as a contextual aid to summarize the information below it (that is if headers are tagged properly and the content in the header is properly descriptive). Structuring the information helps the information be reusable out of the Web page as that is what HTML does, provides structure elements in the markup tags. If information to be reused has needs (including structure and context that is easily discernible), which validating HTML provides as a basic foundation -- of course there is much that can be improved upon the basic HTML markup, but it addresses the information needs. Building accessible information applications (Web sites included) keeps money from being wasted in the future and it does not require buying a third-party application, which are often cause more problems than they solve where accessibility is concerned (this will not always be the case).

As Joe Clark's book, Building Accessible Websites points out accessible does not mean ugly or plain. Joe walks the reader through how to make beautiful sites that are also wonderfully to folks like Marcus (side note: Mark Pilgrim edited Joe's book). Another excellent book on accessibility, and is my favorite book on accessibility, as it works very well for Web application developers (and I agree with its approach to information in complex tables more than Joe's approach) is Accessible Web Sites. These are two great resources for leaning how to do things properly. I will be working on longer reviews of each in the near future.

Zeldman uncovers the mess of Aventis site

Zeldman hits the ugly nail on the head discussing Aventis. I believe that anybody who believes there is not an poor information design or site that is screaming for an Informaiton Architect has not been to Aventis, there are so many problems that begin with and end with the drop down menus that overlap. Zeldmen points out, as he always does, the need to understand what the HTML markup and code do in a browser. Not only understanding the browser but the user. The Aventis site fails in many areas, but the tucking product information under "About Aventis" makes it very difficult to find.

Zeldman has also been sharing his wonderful redevelopment pains and discoveries. I may tackle the last couple layout bugs I have left if he cracks the right nut.

Title to the top

One of the modifications here at vanderwal.net was making better use of the title in the HTML header. This is something that I preach at work, the title should describe the information as it is used by search engines. Google uses it in their algorithms and in their hyperlink to the information. I took the category in my homebuilt CMS and placed the category name in the title and put the same title in the H1 header tag at the top of these pages. After the first Googlebot scrape of this site the incoming Google clicks quadrupled in 24 hours and have stayed rather constant.

I knew something like this would happen, but not to this extent. I guess there are so many poorly formed Web pages out there that a properly formed page sticks out (tounge partially in cheek). The categories are set based on my personal taxonomy and each entry can be cross classified as there is often cross-cutting issues in a post. The things people are seeking and ending up on these pages is extremely broad, much like the topics covered here. Some of the Google queries end up at Off the Top as it is near the top in the search results, but not nearly as on target as others that are farter down the list that have not structured their information properly.

GUI vs Hand Coding for HTML

Dori posts a matrix explaining how well GUI Web mark-up tools perform and it is not suprising that most do poorly. Dreamweaver MX does admirably, but the JavaScript is not up to par. The best coding is still hand coding. If you do not know how to hand code your job will never be done, it will not be right either. The tools have come a long way, but they are nto there yet.

Redesign explained

You most likely have noticed. There has been a redesign here. This new site is nearly all XHTML and using CSS box model. Going through this process introduces one to all the bug that browsers have that you need to work around. I found that IE 5.5 and up on the PC is horribly buggy and does not follow standard box model too well. Netscape 7 on the PC is the best browser. On Mac OS X the best browser has been Navigator/Chimera and IE 5.2 (through this Chimera became my favorite browser on most any platform).

You dare ask why the redesign? Well it was well past time. The last design had been around for a year or so and the CSS was giving me fits. I really wanted cleaner markup and I wanted to have a font size that scales. I believe that the font scales on all web standards compliant browsers and platforms. It should even scale on the PC's IE 5.5 and 6 browser (this has had broken functionality since day one, if you need a browser to scale font sizes properly get a real browser, one that is Mozilla based will do just fine). I am trying to remove the thin white line under the logo graphic and above the menu bar, it is showing up in IE on the PC and on versions of Mozilla on the Mac (Please contact if you have a solution).

I also wanted a better layout that would permit a cleaner layout. I moved the global navigation to the top bar and it uses and unordered list and CSS to put it in line and give it the roll-over (I stole part of the code from Scott and tweaked it). I also moved the local navigation to the left, which has been a joy as it is near the scroll bar and has made life a little easier. The right navigation may also be a place for other goodies. The right navigation has also helped me on the links page as there are a ton of links and I wanted a sub-navigations (yes, the links page is going to be getting an over haul in the near future with some needed integration with other elements in the site). The redesign also give the opportunity to introduce some small photos or images on the pages and not have other colors overwhelm them.

The box model drove me crazy, but I created some cheats I hope to share in the near future, once I get some minor tweaks around here done. The redesign was done solely on the TiBook and using a combination of the Macromedia MX Studio (Dreamweaver MX is a decent text editor, but I could not find a way to have it show a passable rendering of the pages in its own browser) and BBEdit. I started the process with outlines in Omni Outliner (a tool that rocks and is unparralled) as well as Omni Graffle to put together some wireframes to help me sort out the layout and functionality. This set of tools has been one of the best combinations I have used, I wish I could use this combo at work. I really am missing Adobe Photoshop, which may become my next software purchase, as it is a great tool that saves time.

Please, please write wit questions or bugs found. Thank you. I did this for me, but I hope you enjoy it.

Zeldman redoes and keeps teaching

Zeldman is redesigning and explaining the whole thing as he moves his site into the present. Many of us learned for Zeldman's A List Apart in the early days of Web development and he keeps up this wonderful spirit today. Openly sharing and the desire to learn are what the Web was built upon and is what keeps it great.

Wired goes X(HTML)

While trying to catch up on friends and knowledge I ran across Zeldman's discussion of Hot Wired moving fully to valid XHTML and CSS, which is a bold and wonderful move. Zeldman also points to Wired's defense of their move to the new up-to-date site. These are good reads and help us understand why good markup is important and to understand what goes into making these decisions and the work to make it come to life.

Markup gives structure to information

I have been missing a lot of things on the Web the past few weeks. I just found Steve Champeon's article on the importance of understanding mark-up over at Web Monkey. HTML markup, some call it HTML code (not correct), helps structure information so that it can be used and reused properly in the proper context. This is extremely important when you are trying to add style to the content, such as adding the desired size and weight to a header or modify positioning to an unordered list. I see a lot of HTML tags that are not used properly in the work we clean-up on a regular basis. There are very few applications, like MS Word that come close to using HTML markup properly. Cleaning up application generated markup is demoralizing as getting markup right in the first place is easier than having to clean up the mess made. Go read Steve's article and anything else you can put your hands on that he has written and you will be much better off than before, believe me.

Why is markup important? Many folks and applications try styling the information without considering the structure of the information. If you have much of a background in communication, journalism, information science, etc. you understand that information needs structure. There are headers that indicate to the user what the content and tone of the content that follows will contain. There are many elements on a page that need structure, like knowing where a paragraph begins and ends, where in the body of text an image should be tied, words that need to stand out (strong), a string of items in a list, or a structured ordered list with sub-elements. Not having thes information properly marked up would make understanding how to best treat that information very difficult. This may seem irrelevant to those that only deal with a Web browser, but if you want to read the informaiton on a PDA, print the information and use the best styling for reading, or need a screen reader to vocalize the words on the page and give the words that compise the information being communicated the same understanding you need structured information. It would be like trying to bake a cake with out sides on the pan, the cake needs structure to rise and be best consumed. People that guide you away from properly strucutring information, more often than not are not informed on the need and the benefits to structuring information.

Table art

Take your shot at table art, a non-judged competition showcase for those that can have their way with tables.

5k Contest is live again

Yes, it is that time of the year for the 5k Contest. Yes, 5kb of wholesome goodness with which to work. That is graphics, HTML, scripting, and all the the ones and zeros you can pack in.

MS Office special character translation

MS Office special character conversion to Unicode and definition that helps with converting Office documents in to HTML.

Yesterday was all about getting the synapses to fire in the right order at SXSWi. I was running on sever sleep deprivation from phones and alarm clocks ringing when I had not finished my needed sleep cycle. None-the-less I had a great time. I greatly enjoyed Steve Champeon's peer panel on Non-Traditional Web Design, as it focussed on the fine art of tagging content, understanding the uses of information, and the true separation of content, presentation, and application controlling the information. The Web Demo panel I was on seemed to go rather well as there were a broad spectrum of sites reviewed and the information from the panel to the developers was of great use (I hope) as I think we all learned something.

The evening provided good entertainment, a wonderful gattering at the EFF party. Once again many folks adjourned to the Omni Hotel lobby for the after-hours social gathering. I spent much of the time just listening to conversation and occasionally partaking. Of intrigue was Rusty of Kuro5hin and Adam of Brian of Slashdot discussion development of site tools that will help a dynamic site fly, keep in mind all these tools are in Perl.

Personally I think I would extend the Hillman Curtis quote, "Web designer has to think of every pixel and the role it plays in brand" and extend it to the code behind the design. Every choice in the code impacts the display of the information or the way users, particularly with disabilities use the information. Sites that are well crafted have more usable information than poorly coded sites. Unfortunately, I have run across a lot of poor code of late, which the developers of the code believe everything is fine as long as it displays properly in their browser. The problem is not everybody has their browser. The poor coding not only adversely affects the display of every pixel on the page of other browsers, but provides poor usability of the information for the sight impared. The best step is to learn the standard code, learn to code my hand, learn what every tag and element does, learn to write a page efficiently, and most of all learn how to code for everybody in your user base. Lacking this we are just blindly coding in the dark and wasting our own time, the time those that thought they could use our information, and those who have to recode the information to make it usable.

Having watched the desktop publishing (DTP) trend "empower" people to design their own newsletters and brochures, I thought the Web would have followed in a similar growth path. DTP came to popular being in the late '80s with the advent of Adobe's PageMaker. Having formal training in communication design I realized the tool was powerful, but also dangerous. Moving into the workforce I watched the folly of the DTP trend. This powerful application when in untrained hands, could create output that was as far from what anybody would want being put out by a professional organization. I heard more than my share of executives screaming down corridors, "What is this cr*p". The DTP in the hands of the admin staff or the intern with out design backgrounds or training created about what was expected, garbage. DTP was quickly relegated to the hands of trained graphic artists, who turned out great products from the same application and often same machine.

What took four or five years with DTP is not being realized with Web development. Part of this may be Web development is more accessible and children can do it from home. The novelty of Web development has not reached the ends of the earth. Another driver that sets the Web apart is the embarrassment of people's children being able to build pages, which leads some folks logic patterns to the belief Web development/design is not difficult. Much like DTP, it is not difficult to build "something", but is does take a lot of work to build something good that is usable and maintainable. I still hear some executive yelling down the hall about the poor quality of a Web page, but the conversion of those developing sites to knowledgeable developers or turning the site over to experienced expert staff is still a slow transition. The glamour of the Web has worn thin, which is helping move the development to the hands of craftspeople and those with the passion to learn all the details.

I still have hope, actually I work in an environment that gives me great hope as the people with the power to say no do so for all the right reasons. The reasons are development that does not meet the minimum standards of a professional organization. The Web reaches far more people with the messages of our organization that the world prior. The Web imprints user's minds with the impression of a solid organization that cares about the information it handles, or it can do the opposite with equal ease. The experience and impression is in the hands of the professionals to see that these standards are met and adhered to. I am happy to work with not only professionals, but people with the passion to understand what is right to get the information to the people and get it there properly.

I think a note of clarification is needed regarding the frames comments from the other day. I am a huge fan of the Content Management Bible and have been perusing it for a couple months (or so) now. The use of frames is not all bad, if used in a proper context.

One reason to use frames is using the browser client as an application interface and there are distinct sections with quasi-interrelated functionality. A mapping application (select any one of these elements on the page to see the use of frames - keep in mind there is a heavy use of JavaScript that requires a version 4.5 browser or higher). The application interface often has command elements that are essentially toolbars and definition selection elements that set the metadata layers of the information to be displayed. These toolbars direct the actions of the other frames or provide tools to be used in other frames (a zoom tool, etc.). The functionality in a toolbar is not an element of the map display and it should not be an incorporated element of the map as it has a much different functionality from the map display. Conversely, our users are familiar with navigation being incorporated into the Webpage and that is now a common and preferred construct. But, we are looking at an application being displayed in a Web browser, which requires a different mind set.

Another use of frames is in a controlled environment that has a plethora of distinct content items that are within a contiguous text, such as an extensive table of contents. Here the Metatorial CM Bible is a good example of when to use frames. There table of contents is a helpful information tool to quickly scan through the information to place the reader at distinct point in a larger body of text. The table of contents is a large (long) element of text that could work as an element is one distinct page, but that would require rebuilding those elements of the page with every snippet of information delivered to the browser.

Frames should be used when the distinct content elements require each other. The table of contents and the page display elements should not work with out the other components (if they can we really have to ask ourselves why we are using frames). If we can enter a page in the CM Bible without the table of contents the functionality of the site is broken. The navigation is not available and the assistive information (navigation and/or metadata elements) is not available.

The last item is to ensure that if a frame can stand alone as its own page, please ensure there are the needed navigational elements on the page. In the example that drove my frames rant (largely because the CM folks understand information and its need to be used, but the site breaks information use constructs we know from experience and research to be proper and needed) the thing that was disconcerting was each of the frame elements needed the other to provide complete information for the user. The user needs context. We need to provide the user a means to get to our front page or to other areas within our sites, because if they like our information we should offer them more. If we build a site using framed elements and these elements can be used on their own (no JavaScript sniffers to ensure the other frames are open as a requirement for displaying the content, or other similar technique) the content must have navigation elements (the footer is an unobtrusive placement) and really should have some branding or other statement of ownership.

We know that users of information have varied purposes and methods of using our information. We need to provide the users the tools to help the user provide this information. We are often proud of our information work, but if a user does not know it is us or we do not want to claim our work is decreases credibility.

We need to embrace functional information architecture to ensure proper information use. This bleeds in to user experience design, but understanding how information is used and the information interface is used must be integrated into the IA. Proper functional IA should keep improper use of frames from occurring. Functional IA would walk through a string of questions using a wireframe of a site and ask how the frame sections would interact. We would ask what information is lost if not all the frames function (a surprisingly common occurrence). We would ask if frames maintain context for the information. We would look at methods of insuring the whole of the frames remains so to provide proper navigation, proper context, and proper metadata to help understand the information provided. Not asking these questions is not being responsible to the information, those that collected the metadata and spent time understanding how the information is to be used, and is not responsible to the consumers of the information.

The solution to the = in the link is to use  in its place. This may require a solid tweak to my home-rolled weblog application so to sniff, parse, and replace the symbol prior to inserting into the database.