"Liquid Layout"
Hi,
We are currently working with a client on a site that will aim to be compliant with WCAG 1.0 Level AA. With respect to checkpoint 3.4 we have an issue with a part of the site's home page where it is unlikely for aesthetic reasons that we will comply (it is essentially a set of images in layers that absolutely positioned).
We have considered an alternative that doesn't have any graphical elements so liquidity wouldn't be an issue but we want to avoid this is possible.
Does anyone have any experience of dealing with small exceptions to compliance? Are such exceptions generally accepted if they can be justified? Should we go as far as declaring this in the accessibilty statement?
Any advice gratefully received.
Best Regards,
Kirk
Share: 
Providing an example of the page in question would let us see the issue in full context. That's often the only way to determine whether it would be alright or not.
For some elements of a page, it makes sense to use pixel units. For example, images have width and height attributes which use pixel units. These reserve a space of that in the layout size while the image is downloading. Since the image will be a certain size in pixels, it makes sense that images will be sized using pixels.
The problems with pixel sized containers are normally to do with them containing text.
Share:
If the images are purely decorative, and the remaining content is accessible, I would probably just ignore it (there are worse things you could do 
)
Alternatively, note any exceptions to compliance in an accessibility statement.
Share:
If for whatever reasons you cannot technically create a true liquid layout, then consider a 'Jello' alternative, where most elements of the site are fully liquid, ie, menus, text, column widths etc., but your images are positioned absolutely in a container which is positioned relative to the rest of the content.
"everything is relative"
http://www.opsi.gov.uk/acts/acts1995/Ukpga_19950050_en_8.htm#mdiv57
Share:
Hi Kirk,
I disect a few options here:
http://alastairc.ac/2006/05/accessible-layouts/
The bottom line is that you should test the design (in HTML form) under a range of conditions. Every unit doesn't have to be relative, but it should seem as though it is...
Hth,
-Alastair
Share:
According to the W3C, you can't claim partial exceptions. Read what the WAI says about baselines especially with reguards to conformance. Unless, of course, I have misunderstood them.Jonathan Worent
The early bird gets the worm, but the second mouse gets the cheese.
Share:
Well, if you're going to apply WCAG 2.0, could you find where it talks about relative sizing on layouts please?
The closest I could find was in the comparison doc:
http://www.w3.org/TR/WCAG20/appendixD.html
However, that led to a dead end.
Version 1 or version 2, no mixing allowed!
Share:
| jw_developer wrote: |
| According to the W3C, you can't claim partial exceptions. Read what the WAI says about baselines especially with reguards to conformance. Unless, of course, I have misunderstood them. |
which is why i usually tend *not* to make any strict compliance claims, but using phrases like "we strive to comply to WCAG 1.0 AA, as interpreted by the web team". this way, i've got a bit more latitude to make a conscious decision to ignore guidelines which i find outdated (e.g. all the "until user agents..." ones) or just badly phrased.
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
| Alastc wrote: |
| Well, if you're going to apply WCAG 2.0, could you find where it talks about relative sizing on layouts please?
The closest I could find was in the comparison doc: http://www.w3.org/TR/WCAG20/appendixD.html However, that led to a dead end. |
There's an error in the comparison chart. Assuming that you mean this bit
| Quote: |
|
3.4: Use relative rather than absolute units in markup language attribute values and style sheet property values. This maps to an advisory technique (Using readable fonts) for Guideline 1.4. |
It should actually say 1.3, not 1.4, and point towards the "Providing resizable text (future link)" mentioned here http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#content-structure-separation
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
you should also bear in mind that the pixel unit is a relative unit according to the css specification, and therefore a liquid layout may not be mandatory in order to achieve AA accessibility (although some sources, such as the eAccessibility of Public Sector Services in the European Union insist that a fixed width layout does not meet AA guidelines).
In practise, I would prefer column widths etc to be elastic or liquid but I think it's a nonsense to suggest that a margin of 2px would be better coded as 0.1em (or whatever). Px units are seen as less accessible/usable (depends on your take - my take is that it could be accessible if it's text size but layout is usability) than em or % units because the user is in general, less able to alter their scaling.
The end goal of accessibility is either to:-
- make your site available to all users
- make your site available to users with disabilities
(as this rather depends on your definition of accessibility!)
In either case, your goal should not be "to satisfy a particular checkpoint", but to make your site available to more people. If you can find an example where using a 2px margin will make your site inaccessible to some people, then by all means use the em size - but do so understanding why you are doing it and not just because of some myth that px units are inherently "bad"!
[EDIT: note that the reference Redux supplied suggests that TEXT should be resizable as an advisory for WCAG 2 1.3; there is no mention that fixed widths should not be used.]
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
Thanks Patrick,
I'll have a look around for a bug list later, and prod them on that (checking someone hasn't already, of course
I went through the WCAG v2 in detail in august '04, and didn't find a direct equivalent for the relative units checkpoint then. I need to go through it again now, but at first glance I'm struggling to find any guidance on layouts.
This is the nearest I can see:
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#F1
But it's more to do with not using presentational cues to change the meaning/order than visual layout.
Please be aware that I approached that article based on experience with people who use assistive technologies and what works in practice, I wasn't trying to preempt WCAG 2, just help on how to test layouts.
Share:
| JackP wrote: |
| I think it's a nonsense to suggest that a margin of 2px would be better coded as 0.1em |
Visually impaired people often require large text sizes because they can't make out small details. By using em to space text away from edges, the gap will remain as visible as the text for them. Similarly, using em for borders ensures they will grow with text size to remain visible. This prevents text from seeming to run up against edges, images or other sections of text.
It's a bit like colour contrast; relative units for gaps and borders should improve the readability for visually impaired people. I think that makes it an issue for WCAG-defined accessibility.
A 2px gap will seem small at 1024x768 on a smallish monitor. However, it will take up about twice as much space on a medium screen device. An em gap woud adapt to user's text size preferences, keeping these gaps relative to gaps between words and letters in the text. For media="handheld" devices, common screen widths range from about 150px to 320px. A pixel unit in a stylesheet for these would appear twice as big on a cheap phone than an expensive phone, while the equivalent em will adapt to suit the user's text setting.
This seems to makes it an issue of usability and device independance, too.
That's my understand of it, anyway. Accessibility is more than ticking a checklist but the items in WCAG were written to address these real-world issues.
Share:
| Cerbera wrote: |
| Actually, using ems for small gaps should be advantageous in some circumstances for some users (and detrimental to none). |
Up to a point, but consider Eric Meyer's site (which is great, and he is the godfather of CSS in my eyes, but demonstrates this point).
If margins grow, they can actually squeeze out the content. I don't think there will be a good answer to this unless Andy Budd's request for min/max on margins and padding comes to fruition.
| Cerbera wrote: |
| Accessibility is more than ticking a checklist but the items in WCAG were written to address these real-world issues. |
Totally agree. Not sure where we stand with WCAG 2 on this though, I've posted to the WAI interest group to see if anyone knows.
Share: