Forum Moderators: not2easy
I just thought I get some of you css clever people advices on how best start moving to css/table-less design.
I have been designing web pages for 3/4 years now and I've set up my own business for almost 2. This month here (in UK) a new DDA (disability discrimination act) has been put in place which depending on how you read it, encompasses corporate/companies' websites in its guidlines.
I've always designed with tables [me ducking behind my pc]for layout and have been using css only for styling.
I want to move away from table design to be able to offer my customers the possibility to opt for a accessible design should they want to i.e. I need to learn accessible site design. Also I beleive that their is going to be a huge market for accessible sites over here very soon. And finally I really believe that accessibility and web standards are the way forward.
So I bought Designing with Web Standards (Zelman) and Eric Meyer on CSS for a starter (still waiting to be delivered) and was wondering what other things you guys were recommending me to do/read/assimilate/try/print/incorporate.
The next item on my agenda - once the books are read and understood - is to redesign my company website accessible-style and also a couple of other personal/business website I own.
So what you guys advise me to do?
Thanks
Leo
1) Don't use layout tables at all in a transitional period. Not only do you learn faster if you dump yourself at the deep end, but I've found that trying to mix the two paradigms only leads to stress. There are a few things that are more difficult to layout in CSS (footers, forms, etc) but usually someone has done them before and written about it.
2) Cultivate a set of websites. Personally I like A List Apart and w3schools for tutorial stuff, but I also read blogs like stopdesign, mezzoblue, clagnut etc.
3) diveintoaccessibility.org. Read it.
You're right on accessibility being not only important but a legal requirement now. Certainly the company I work for is taking it very seriously and companies do ask us for specific WAI levels, which can only be a good thing.
However be aware that eliminating layout tables will not automatically make your site accessible to all. And using layout tables does not make your site automatically inaccessible. Simple table layouts are not a barrier to visually impaired users, however an all-CSS design can provide extra "enhanced-accessibility" features e.g. linearised and high contrast versions of the site content.
But remember that visual-impairment is not the only type of disability. How will your websites support visitors with cognitive-impairments who would need simplified copy?
In reality, organisations always cannot cater to all disabilities and it is my understanding* that the DDA recognises this and accepts that alternatives can be substituted e.g. a shop without a wheelchair access ramp can provide a door bell for wheelchair users to request assistance.
But on the web we have a chance to easily build in good accessibility for most people, and this is a very worthy goal that we should all strive for.
*I'm not a lawyer...
Just be aware that cross browser compatibility issues while implementing CSS-P (CSS-P is a shorthand term for Cascading Style Sheet Positioning) will give you some trouble starting out. You will have to deal with browser quirks, bugs and browser developer nearsightedness.
MAKE SURE you understand relative vs. absolute position and why container blocks play a big role in which positioning will work in a design situation. Make sure you understand element boxes and the box model, plus the different ways different browsers implement the box model. IE in particular.
Make sure your nesting of divs (we all do it) are kept to the minimum necassary and you know HOW/WHY they nest. I leave the definition of 'necassary' to you and your projects.
Remember, tableless design does NOT mean never using tables. REMEMBER this even more...it does not say ANYWHERE that you MUST go tableless to have an accessible site.
I took myself and my company 'off the deep end' as someone stated here and it actually SLOWED our production rate, increased office stress and magnified on our weakness at the time. It also introduced design dilemas that were initially avoidable and took time to fix.
Granted, we learned a heck of alot by going off the deep end...but NEVER take your clients with you. They usually drown alot faster than you might in the process.
We are in a transitional period so use that to your advantage. This industry accepted period took the early CSS developers/advocates nearly 5 years (possibly more) to achieve.
This time is transitional. Use it to transition gently.
I'd love to keep in contact with you to offer our mistakes and trails as learning tools. Send me an email using this forum if you'd like to keep this dialogue open.
Nathan
The unfortunate downside is that they are written in pretty heavy tech-speak that takes some getting used to. The best way to cut through it, though, is to keep on reading it. Eventually, you start to pick up on the language. All by themselves, the specs are too cryptic to be of much use, but when referred to as you read about cSS in more normal-person geared sources, they are absolutely invaluable.
Best of luck,
cEM
My pages are generated from perl so it is relatively easy for me to change markup for a whole site.
I'm doing it in two stages:
first: tables with css for specifying all the styles of font, margins, colours etc.
second - the current stage - the css layout.
To generate the new html markup I have made use of the fact it is easy for me to identify newly added pages. I have duplicated all the perl code used to generate pages and added css as a prefix to the routines.
I modded the css prefix routines to generate the new markup.
I use the old routines for the old pages and the new routines for new pages. Now that i'm happy with what the routines are producing I'm ready to complete the change over.
I worked out the layout using a minimal markup test page.
I find it useful to use two css files, one for positioning, one for remaining styles.
I agree with nightva attending to the box model and createErrorMsg re keeping the w3 css pages handy.
One thing that is vital to mention.
A big incentive to go all css was a desire to go up the search engine rankings.
Google pays attention to h1,h2, h3 etc markup and the order of this. Thus it is good idea to put index links after the content.
Julius
[edited by: SuzyUK at 3:24 pm (utc) on Oct. 21, 2004]
[edit reason] sorry no URLs : see TOS #13 [webmasterworld.com] [/edit]
The best practical course of action is to do a thorough accessibility review of your existing site designs, and then you make some more informed decisions based on some hard practical evidence.
The keys to basic accessibility lie in clear navigation, avoidance on non-standard elements, flash or scripted events, and logical source-code order. On a table-based site, linearization is the keyword: what happens when you visit your existing site in a text browser such as Lynx? If the site contents make sense when the table is linearized, then you are a long way to being accessible already, even without doing away with the tables.
One concrete example: check out the website for the RNIB (Royal National Institute for the Blind). It uses - guess what! - tables for layout.
You can do great things with CSS positioning, and there are other factors in its favour including easier spidering, but before you jump to the conclusion that CSS-P is the only way, you need to make that evaluation based on your current site structure. Only then can you lay down the priorities.
Don't use layout tables at all in a transitional period.
<div><h1>Header</h1></div>
<table>
<td>col one still containing CSS and divs</td>
<td>col two still containing CSS and divs</td>
<td>col three still containing CSS and divs</td>
</tr>
</table>
<div><p>footer</p></div>
Plus.. tables for layout are not perfect (IE?) either so learning what they will do and what CSS-P makes worse or better is a good tool too
Suzy
