TW Blog :: Entries for Accessibility
Architecture is frozen musicFreidrich Schelling
DRC Report Arrives
This post does not relate to any other topics
The DRC formal investigation into web accessibility has released its findings today in this comprehensive report (PDF File, 406KB).
This report demonstrates that most websites are inaccessible to many disabled people and fail to satisfy even the most basic standards for accessibility recommended by the World Wide Web Consortium.
[snip.]
Organisations that offer goods and services on the Web already have a legal duty to make their sites accessible. It is clear from the investigation that these duties are not being fulfilled. The Commission's policy is to seek improvement in the first instance through advice and conciliation, and this report contains a range of recommendations to help website owners and developers tackle the barriers to inclusive design. However, where the response is inadequate, we shall be vigorous in the use of our enforcement powers; these range from namedparty Formal Investigations which can lead to sanctions against the owners of inaccessible websites, to the provision of support for test cases being brought by individual disabled people.
DRC Formal Investigation Report: Web Accessibility, Foreward vi.
The report raises some criticism of the overall ability of the WAI Guidelines and automated test suites for validating accessible sites and the WAI have posted a rebuttal to some potentially misleading analysis in the report.
Posted on Apr 14, 2004 at 14:12:42. [Comments for DRC Report Arrives- 0]
Article On Accessible DHTML
Also relates to DOM Scripting
One of my aims now the new site is up and running is to start writing some articles. I regularly find my blog entries become too drawn out, and ideally these would be better presented as short articles. As always, I am currently way too busy to really get underway with this. However, to get the ball rolling, I have posted a short article on creating DHTML content without compromising accessibility. It basically surmises the process I went through on a recent site development to create a manual image slideshow, hence allowing the maximum preservation of screen real estate.
I haven't found time to add a comments section following the article (which I do hope to do for all future articles, since discussion generally brings out further ideas and enhancements). However, feel free to post any remarks, criticisms, or errors for the article under this blog entry. I hope it is of use to those crossing the accessibility threashold.
Posted on Feb 25, 2004 at 23:04:08. [Comments for Article On Accessible DHTML- 0]
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]
