RE: [WSG] Fixed vs flexible layouts
Well i think i found the best of both worlds... and Fluid/Elastic Design http://www.southtyneside.info/project_area/southtyneside/xhtml/elastic.asp :) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
Andy Budd wrote: > > Lee Roberts wrote: > > > Andy wanted to know what the WCAG working group members > > had to say about fixed and scalable width layouts. I am a > > member of the working group. > > > > Well, I gave an education and it seems the topic has grown > > to now include more about mobile devices. > > > > The purpose of variable width or elastic designs is to > > help people by allowing them to increase their font size > > without destroying the design. Yes, you will end up with > > right-scrolls. It doesn't matter what you do. > > Thanks for that Lee. So are you saying that the sole purpose of > checkpoint 3.7 is to accommodate the resizing of layouts along with > text? > > Does that mean in this case, pixels aren't being considered as relative > units, contrary to what the specs say? > > I have to admit that I have huge problems with the guidelines. Most > notably because they don't really tell you why each checkpoint is > necessary and how failure to comply can reduce accessibility. Some are > obvious, but many others aren't. > > > > Andy Budd > If I can just add my 2 cents worth. 3.7 has to do with using markup in the correct semantic way. HTML is for marking up content. and have meaning to user agents and parsers that are parsing documents for semantic value. If a designer was using this purely as a visual formatting technique, a blind person would have a different understanding of the way the information is communicated, because that information is being communicated via another device as a quoted block of text. If the designer wants to indent something in their design, which in itself could even be said to convey a visual semantic meaning, then they should do that with CSS. The problem is, that when TBL first adapted HTML from SGML, he only took 66% of the equation, he took from the SGML family HTML and DTD, but left out the DSSL component, and this oversight was latter addressed with CSS. Because there was no DSSL equivalent in the early drafts, default value for displaying the various elements are handled by the browsers... ie indent . pixels are relative units, but em is regarded as a far better representation of a relative unit from an accessibility point of view. The same principle is true in software development. But designers have to work with how well or how poorly user agents support the designs they want to implement. If you are having trouble understanding the guidelines I would suggest that you do go back and look at the history of human interface guidelines for digital devices and try to find the common thread. If you do this you will begin to see how WCAG evolved, and that the basic principles are consistent. You could also discuss specific checkpoints here, or on the W3C WAI Interest Group list, or the one at WebAIM. Regards Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
Yes, Checkpoint 3.7 is for resizing along with text. Pixels are not scalable. A pixel is a pixel regardless of how one might look at it. As I recall on a 800x600 screen resolution IE used 1.25 microns for a pixel while Netscape uses 1 micron. On the 1024x768 I recall that IE uses .8 micron for a pixel while Netscape uses .5 micron. Of course, I'm an old guy so my memory may be a little off. That's why looking at pixeled fonts in IE looks larger than pixeled fonts in Netscape. Mac and Linux are different as well. But, a pixel is supposed to be 1 micron. So, technically a pixeled font is not scalable. It does not resize. Only the monitor resolution resizes. Pixels are absolutes. There are many holes in WCAG1. WCAG2 is attempting to fix those problems. I hope this helps. Lee Roberts http://www.applepiecart.com http://www.roserockdesign.com -Original Message- From: Andy Budd [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 4:26 AM To: [EMAIL PROTECTED] Subject: Re: [WSG] Fixed vs flexible layouts Lee Roberts wrote: > Andy wanted to know what the WCAG working group members had to say > about fixed and scalable width layouts. I am a member of the working > group. > > Well, I gave an education and it seems the topic has grown to now > include more about mobile devices. > > The purpose of variable width or elastic designs is to help people by > allowing them to increase their font size without destroying the > design. Yes, you will end up with right-scrolls. It doesn't matter > what you do. Thanks for that Lee. So are you saying that the sole purpose of checkpoint 3.7 is to accommodate the resizing of layouts along with text? Does that mean in this case, pixels aren't being considered as relative units, contrary to what the specs say? I have to admit that I have huge problems with the guidelines. Most notably because they don't really tell you why each checkpoint is necessary and how failure to comply can reduce accessibility. Some are obvious, but many others aren't. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Lee Roberts wrote: Andy wanted to know what the WCAG working group members had to say about fixed and scalable width layouts. I am a member of the working group. Well, I gave an education and it seems the topic has grown to now include more about mobile devices. The purpose of variable width or elastic designs is to help people by allowing them to increase their font size without destroying the design. Yes, you will end up with right-scrolls. It doesn't matter what you do. Thanks for that Lee. So are you saying that the sole purpose of checkpoint 3.7 is to accommodate the resizing of layouts along with text? Does that mean in this case, pixels aren't being considered as relative units, contrary to what the specs say? I have to admit that I have huge problems with the guidelines. Most notably because they don't really tell you why each checkpoint is necessary and how failure to comply can reduce accessibility. Some are obvious, but many others aren't. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
> -Original Message- > From: Patrick Griffiths > Geoff Deering wrote: > > > I'm quite sure that when the WCAG authors say "absolute" units they > are > > > talking about pixels. If my memory serves me correctly, they more or > > > less say this. Again, it's open to interpretation, but we all know > what > > > they're getting at, really. > > > > No, that is not correct, WCAG directly references the HTML and CSS > > specifications and does not have their own differing interruptation of > any > > of the specifications. > > Okay, well I took a quick look and there is no direct reference to > pixels. It is quite clear that the gist is to use ems or percentages > however. > In http://www.w3.org/TR/WCAG10-CSS-TECHS/#units for example: > "...you may position an image to be offset by "3em" from the top of its > containing element. This is a fixed distance, but is relative to the > current font size, so it scales nicely." The WCAG1 references the CSS2 specifications on this, which includes pixels as relative units, but it is true that the emphasis is on "em" as it is the more prefered relative unit for usability and accessibility. > > It works for simple layouts, but I don't think it works for complex > layouts > > across multiple users agents. If it does, can you please show me an > > example. > http://www.csszengarden.com/?cssfile=/063/063.css > > I don't see what the big deal is. You can just take a pixel-laden layout > and replace values with suitable ems values. Why isn't this realistic? > > Mutley > I would not put CSSZenGarden in this category. What I mean by more complex layouts are multi column multi box designs, complex forms within columns, etc. It's not that it is not doable, but if you are trying to compete with the designs houses that use quirks mode and hacks across multiple user agents, maybe it's a bit difficult. If it was an easy solution to address, then why is there so much discussion on lists like this trying to find solutions? I'm not up to date with all the CSS browser design issues at all. I haven't been doing a lot of CSS the last few years, so I'm here to learn. But I'm also curious to find out how developers are dealing with these problems. --- Geoff Deering * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
- Original Message - From: "Patrick Griffiths" [snip] > I don't see what the big deal is. You can just take a pixel-laden layout > and replace values with suitable ems values. Why isn't this realistic? until we have fully supported scalable vectors, images will either not resize (changing the font size on the zengarden example, you end up with illegible chopped off text) or look crud when attempting ad-hoc "i'll use ems instead of pixels for width/height" methods. Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively. [latin : re-, re- + dux, leader; see duke.] http://www.splintered.co.uk | http://www.photographia.co.uk | http://redux.deviantart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Geoff Deering wrote: > > I'm quite sure that when the WCAG authors say "absolute" units they are > > talking about pixels. If my memory serves me correctly, they more or > > less say this. Again, it's open to interpretation, but we all know what > > they're getting at, really. > > No, that is not correct, WCAG directly references the HTML and CSS > specifications and does not have their own differing interruptation of any > of the specifications. Okay, well I took a quick look and there is no direct reference to pixels. It is quite clear that the gist is to use ems or percentages however. In http://www.w3.org/TR/WCAG10-CSS-TECHS/#units for example: "...you may position an image to be offset by "3em" from the top of its containing element. This is a fixed distance, but is relative to the current font size, so it scales nicely." > It works for simple layouts, but I don't think it works for complex layouts > across multiple users agents. If it does, can you please show me an > example. http://www.csszengarden.com/?cssfile=/063/063.css I don't see what the big deal is. You can just take a pixel-laden layout and replace values with suitable ems values. Why isn't this realistic? Mutley Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
> -Original Message- > From: Andy Budd > Sent: Saturday, 31 July 2004 2:10 AM > To: [EMAIL PROTECTED] > Subject: Re: [WSG] Fixed vs flexible layouts > > > Some very interesting discussion point here. > > I think the topic of fixed vs flexible layouts tends to cover a number > of areas. > > - Accessibility > - Usability > - Device Independence > - Personal Preference > - User Control These principles are pretty well executed in desktop GUIs. The developer really does not have to do anything other than follow the SDK and APIs and the application should deploy correctly addressing these requirements, because there features are in the domain of the operating system to manage the application correctly. There are some things the application developer has to do, they have to work with the GetSystemMetrics() information and display according to that, that is mainly working with the resolution the software is running under, and other user preferences. These are the same principles that have been used to develop WCAG. Unfortunately the developers of user agents have either in their ignorance, or by choice, or the need to be quick to market, ignored many of the principles and standards required to build user agents correctly. Some of it is just poor software architecture. If feel there is constant need to expose the short comings in user agents, much like WASP did a few years back. There is a need to keep doing this, because, if we don't, it only makes web developers work more and more difficult, and user agents companies just become complacent. WCAG is not meant to make it hard for developers, it is really meant to try and help everyone, the user and the developer (ideal world again). The W3C people in this area do try and work with the user agent developers, but because they are W3C sponsors they cannot openly critise them. I have done so in shere frustration on those lists and I have been asked to refrain from open critisism on that forum. And I think that request is appropriate, it is not the place to express those things. But developer forums are. It would be great to see some kind of wiki set up so that developers could put data into a public forum addressing user agent compliance with standards, see; http://www.w3.org/WAI/UA/2001/10/eval http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Test%20Suites http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Evaluations http://www.maccessibility.com/archive/000595.php If anyone thinks such a site to lobby all the user agent developers would be a good idea, please contact me off list. Also, if you think it is not a good idea, I'd also appreciate such informed feedback. > Many people quite understandably end up mixing these issues together. > For instance, if you create a fixed width layout and then reduce the > browser so that the viewport is smaller than the layout width, you are > going to get scroll bars. The same thing happens if you create an > elastic layout and up the font size too much. However surely these are > more usability issues than accessibility issues. > > People often bring up the question of mobile phones and PDA's but where > does accessibility end and platform independence begin? Many mobile > developers would argue that you should be developing specially for > mobile devices as the needs of the users and limitations of the medium > are very different to that of computer screens. While it's an > idealistic goal, it's probably unrealistic to develop once then deploy > across all internet enabled devices. > > Personal preference is a bit of a red herring. It seems that as many > people like fixed width layouts as they dislike them. > > Pretty much all these areas have been covered here, and elsewhere, yet > I'm still left feeling that we've not had a definitive reason why fixed > layouts are bad for *accessibility*, only personal opinion. Probably > because accessibility is a subjective concept that, at certain times, > can include all the other areas I've mentioned. > This is a fundemental HCI principle that is applied well in the major operating systems. If you read any of the following you will begin to see how these common threads type HCI principles together, and why this is also important on the web and for user agents to comply with these parameters in handling instructions, so that web developers can better support usability and accessibility in their designs. http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/HID esign/chapter_3_section_1.html#//apple_ref/doc/uid/TP3353 http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/ind ex.html?http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDe sign/HIDesign/chapter_3_section_3.html http://msdn.microsoft.com/library/default.asp?url=/librar
RE: [WSG] Fixed vs flexible layouts
> -Original Message- > From: Patrick Lauke > > From: Geoff Deering > [snip] > > If you are designing for handheld you should be considering > > display:none for > > the none content columns, header and footer and just be using the link > > element for prev, next, etc. Some sort of minimalist > > approach may be more > > appropriate for that media. > > actually, I'd go even further than that and say that this is > a case in which we may need completely different sites (or entry points > to the same information) depending on user preference - using something > like XSLT, or in any case some hefty-ish server-side system. Then, > you could serve targetted content for those who wish to have a minimalist > view, or more media rich version for those who want it. I completely agree with that, I think it is rare that the same content fits both types of media. This is also why I am trying to move to server side XML based solutions like Cocoon / Axkit / Forrest, and use TCN for delivery of content. It may be an overkill for some sites, and doesn't fit all situations, but it seems the most encapsulating type of solution for some sites where you need to address these issues. > before anybody jumps up and down and scream bloody murder: i'm not talking > about browser sniffing, but about having two or more version of the > site (ideally all powered by the same content) to allow "modal" access > to information. This is what Cocoon is meant to address, or using TCN (Transparent Content Negotiation) intelligently from the server side (I know TCN is not perfect.. thanks to user agents identifying themselves as someone else). > yes, you can just display:none, but particularly considering handhelds, > mobile phones, etc, you're still sending the data, wasting bandwidth, in > an environment where it may well be a scarce commodity (and/or > expensive... > imagine being charged by the kilobyte or something) > I agree. I'd get frustrated with anyone trying to ram unnessary content to me via a handheld. Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: RE: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
Users shouldn't need zoom, but the problem is graphic designers think 9px font sizes should be the standard. I'm afraid even I can't read that. So, until we get rid of graphic designers who believe concepts such as small font sizes is best we will continue to have the problems. No, IE doesn't allow you to increase or decrease font size when the designer uses px, pc, or pt. So, zoom is required. IE also does not support multiple choice for style sheets. So, the option of allow ing the user to select a font-size isn't always acceptable. However, if you are using the DOM you can help visitors by offering varying style sheets based upon a selection within the code of the page. I think there is an article about this on A List Apart. Lee Roberts http://www.roserockdesign.com http://www.applepiecart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: Re: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Lee Roberts wrote: > The purpose of variable width or elastic designs is to > help people by allowing them to increase their font size > without destroying the design. I think the better statement of purpose is to allow the users' choices of font sizes to work with the designs. Your statement implies that sites are purposefully designed such that users should need to zoom on sites. Users shouldn't routinely need zoom. The exceptional eyesight of the average web page designer compared to the population in general is what makes a browser zoom feature necessary. -- "If you are wise, your wisdom will reward you;"Proverbs 9:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://members.ij.net/mrmazda/auth/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: RE: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
Andy wanted to know what the WCAG working group members had to say about fixed and scalable width layouts. I am a member of the working group. Well, I gave an education and it seems the topic has grown to now include more about mobile devices. First, you must understand that a blind or low vision person wouldn't be using a mobile device. Hell, I take my bifocals off and I can't even read the the information on my cell phone ... don't even think about me trying to read a web page on it. The purpose of variable width or elastic designs is to help people by allowing them to increase their font size without destroying the design. Yes, you will end up with right-scrolls. It doesn't matter what you do. Images must be sized with fixed height and width. So, here's your problem now. You set your header image up so it is 789x wide. You resize your browser window to anything less than 789px wide and viola you end up having a right-scroll. So, how do you fix that slight problem? Well, that's kind of simple. You make it a background image. Then you're able to shrink your design down until you run into another image that is set in the foreground. You simply can't avoid a right-scroll in many cases. Developing for mobile devices is a pain, but XHTML helps much better. XHTML2 will do more. WML is understood by Nokia, but not all other phones. iPod understands things differently than IE for Palm. But, those devices are not what I focus upon when developing pages for disabled access. I hope this helps. Lee Roberts http://www.roserockdesign.com http://www.applepiecart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: Re: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Some very interesting discussion point here. I think the topic of fixed vs flexible layouts tends to cover a number of areas. - Accessibility - Usability - Device Independence - Personal Preference - User Control Many people quite understandably end up mixing these issues together. For instance, if you create a fixed width layout and then reduce the browser so that the viewport is smaller than the layout width, you are going to get scroll bars. The same thing happens if you create an elastic layout and up the font size too much. However surely these are more usability issues than accessibility issues. People often bring up the question of mobile phones and PDA's but where does accessibility end and platform independence begin? Many mobile developers would argue that you should be developing specially for mobile devices as the needs of the users and limitations of the medium are very different to that of computer screens. While it's an idealistic goal, it's probably unrealistic to develop once then deploy across all internet enabled devices. Personal preference is a bit of a red herring. It seems that as many people like fixed width layouts as they dislike them. Pretty much all these areas have been covered here, and elsewhere, yet I'm still left feeling that we've not had a definitive reason why fixed layouts are bad for *accessibility*, only personal opinion. Probably because accessibility is a subjective concept that, at certain times, can include all the other areas I've mentioned. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: Re: [WSG] Fixed vs flexible layouts
I am on holiday between the 30th July and the 14th August. I will reply to your e-mail as soon as possible on my return the following day. Thank you for your understanding. Jay Hills - Ikonik.net (This is an automated response. Please do not reply to this e-mail as it will simply send another back - Thanks) * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Patrick Lauke wrote: actually, I'd go even further than that and say that this is a case in which we may need completely different sites before anybody jumps up and down and scream bloody murder: i'm not talking about browser sniffing, but about having two or more version of the site (ideally all powered by the same content) to allow "modal" access to information. I know a few people who specialise in design and development for mobile devices. When I asked them about CSS support for handhelds they just laughed! They took very much the view you're taking, often having to create multiple versions of the same site for different handheld devices, all powered by the same content obviously. Designing for handhelds (and DTV for that matter) is a very different medium than designing for a computer screen. I know we'd all like to see a world where you develop once and then deploy across multiple platforms, however I'm really not sure how realistic this is. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
> From: Geoff Deering [snip] > If you are designing for handheld you should be considering > display:none for > the none content columns, header and footer and just be using the link > element for prev, next, etc. Some sort of minimalist > approach may be more > appropriate for that media. actually, I'd go even further than that and say that this is a case in which we may need completely different sites (or entry points to the same information) depending on user preference - using something like XSLT, or in any case some hefty-ish server-side system. Then, you could serve targetted content for those who wish to have a minimalist view, or more media rich version for those who want it. before anybody jumps up and down and scream bloody murder: i'm not talking about browser sniffing, but about having two or more version of the site (ideally all powered by the same content) to allow "modal" access to information. yes, you can just display:none, but particularly considering handhelds, mobile phones, etc, you're still sending the data, wasting bandwidth, in an environment where it may well be a scarce commodity (and/or expensive... imagine being charged by the kilobyte or something) just thoughts, P Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
I think you've made some really good points here. > -Original Message- > From: Lee Roberts > > To Fix or not to Fix, dang we're back in Shakespeare's > time with To Be or Not To Be, that is the question. > > Let's start with the easy stuff ... fonts. > > If you use font-size: percentage, then your layer or table > layout widths should be in percentages. > If you use font-size: em, then your layer or table layout > widths should be in em's. > > But, do you know what they both do? > > Interestingly enough, they take the default font size set > in the browser and use it as a basis. If the font-family > is a sans-serif and the user set the browser to 10pt then > 100% would be equal in size to 10pt. If the you used > em's, then the 1em would be equal in size to the 10pt. > This allows the visitor the ability to declare their own > font sizes without the use of programming a stylesheet ... > effectively they are with setting defaults in their > browser. > > So, if I come in and say that I want me font-size to be > 1em or 100% then my font size is relative to the browser's > default. > > Now, coming in and using the width attribute with fixed > values will obviously cause your width to maintain a fixed > value. This is unfriendly to the users of screens smaller > than the values you set. It also doesn't always look > professional on larger screens - in some people's > opinions. > > By applying percentages you end up running the problem > with the presentation causing drip effects in font > presentations once the font-size gets too large. The drip > effect is when the words start dripping off the line and > eventually it will start dripping more quickly so as to > make the words drip their letters as well. (Yes, I coined > the term "drip effect"). > > The only truly scalable width is the em. As you increase > the default font-size, the width increases as well. For > example, if my default sans-serif is 10pt and I change > that to 72pt, then 1em becomes equal to 72pt. If my > mobile device uses a font-size of 6pt then 1em is equal to > 6pt. But, please don't try to use 6pt on a regular > computer. > > The problem with using scalable widths is people tend to > not use them correctly. They'll use a scalable width such > as 100% for the width and then turn around and use px or > pt for their font-size. I've done it many times ... shame > on me. > > But, now you know how to use scalable widths ... you have > to use them with scalable font-sizes. > > So, I guess your next question would be how many em's > would I need to use to make my presentation fill the > screen without scrolling right? That is a good question > and one I can't answer. In fact, you couldn't answer it > either even if you guessed. The reason you can't is > because of the visitor. Each visitor can set their own > font-size values in their browser. And, since the em is > based upon the font-size selected by the visitor, we have > no control. > > My best advice is to tinker until you are happy with the > default presentation. But, remember, you will make > someone scroll right eventually. For example, if the > 800x600 only hold 75em's wide and you decrease the screen > resolution to less than that the user will have to scroll. > But, still the em is the only truly scalable width. > > The purpose of having scalable widths is to help prevent > the "drip effect". > > I hope this helps. > > Lee Roberts > http://www.roserockdesign.com > http://www.applepiecart.com > > > * > The discussion list for http://webstandardsgroup.org/ > See http://webstandardsgroup.org/mail/guidelines.cfm > for some hints on posting to the list & getting help > * > > > * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
> -Original Message- > From: Patrick Griffiths > > I'm quite sure that when the WCAG authors say "absolute" units they are > talking about pixels. If my memory serves me correctly, they more or > less say this. Again, it's open to interpretation, but we all know what > they're getting at, really. No, that is not correct, WCAG directly references the HTML and CSS specifications and does not have their own differing interruptation of any of the specifications. > > The WAI purists would say an all em site is better, but that is just > not > > realistic in todays world. > Sure it's realistic. It's one of many options and some people have opted > for ems and successfully built elastic pages. > It works for simple layouts, but I don't think it works for complex layouts across multiple users agents. If it does, can you please show me an example. -- Geoff Deering * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
To Fix or not to Fix, dang we're back in Shakespeare's time with To Be or Not To Be, that is the question. Let's start with the easy stuff ... fonts. If you use font-size: percentage, then your layer or table layout widths should be in percentages. If you use font-size: em, then your layer or table layout widths should be in em's. But, do you know what they both do? Interestingly enough, they take the default font size set in the browser and use it as a basis. If the font-family is a sans-serif and the user set the browser to 10pt then 100% would be equal in size to 10pt. If the you used em's, then the 1em would be equal in size to the 10pt. This allows the visitor the ability to declare their own font sizes without the use of programming a stylesheet ... effectively they are with setting defaults in their browser. So, if I come in and say that I want me font-size to be 1em or 100% then my font size is relative to the browser's default. Now, coming in and using the width attribute with fixed values will obviously cause your width to maintain a fixed value. This is unfriendly to the users of screens smaller than the values you set. It also doesn't always look professional on larger screens - in some people's opinions. By applying percentages you end up running the problem with the presentation causing drip effects in font presentations once the font-size gets too large. The drip effect is when the words start dripping off the line and eventually it will start dripping more quickly so as to make the words drip their letters as well. (Yes, I coined the term "drip effect"). The only truly scalable width is the em. As you increase the default font-size, the width increases as well. For example, if my default sans-serif is 10pt and I change that to 72pt, then 1em becomes equal to 72pt. If my mobile device uses a font-size of 6pt then 1em is equal to 6pt. But, please don't try to use 6pt on a regular computer. The problem with using scalable widths is people tend to not use them correctly. They'll use a scalable width such as 100% for the width and then turn around and use px or pt for their font-size. I've done it many times ... shame on me. But, now you know how to use scalable widths ... you have to use them with scalable font-sizes. So, I guess your next question would be how many em's would I need to use to make my presentation fill the screen without scrolling right? That is a good question and one I can't answer. In fact, you couldn't answer it either even if you guessed. The reason you can't is because of the visitor. Each visitor can set their own font-size values in their browser. And, since the em is based upon the font-size selected by the visitor, we have no control. My best advice is to tinker until you are happy with the default presentation. But, remember, you will make someone scroll right eventually. For example, if the 800x600 only hold 75em's wide and you decrease the screen resolution to less than that the user will have to scroll. But, still the em is the only truly scalable width. The purpose of having scalable widths is to help prevent the "drip effect". I hope this helps. Lee Roberts http://www.roserockdesign.com http://www.applepiecart.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
> -Original Message- > From: Andy Budd > > Patrick Griffiths wrote: > > Oh, and then there's the accessibility problems with small-screen > > devices. If you were to set your content area to 600px wide, for > > example, some mobile browsers (I'm thinking Pocket PC Windows IE here) > > will apply that width and you have a scrolling nightmare on screens > > that > > will probably be much less than 600px wide. > > If you are embedding widths in the HTML this is definitely an issue. > However if you are doing it using CSS, these devices should really use > 'handheld' stylesheets instead of those intended for 'screen'. > > I doubt that using a flexible layout would be that much better. Take > your typical 3 col layout for instance. Reduced down to a mobile phone > sized screen you'd have exactly the same issue as described in your > first para. i.e. The text in each col would be so squashed up as to be > unreadable. > If you are designing for handheld you should be considering display:none for the none content columns, header and footer and just be using the link element for prev, next, etc. Some sort of minimalist approach may be more appropriate for that media. > > The WCAG are so vague, often with a get out clause of "well, if you > > can't really achieve that then if you vaguely do this to compensate > > then > > that's alright" kind of thing. It's not that difficult to argue that > > something is "AA" for example, because the guidelines give you a lot of > > flexibility and are open to interpretation. This is why, personally, I > > don't think WAI standards badges are that useful. Good as guidelines, > > but not as rules. > > Agreed. One of the reasons I posted here was because there are a few > WCAG members on the list. I'd be interested to hear their rational > behind this guideline. It seems to me that whether you use fixed or > flexible layouts there will always be accessibility issues at the > extreme ends of screen size. > It's always worth taking into account that WCAG1 was released in May 1999, and while it is still relevant, you can almost smell it's ripe old age. Yet, these parts of the guidelines are adapted straight from the principles of Human Computer Interface Guidelines that are deployed by Apple, Microsoft, Sun, Gnome, etc. They are the same principles. Software on all these platforms are built to these standards, and it is also why Assistive Technology fits so well into these particular environments. Take for instance the way the resources of MS SDK API is structured; Icons Cursors Menus Dialog Boxes Bitmaps Fonts String-Tables Accelerators Name-Table Version-Information Menus are never hard coded as bitmaps, because then you would not be able to customise your desktop to your preferences as menu fonts could not be enlarged or changed. The same principle is meant to apply on the web, that is why the WCAG trys to encourage everyone to use the appropriate markup and media. A similar structure can be applied to markup Head Body Text Lists Tables Links Objects, Images & Applets Style Sheets Frames Forms Scripts You try to use the appropriate resource as much as possible. This is meant to return control of how the web is interacted with to the user. I have written a draft of some material that tries to tie all the philosophy of accessibility and how it has developed in WAI back to basic software development, the history of markup and HCI, but I have not worked on it for a while, with also some coverage of applying it to web SLDC and ROI, but I never find the time or motivation to finish it. Basically WCAG is nothing new, if you look back at the development of HCI, it's just taking quite common standards and principles and applied them to the web. Geoff * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Geoff Deering wrote: > The absolute irony here is that pixels (px) are classified as relative > units. I know, I can never get my head around this one either, but it's > great news for those of us trying to get good layouts and address > accessibility. A pixel is relative because it can be any physical size - it can be one millimetre wide or one inch wide, for example. That's not particularly helpful for a web designer though. It *is* absolute in relation to the screen size, which is kind of a contradiction, but a much more useful way to think about it. I'm quite sure that when the WCAG authors say "absolute" units they are talking about pixels. If my memory serves me correctly, they more or less say this. Again, it's open to interpretation, but we all know what they're getting at, really. > The WAI purists would say an all em site is better, but that is just not > realistic in todays world. Sure it's realistic. It's one of many options and some people have opted for ems and successfully built elastic pages. Fido Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
Geoff Deering wrote: > The absolute irony here is that pixels (px) are classified as relative > units. I know, I can never get my head around this one either Well, a pixel at 800x600 has larger physical dimensions than a pixel at 1600x1200. I doubt many people enlarge text by decreasing their resolution, though... ;) Owen This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com CONFIDENTIALITY NOTICE The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you should not disclose, copy, distribute or take action on the contents of this information, except for the purpose of delivery to the addressee. Any unauthorised use is strictly prohibited and may be unlawful. If you have received this email in error please notify the sender by email immediately and delete the message from your computer. ECOTEC Research & Consulting Limited Registered in England No. 1650169 Registered Office: Priestley House, 28-34 Albert Street, Birmingham, B4 7UD, UK Tel: +44 (0)121 616 3600 http://www.ecotec.com * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
> -Original Message- > From: Andy Budd > > For a site to get a AA accessibility rating, you are supposed to use > relative units (%, em) rather than fixed units (px). However the WAI > guidelines do say that, if you use fixed units, you must make sure that > your site is usable. The absolute irony here is that pixels (px) are classified as relative units. I know, I can never get my head around this one either, but it's great news for those of us trying to get good layouts and address accessibility. see http://www.w3.org/TR/1998/WD-css2-19980128/syndata.html#h-4.3 http://www.htmlhelp.com/reference/css/units.html http://www.juicystudio.com/tutorial/css/units.asp Zeldman addresses this on p316 of DWWS. So if you use em and px for the right elements, following the likes of Eric Meyers and Russ's collection of Liquid designs you fullfil that part of WCAG-AA no problems. The WAI purists would say an all em site is better, but that is just not realistic in todays world. > Is it acceptable for the vast majority of fixed width CSS based sites > to claim AA compliance if all other priority 1 and 2 checkpoints are > met? > If they have done that much work to get to almost AA, then it seems that designing with both em and px should not be too much of a further step to take. - Geoff Deering * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Andy Budd wrote: > If you are embedding widths in the HTML this is definitely an issue. > However if you are doing it using CSS, these devices should really use > 'handheld' stylesheets instead of those intended for 'screen'. Indeed they should. Unfortunately, a lot of mobile browsers (such as PPC IE) apply the screen media type. > I doubt that using a flexible layout would be that much better. Take > your typical 3 col layout for instance. Reduced down to a mobile phone > sized screen you'd have exactly the same issue as described in your > first para. i.e. The text in each col would be so squashed up as to be > unreadable. For some (maybe most) devices, sure, but some screens (especially those on PDA's and PDA-style phones) are wide enough to accommodate multi-column layouts. It depends what you need to do with your design. 3 columns would certainly be pushing it, but two column or (obviously) single column designs would probably usually work better within a fluid design. Like I say, it comes down to what you're trying to do with the page. Dog Boy Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: "Andy Budd" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 30, 2004 11:53 AM Subject: Re: [WSG] Fixed vs flexible layouts > Patrick Griffiths wrote: > > > The accessibility concern with fixed (pixel) width layouts that > > instantly jumps to mind is that if a user with poor eyesight decides to > > bump up the text size, you're going to find yourself with fewer words > > per line. If you're not careful, such an action can lead to content > > being more difficult to read, especially in narrow columns. This is one > > of the benefits of elastic fixed (em) width layouts - you should > > maintain the same number of words on a line, no matter what the text > > size (but then, the larger it gets, the greater the likelihood of > > dreaded horizontal scroll bars appearing gets). > > That's my problem with using ems. You maintain the 'words per line' but > risk horizontal scrolling. Yet the horizontal scrolling/small screen > issue seems to be the main reason why the WAI advocate using relative > units instead of absolute units. > > > Oh, and then there's the accessibility problems with small-screen > > devices. If you were to set your content area to 600px wide, for > > example, some mobile browsers (I'm thinking Pocket PC Windows IE here) > > will apply that width and you have a scrolling nightmare on screens > > that > > will probably be much less than 600px wide. > > If you are embedding widths in the HTML this is definitely an issue. > However if you are doing it using CSS, these devices should really use > 'handheld' stylesheets instead of those intended for 'screen'. > > I doubt that using a flexible layout would be that much better. Take > your typical 3 col layout for instance. Reduced down to a mobile phone > sized screen you'd have exactly the same issue as described in your > first para. i.e. The text in each col would be so squashed up as to be > unreadable. > > > The WCAG are so vague, often with a get out clause of "well, if you > > can't really achieve that then if you vaguely do this to compensate > > then > > that's alright" kind of thing. It's not that difficult to argue that > > something is "AA" for example, because the guidelines give you a lot of > > flexibility and are open to interpretation. This is why, personally, I > > don't think WAI standards badges are that useful. Good as guidelines, > > but not as rules. > > Agreed. One of the reasons I posted here was because there are a few > WCAG members on the list. I'd be interested to hear their rational > behind this guideline. It seems to me that whether you use fixed or > flexible layouts there will always be accessibility issues at the > extreme ends of screen size. > > Andy Budd > > http://www.message.uk.com/ > > * > The discussion list for http://webstandardsgroup.org/ > See http://webstandardsgroup.org/mail/guidelines.cfm > for some hints on posting to the list & getting help > * > * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Patrick Griffiths wrote: The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). That's my problem with using ems. You maintain the 'words per line' but risk horizontal scrolling. Yet the horizontal scrolling/small screen issue seems to be the main reason why the WAI advocate using relative units instead of absolute units. Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. If you are embedding widths in the HTML this is definitely an issue. However if you are doing it using CSS, these devices should really use 'handheld' stylesheets instead of those intended for 'screen'. I doubt that using a flexible layout would be that much better. Take your typical 3 col layout for instance. Reduced down to a mobile phone sized screen you'd have exactly the same issue as described in your first para. i.e. The text in each col would be so squashed up as to be unreadable. The WCAG are so vague, often with a get out clause of "well, if you can't really achieve that then if you vaguely do this to compensate then that's alright" kind of thing. It's not that difficult to argue that something is "AA" for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Agreed. One of the reasons I posted here was because there are a few WCAG members on the list. I'd be interested to hear their rational behind this guideline. It seems to me that whether you use fixed or flexible layouts there will always be accessibility issues at the extreme ends of screen size. Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Well im just swaying away from my "gotta keep it fixed" way of thinking and slowly getting on with "Stretch it like a rubber Johnny" as i still dont think a full fluid layout works 100% of the time. But an Elastic one does! As you can still set your width's and if you do everything in EM's images,margins,padding and borders then it should scale up and down very well! the only problem i've seen is with the like of floats and positioning... I've started playing with this (http://www.southtyneside.info/project_area/southtyneside/xhtml/test.asp) yesterday to see if an Elastic design is viable and im pretty much set to move over from Pixel to EM's as it not any harder, just gotta learn the relative size's! The only thing i've found a problem is controling the Text size! Cos as soon as you change the font-size of and element it starts to mess with it width and height too!! * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
I'd argue that the best compromise are elastic layouts, where things are positioned and sized in relation to other factors like font size. To say that if we just set our width to 100% or something and rejoice that the site will work in all sizes is misguided; there will always be extremes at both ends of the spectrum (really large desktop sizes, really tiny handheld displays) which will need a complete rethink. As for "can I claim AA", I'd say the most pragmatic approach would be - and I know I keep banging on about it, but hear me out once more - to create separate stylesheets, a "designery" one (with fixed/elastic layout, pastel colours, small-ish font size, all that stuff) and a more accessible one (flexbile layout, higher contrast, slightly large font sizes, etc) and a clear, simple, and obviously accessible mechanism to switch between them. A bit like the "if you can't make it accessible, offer an accessible alternative" idea (and certainly a lot better than "text only" versions). And going back to the problem of extremes (ultra large/ultra small displays), I could envisage a few more stylesheets available..."lightweight" (which could also be set to media="handheld" for instance (if any of those little bleeders actually support/understand it), "widescreen", "tv" (again, couple with a media="tv" attribute)... (to muddy the waters further, there's also, in my mind, an issue of adapting the content itself to the context; if I'm using a browser on a small mobile phone and access, say, a cinema website, I don't care about the flash intro, the sections about the history of that particular company, etc...I'm just after a quick way to check times when movies are playing; the context is different, my purpose is different, and possibly the site should be different - maybe as a separate domain, or in any case showing a different view into the same data that is more tailored to that specific situation. heck, I'm digressing quite badly here) But yes, my personal opinion, worth about GBP0.02 or less :) Patrick Patrick H. Lauke Webmaster / University of Salford http://www.salford.ac.uk > -Original Message- > From: Andy Budd [mailto:[EMAIL PROTECTED] > Sent: 30 July 2004 10:47 > To: [EMAIL PROTECTED] > Subject: [WSG] Fixed vs flexible layouts > > > Hi folks, > > Everybody has an opinion on fixed vs flexible layouts. Some people > prefer how fixed width sites look, and there is little doubt > that they > are easier to build. Others hate the whitespace around fixed width > designs, thinking they look ridiculous on large monitors. > > For a site to get a AA accessibility rating, you are supposed to use > relative units (%, em) rather than fixed units (px). However the WAI > guidelines do say that, if you use fixed units, you must make > sure that > your site is usable. > > Personal preferences aside, what "accessibility" problems to > people see > with fixed width layouts and what are the scale of these problems. > Could the same arguments hold true for "elastic layouts" > (layouts based > on ems) and do "flexible layouts" (those based on %) have their own > accessibility issues? > > Is it acceptable for the vast majority of fixed width CSS based sites > to claim AA compliance if all other priority 1 and 2 checkpoints are > met? > > Andy Budd > > http://www.message.uk.com/ > > * > The discussion list for http://webstandardsgroup.org/ > See http://webstandardsgroup.org/mail/guidelines.cfm > for some hints on posting to the list & getting help > * > > * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
Re: [WSG] Fixed vs flexible layouts
Fixed vs. Liquid. Excellent! I love these arguments. I'm sure we'll see about 300 replies to this that go way off topic in a general "Fixed is better!" - "NO! Liquid is better" style. The accessibility concern with fixed (pixel) width layouts that instantly jumps to mind is that if a user with poor eyesight decides to bump up the text size, you're going to find yourself with fewer words per line. If you're not careful, such an action can lead to content being more difficult to read, especially in narrow columns. This is one of the benefits of elastic fixed (em) width layouts - you should maintain the same number of words on a line, no matter what the text size (but then, the larger it gets, the greater the likelihood of dreaded horizontal scroll bars appearing gets). Oh, and then there's the accessibility problems with small-screen devices. If you were to set your content area to 600px wide, for example, some mobile browsers (I'm thinking Pocket PC Windows IE here) will apply that width and you have a scrolling nightmare on screens that will probably be much less than 600px wide. The WCAG are so vague, often with a get out clause of "well, if you can't really achieve that then if you vaguely do this to compensate then that's alright" kind of thing. It's not that difficult to argue that something is "AA" for example, because the guidelines give you a lot of flexibility and are open to interpretation. This is why, personally, I don't think WAI standards badges are that useful. Good as guidelines, but not as rules. Patrick Patrick Griffiths (PTG) http://www.htmldog.com/ptg/ http://www.htmldog.com - Original Message - From: "Andy Budd" > > For a site to get a AA accessibility rating, you are supposed to use > relative units (%, em) rather than fixed units (px). However the WAI > guidelines do say that, if you use fixed units, you must make sure that > your site is usable. > > Personal preferences aside, what "accessibility" problems to people see > with fixed width layouts and what are the scale of these problems. > Could the same arguments hold true for "elastic layouts" (layouts based > on ems) and do "flexible layouts" (those based on %) have their own > accessibility issues? > > Is it acceptable for the vast majority of fixed width CSS based sites > to claim AA compliance if all other priority 1 and 2 checkpoints are > met? * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
RE: [WSG] Fixed vs flexible layouts
I have not made a study of the accessibility guidelines in depth, but my guess would be that they are referring to elements that can be resized like text rather than positional elements and that confusion arises because of vagueness like that. Just a thought, probably wrong, but hey. :) -- Iain Gardiner http://www.firelightning.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Budd Sent: 30 July 2004 10:47 To: [EMAIL PROTECTED] Subject: [WSG] Fixed vs flexible layouts Hi folks, Everybody has an opinion on fixed vs flexible layouts. Some people prefer how fixed width sites look, and there is little doubt that they are easier to build. Others hate the whitespace around fixed width designs, thinking they look ridiculous on large monitors. For a site to get a AA accessibility rating, you are supposed to use relative units (%, em) rather than fixed units (px). However the WAI guidelines do say that, if you use fixed units, you must make sure that your site is usable. Personal preferences aside, what "accessibility" problems to people see with fixed width layouts and what are the scale of these problems. Could the same arguments hold true for "elastic layouts" (layouts based on ems) and do "flexible layouts" (those based on %) have their own accessibility issues? Is it acceptable for the vast majority of fixed width CSS based sites to claim AA compliance if all other priority 1 and 2 checkpoints are met? Andy Budd http://www.message.uk.com/ * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help * * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help *
