Home > Developing > Working for Accessibility using CSS

Working for Accessibility using CSS

An interview with France Rupert: Interaction Designer, Sprint

by Leslie Salazar-Bushell
Interaction Architect Kansas.gov

For years, Web designers have labored to control their pixel-perfect designs on the Web with the table-based layout structure. Spacer images, fixed font sizes, fixed table widths and heights, tables nested inside tables. Tables, tables, tables. Sure the designers gained control, but the cost came in maintenance, speed and accessibility.

In recent years, the focus has been on the separation of style from structure and content. New methods and standards have come about to support this need and Cascading Style Sheets (CSS) are leading the way. One reputable group of forward-thinking designers and developers, The Web Standards Project has helped push for quality standards for designers with accessibility and usability in mind.

CSS is a means for designers to separate presentation such as style, color and layout from content. The presentation is then easily controlled through a series of style declarations based on certain selectors in HTML markup, e.g. <h1>, <h2>, <ul> and <p>. CSS provides more control and creativity with reduced maintenance, and produces cleaner and more efficient code that in turn produces quicker download and, most importantly, provides better accessibility to the users.

France Rupert, Interaction Designer for Sprint, recently received quite a bit of attention when he and his design team launched the redesign of sprintpcs.com in November 2003. Its design is all CSS-based, making it one of the first major commercial sites to make the leap to full CSS. He authored the Presentation Coding guidelines for Sprint online properties and has been featured on several Web sites including the Web Standards Project, Douglas Bowman´s Stopdesign, The CSS Vault, The Weekly Standards and numerous other accessibility and CSS Web logs.

He has worked in Web design for almost eight years both in commercial and local government entities. I sat down with France to talk CSS and its impact on accessibility.

LSB: When did you become interested in accessibility, Web standards, etc.?

FR: I´d always been mindful of the core tenets of Web standards, especially with accessibility; but it wasn´t until mid-2001 I realized it could be implemented in full force - tableless and all. We can attribute that to improvements on browsers, especially when Mac IE 5 came out. Its CSS 2 capabilities and rendering engine were a huge accomplishments at the time. The true moment of truth came with wired.com´s late-2002 CSS-based redesign, courtesy of Douglas Bowman. This was immediately followed by espn.com from Mike Davidson and FastCompany.com from Dan Cederholm. This gave me the ammunition needed to make the case that the timing is right.

LSB: So tell me, where are you in the whole accessibility area?

FR: I´ll just sum it up by with favorite quote of mine from Jeffrey Veen. "....I don´t care about accessibility!"

LSB: (Raised eyebrow.)

FR: "Because when Web design is practiced as a craft, and not a consolation, accessibility comes for free." (Jeffrey Veen, )

This is Jeff´s ironic way of stating that designing with best practices in Web design, designing with Web standards, makes accessibility a bonus without adding development time and extra cost runs. Retrofitting an existing site for accessibility features can be a rather costly and time-consuming process. Why not beat ´em to the punch? Buy one, get one free kind of deal if you will.

LSB: So how were you able to convince your superiors that developing your site with Web standards was the way to go?

FR: Once our browser numbers supported it, I went forward with proposing CSS-based coding pratices for presentation control of our sites. In getting buyoff, I might have had it easy, but only because I think I had the right approach. I did a lot of proof of concepts. Dave Shea has since created the best example with the CSS Zen Garden. He takes it a step further with submissions from the design community. Not only does it demonstrate the endless number of style sheets idea, it also showcases some original and beautiful designs.

My three word advice to anyone needing to promote accessibility though Web standards is "Don´t sell, show!" I´m pretty sure this isn´t an original salesman tactic, but it worked for me. The audience usually won´t listen to my endless explanations of separation of style from content, presentation from structure, design from data. As accurate as that line is, it doesn´t translate for customers. They don´t want to be told about the benefits, they want to be shown the benefits. Show them working examples that demonstrate multiple designs for a single HTML page; show graceful degradation in older browsers, devices, and platforms; and if possible, demonstrate using a screen reading software. Once they´ve seen the obvious benefits, it is smooth-sailing from there.

