TW Blog :: Entries for Accessibility
The finite has no genuine beingGeorg Wilhelm Friedrich Hegel
CSS Zoom Factor
Also relates to CSS Design
Recently I have been considering the CSS Zoom Factor (or Full Page Zoom) as a very viable option for controlling the size of the root container in a design layout. There are several examples of this technique on the CSS Wiki, and it has already produced extensive discussion on Simon Willison's Blog but it does not seem to have been widely adopted as an alternative to fixed width or percentages yet.
In short, CSS Zoom declares the root container dimensions in a unit relative to the font size (em). This allows the whole page to scale up and down when font-size is adjusted. The new design of my business (and blog) site utilise this method. I actually stumbled on it by chance initially - one of those trial and error situations - but as the design developed, it became clear that this method resolved a number of limitations of fixed dimensions and percentage dimensions:
- Text breaking out of columns above several levels of magnification.
- Resolution limitations - fixed dimension columnar designs can become squashed and barely legible at super high resolutions with several magnifications of zoom. Percentage dimension designs will resize to the resolution, but they suffer the same problem at a single resolution when font is increased extensively. Similar problems can arise when down sizing resolution and font-size.
- Precise positioning can easily be broken in fixed and percentage dimensions. A typical example I have experienced several times is the absolute placement of a horizontal navigation bar. As font size increases the content may fold over to two lines, hence breaking the synchronisation of following content..
CSS Zoom also has disadvantages:
- Images do not resize with the text (except Opera's internal zoom mechanism), so blank spaces will soon appear where the design is image specific.
- Nesting fixed width elements (eg floated elements) inside the relative parent can become impossible.
- If a user is re sizing the font to a very large size at a small resolution, much of the page is going to be forced out of the viewable area requiring horizontal scrolling.
I think the last point mentioned above is a major issue. There are likely to be two groups of users who resize fonts - those with extra large screen resolutions and those with poor visibility. The application of CSS Zoom is ideal for the first group but forcing an impaired user to scroll horizontally impinges negatively on the accessibility of a page. Arguably, many fixed width/percentage width designs can become quite illegible at extra large font-sizes anyway (3 to 4 times zoom), while the Zoom factor will still maintain its form. Also with careful design planning, a columnar layout can allow a single column to display clearly within the viewable area at high resolutions.
The three column layout displayed on Severn Solutions has been designed to take this into account. As an example, the home page can be resized in Firebird to five times magnification at 1024 by 768 screen resolution and allow each column to be read clearly with only vertical scrolling, once it has been screen centred. While the larger blog column layout can be resized to three times magnification without the need for horizontal scroll.
UPDATE - 2004-02-10. Recent testing has shown that a centre-aligned root container in the document body must have a border declared to prevent the container from disappearing off the left edge of the screen as the font is increased.
Posted on Feb 08, 2004 at 04:29:35. [Comments for CSS Zoom Factor- 0]
IE5.0 Versus IE5.5
Also relates to Exploder
I am a strong advocate of accessibility, and make every effort to sell and build website for clients that are conforming to the WCAG, while maintaining Web Standards and page validity. For all the hard work, sometimes those ever so standards-friendly browsers from Micro$oft put a spanner in the works!
On completion of a recent website, with all the usual set of validity and accessibility tests, I was perturbed to hear from the client that the display on screen was total chaos! As it turned out, they had just had MS 2000 Pro installed, accompanied by IE5.0 as the default browser. While I urged them to upgrade their browsers, it was conceivable that a portion of the target audience would also be using IE5.0, and so the pages were not accessible. A few weeks ago, this would have been a real issue with no way for me to test where the problems were arising, but fortunately recent discoveries allow testing over the full range of IE browsers.
So I got to testing, and soon traced down the glitches to a couple of CSS incompatibility issues
for IE5.0. The major cause of so much destruction was the use of relative for container positioning, and IE5.0's reluctance
to acknowledge the height attributes in these containers. I knew declaring position:relative was a cause for disappearing elements
across IE5.x and had formulated personal guidelines for using this declaration, but did not know it could eat appart the display in IE5.0.
Most CSS hacks for hiding code seem to classify IE5.x as a single entity, but in this case I needed to write different code for IE5.0 and IE5.5, otherwise one of them would fail to display correctly. The best solution I found in the archives is the following snippet:
div#id {
position: static; [1]
position/* */:/**/:relative; [2]
position:relative; [3]
}
- Line [1] is read by all browsers - final value for IE5.0
- Line [2] is ignored by IE5.0 and IE5.5 but read by all other browsers
- Line [3] is also ignored by IE5.0 but is read by IE5.5 - final value for IE5.5
It is a great shame when so much work is put into accessibility for all browser mediums and users, yet making a site accessible for the client rests on a bunch of ugly hacks! I suppose a better long term solution to this would be to separate this bunch of IE CSS hacks using Tantek's Mid Pass Filter. Then, once these legacy browsers have finally been put down, the hacked files could just be discarded.
Posted on Nov 18, 2003 at 18:03:00. [Comments for IE5.0 Versus IE5.5- 0]
Key Press Event Revisited
Also relates to DOM Scripting and Firefox and Co
In a posting last month I presented an onkeypress event handling script to avoid the Mozilla browsers triggering the event when the user tabs of the anchor. This was achieved by
calling an intermediary function when the onkeypress event handler was triggered that would call the final function (in this case a style switcher) only if the pressed key was return.
While this resolved the problem, I discovered the other day that a better solution is to just call the onclick event of the same anchor element when the onkeypress event is triggered.
<a href="#" onclick="setStyleSheet('sheet'); return false;"
onkeypress="this.onclick">Switch to List View</a>This works fine on the Mozilla browsers and does not raise the problem when the function is called directly by the event handler. Also, there is no need to hard code this and it can be extracted to a DOM creation scripting once the page has loaded, thus making the markup ever so slightly purer.
Posted on Oct 15, 2003 at 04:49:05. [Comments for Key Press Event Revisited- 3]
Does RNIB See It Right?
Also relates to Web Standards
In follow up to Andrew Sinclair's Accessibility Article I had a quick reccie of the Anglia Railways website, mentioned in the article for its recent receipt of the RNIB See It Right logo.
The W3C Validator failed the home page with 80 errors, many of which were associated with incorrect embedding of Flash objects in the page and entity errors in URL query strings, but also failure to close a few elements.
Bobby (an official part of the
RNIB audit) was equally less forgiving, picking up on absolute sizing at Level 2. Cynthia was equally unhappy with the use of the deprecated embed element. View the page in Mozilla and there is an immediate problem with the on and return labels. Blow
up the text 2 times and the page quickly become difficult to view.
So, what exactly does the RNIB See It Right campaign represent? Perhaps the Anglia Railways site passed the audit a week ago, but has changed since then. Or perhaps a few important accessibility issues are brushed under the table as not relevant to this specific audit - the errors are perhaps not relevant for screen readers and braille browsers? Well clearly, valid and well formed markup is of little importance, with the Audit guidelines page failing to supply a DOCTYPE!
Posted on Sep 19, 2003 at 13:31:52. [Comments for Does RNIB See It Right?- 1]
Key Press Event Handling
Also relates to DOM Scripting and Firefox and Co
On a current project, where accessibility is essential, I have integrated a stylesheet switcher on two pages where a mouseover affect on an image montage displays an introduction to each page in a separate box below the montage. The montage is structurally defined as a definition list, since it is a visual representation of links to pages on the site, with a brief description of each page. The stylesheet switcher allows users to switch the view to an actual list representation, if, for example, they are using only the keyboard. For CSS-enabled browsers without Javascript, the switcher loads a fresh page with the list display, and for non-display browsers the montage is just represented as a list from the outset.
While, I hope this will be effective under most conditions, I found a frustrating problem with supplementing
the onclick event with an onkeypress event for keyboard users in Mozilla and co.
When tabbing through the links on the page, as soon as the user tabs off the switcher (containing the event handler)
the key press event is triggered. Well, of course, this is the correct behaviour, but Inte$net Exploder actually only
triggers the event when the Return key is pressed, which is misleading to the developer, and incorrect interpretation.
The solution was to integrate a filter function that is called by the onkeypress event and this in turn only
calls the style switcher function if the key pressed was Return
Here is the code:
function checkKeyPressed(evt, func, params)
{
evt = (evt) ? evt : (window.event) ? event : null;
if (evt)
{
var charCode = (evt.charCode) ? evt.charCode :
((evt.keyCode) ? evt.keyCode :
((evt.which) ? evt.which : 0));
if (charCode == 13) func(params);
}
}
Where 13 is the ASCII value for the Return key. As well as passing the event as argument, I passed the function to be called and its parameters, to make the function generic. The scenario is just as relevant if using the event handlers to open a new window from a link (although this is strongly discouraged). The resulting anchor is as follows:
<a href="#" onclick="setStyleSheet('sheet'); return false;"
onkeypress="checkKeyPressed(event, setStyleSheet, 'sheet');"
>Switch to List View</a>
It is important that a false value is not returned in the key press event since this would prevent the user from tabbing beyond the style switcher link. The DHTML cookbook suggests the key detection in the filter should work in Netscape and Exploder back to v.4. It resolved the issue for this project.
Posted on Sep 14, 2003 at 16:44:31. [Comments for Key Press Event Handling- 7]