I started off with a single CSS file for a proposed Sprint PCS visual design. I then had a second (and vastly different) CSS in the wings. I would show the page plain with no styles. This raw page is reasonably usable to begin with because it´s been marked up appropriately, e.g. <h1>,<p>,<ul>, etc. At this point I apply the first style sheet. The page is styled according to the proposed design. Next, I load the second style sheet and the layout changed in every way with the second CSS file. I continued to toggle between all three, reiterating over and over this isn´t three different pages; rather, it was the same page styled between two different style sheets. Slowly but surely, they really get it.

While the CSS Zen Garden makes the case perfectly when doing such a demonstration, I think it´s extremely important that a proper demo is given that shows the project or product they expect. It is giving them an emotional attachment to what you will eventually work on and gets their imaginations going.

After such a demonstration, and after I´ve got their attention, I would go more in detail about the benefits. Simplicity of development, browser compatibility, ease of maintenance, faster pages, accessible pages, etc.

LSB: Is that all you had to do to sell it?

FR: Pretty much. Developers got on board almost immediately because they realized they could develop an application or otherwise dynamic site without having to dance around markup and layout items - let alone worry about visual layout. They were particularly pleased with the drastic reduction in HTML size. Most pages that were upwards of 75k are now 10-15k.

If there´s one thing development teams understand, it is the separation of form from function. While the inspired adoption of <table> element and spacer images was perfect in laying out any design, it was embedding ALL visual presentation in the code. We would redesign a site knowing that we´ll likely have to reinvent the wheel as the next round of browser came out. We hacked and bended HTML markup to the point where we nearly killed browsers trying to parse it. Fortunately, we have broken that loop of obsolescence.

LSB: How did you sell it to your marketing team and the higher ups?

FR: I´d say it was primarily the in-person demonstration. They were also attracted to the centralized control of design, maintaining an enterprise-wide look and feel consistency. This was especially important as Sprint is a very brand-centric company. As an added bonus, they´re pleased with the lowered maintenance costs, reduced time for development, and the decreased cost of money and time to "retool" a site.

Above all, they got that we are doing this almost exclusively for the user experience. After all, if the designer or presentation coder doesn´t consider the impact front-end code has on the user, no one will. Consider these reasons why the user will thank you for using such best practices in Web design: pages are smaller in size and load quicker; cross-browser display is consistent; pages are accessible.

LSB:When you were learning Web standards and CSS what was your biggest issue?

FR: Absolute Positioning vs. Float

LSB: (Laughing) YES! Me too. Another designer and I developed two sites one using one method, one using another. I know what we picked. What did you decide?

FR: For most layout purposes, no doubt, floats. For Sprint sites, we use absolute positioning for higher-level pieces like the logo, the navigation, and the location of the primary content pieces we know we can control. For everything else on a page, I don´t see any other real option as every page´s content will flow in a different manner. In little places here and there, we´ll use relative positioning for some pieces that we need to pull out of the flow of the page, but within the context of where they were in the HTML structure.

LSB: Plus using a float-based layout allows you positioning control of your footer.

FR: Yes, and it is almost the root of why I implemented limited positioning, since our footer needs to fully extend from left to right below all columns. Apart from a JavaScript hack to detect the tallest column, floating those pieces was the only option.

LSB: What accessibility issues are you working with?

FR: Before and since our redesign I´ve been flip-flopping on absolute vs. relative font sizes. For visual design control reasons, I decided on an absolute font size. This issue/argument is well-documented in the Web standards community, so I won´t go there much. The purist side of me knows that we must use relative sizes as that is the W3C mandate. However, the designer in me realizes the reality just won´t give us the consistency and predictability needed. It does go to the biggest headache designers have —IE. It´s the only browser that will not resize absolute sizes, but every other modern browser has the capability. I would argue that a fixed size (11px, 15px, etc.) IS a relative font size, that is, relative to your monitor´s resolution. It´s unfortunate that a single browser´s limitation has produced such a heated issue.

LSB: We use relative. State guidelines.

FR: Yeah, and that´s expected for government sites. To settle that argument with myself, I decided to appease both viewpoints. I have a design and code solution in the bullpen that will toggle between three different absolute font-sizes - a common method see wired.com for an example. It´s a user-facing piece that will be more apparent to users than a browser´s font-sizing menu item. I feel it just might be the better solution since it mitigates my two viewpoints. It will allow us control of layout since I know exactly how the pages will render at the possible sizes.

LSB: Any other issues you have been looking at?

FR: Another common issue I flirted with was fluid layout rather than the current fixed grid. It was never really an option since we had pretty much settled on fixed for almost the same reason as absolute font-size: control, predictability and usability. Any designer, whether it´s for screen or print media, understands there´s a certain line-length at which text becomes uncomfortable or impossible to read. I boil it down to good design really being about eye-flow. Forcing a user to read 30 words and then find the correct carriage return isn´t going to work.

I would have liked to take advantage of minimum and maximum width, but IE doesn´t support those CSS properties. If I was ambitious, I could have implemented an em-based layout where columns would grow upon increasing font-size. That can be fun, but gets way unpredictable especially with our hardcore float-based layout. In the end, the decision was an easy one.

LSB: What book recommendations do you have to get started on transitioning from table-based to CSS-based design?

FR: There are three books that do excellent job for beginners and pros alike: the orange book, the blue book, and the yellow book.

The orange book is Jeffrey Zeldman´s Designing with Web Standards. It gives a great historical basis for where we were, what we can do now, and where we hopefully can go. It´s more off a foundation to lay down in understanding the theory and practice of Web standards.

The blue book is Eric Meyer´s Eric Meyer on CSS, a very specific How to code CSS. It´s especially a good book for those who´ve mastered table-based layouts. It starts out by providing tutorials on creating hybrid layouts that use minimal tables for layout coupled with CSS. It then goes on to more CSS-based layouts. He follows it up with The Pinkish Book More Eric Meyer on CSS.

The yellow book is Dan Cederholm´s Web Standards Solutions: the Markup and Style Handbook. It extends upon his popular SimpleQuiz series. It provides code example solutions for the marking up of a page and decides which of the examples is the more semantically accurate method. It stresses that there isn´t any one solution, just that some are more pure to form than others.

To complement these, a good CSS reference book is always good. Eric Meyer´s Cascading Style Sheets: The Definitive Guide is a good one as well.

Coupled with this newfound knowledge, the design community is extremely helpful. One strong example is the CSS Discuss discussion board. Most problems found along your way are archived there; if not, there are plenty of folks ready to help solve your problems.

LSB: Any closing thoughts?

FR: Fortunately, we´re at the point now where CSS-based designs are almost expected for any new and redesigned site. The Web standards case has been made, many reputable companies are on the bandwagon, the practice has been refined, and there are endless examples and resources available. Two years ago there was the common misconception that CSS-based designs are boring or boxy-looking. This evidently was brought about because those who abandoned tables and spacer images for CSS were the more technically-minded and that designers were intimidated by the technology.

Frankly, this did surprise me because CSS should not be mistaken as a programming language. It is a design language specifically for designers to describe how a page should look based on the markup. Even though it was an extremely elegant hack, we made the mistake of treating HTML as a design language because it was a natural transition from the page layout tools we know and love (QuarkXPress, Illustrator, etc.).

Web Designers latched onto HTML in this manner because we treated it as a design language. So I think the gradual adoption of CSS-based layouts came slowly because it was more the markup language, HTML, that tripped them on the way, not so much the CSS. Now that timing is right, the best thing to do to start off now is clear your mind of pretty much everything you knew and start fresh. Describe the page with semantic markup and style away with style sheets.

To see what France is working on, visit his personal Web site www.point-break.com for links to CSS and accessibility information.

For more information on CSS, accessibility, and Web Standards, visit the sites below.

• Accessibility at Kansas.gov
• westciv: Learn Web Standards
• Stopdesign
• CSS Zen Garden
• A List Apart