April 14, 2003

Opera 7.10

Opera has released yet another version of their browser.

Opera 7.10 incorporates a few new features including:

Posted by Andrew at 09:52 PM

April 13, 2003

GetContentSize

This cool utility calculates the percentage of a page's HTML that is markup and that which is content.

I was actually surprised at how few of my pages' dedicated even 50% of their file size to content.

Perhaps it's time for me to start optimizing ☺.

Posted by Andrew at 03:19 AM

April 08, 2003

Opera 6 upgrade

Recently, after public outcry, Opera released an upgrade to version 6 of its browser. Version 6.06 fixes some security issues that were discovered after version 7 had already been released. This breaks with the company's previous tradition of not releasing updates for browser versions other than the most current release.

I applaud this move, even though I, unlike many others, prefer Opera 7 over 6. Opera is, after all, commercial software, and customers should expect a certain level of continuing support for software that they've purchased.

Posted by Andrew at 08:49 PM

April 03, 2003

An accessibility rant

The following was a little piece that I wrote in response to some posts on the Web4Lib discussion list commenting on the inherent inaccessibility of DHTML menus.


***************************************

Replies inline:

TD> that you have
TD> a responsibility to support users who use keyboard navigation and those
TD> who have Javascript disabled. Making essential site navigation
TD> available only through Javascript mouseovers is a serious accessibility
TD> failure.

Very true, but it isn't as hard to make such things accessible as some
people would have you believe.

Creating a keyboard navigation-compatible DHTML menu isn't any more
difficult than creating keyboard navigation on any other page.

It's also quite easy to make JavaScript-based navigation degrade to simple HTML links when
JavaScript is turned off.

<div class="menuLabel" id="menuLabel1"><a class="ml" onclick="menuShow(event,1); return false;"
onmouseover="menuShow(event,1)" href="items.html" accesskey="l"><span style="text-decoration: underline;">L</span>abel1</a></div>

<div class="menuBox" id="menu1">
<a class="m" href="item1.html" accesskey="1">Item <span style="text-decoration: underline;">1</span></a><br>
<a class="m" href="item2.html" accesskey="2">Item <span style="text-decoration: underline;">2</span></a><br>
<a class="m" href="item3.html" accesskey="3">Item <span style="text-decoration: underline;">3</span></a><br>
</div>


The example above shows the markup for a simple DHTML menu.

The first couple lines contain define the menu label. Including an
href and the "return false" within the on onclick event handler allows
the menu label to function as a plain HTML link when JavaScript is
turned off.

Also, you'll notice that each of the menu links employs an accesskey
to ease keyboard navigation.


EO> please also include
EO> some method to skip the navigation for text/limited-or-no-sight browser
EO> users. Methods include the 1x1 pixel "invisible" gif with link to anchor
EO> after the navigation and/or use CSS to create an aural (and/or print)
EO> stylesheet. If anyone has another method, please let me know.

Another method is to use CSS set the link text's display to "hidden".

Examples of both methods are below:

<a name="topofpage" id="linktocontent" href="#content" style="display:hidden;">skip to main content</a>
<a href="#content" title="skip to main content"><img src="spacer.gif" alt="skip to main content - image link" border="0"></a>

Both of these methods will satisfy section o of Section 508:
A method shall be provided that permits users to skip repetitive
navigation links.


PLP> I run into this issue frequently. Some people think javascript mouseover
PLP> menus are a good way of cramming lots of choices on the page, without making
PLP> it look crowded.

Menus are a very good way of placing many choices into a small area.
Additionally, menu conventions are firmly established, with OS GUIs
making wide use of menus.

PLP> So, before using javascript, I think one should try to organize their pages
PLP> better, perhaps a different schema is needed if the menus are necessary.

Menus are rarely necessary, however they can greatly clean up an
interface that would otherwise be cluttered. Also,

PLP> If on the other hand, it must be, my understanding of accessibility is that
PLP> as long as there is an alternative, it is fine.

Yes and no.

Yes, if you can't make your pages accessible through other means, then
alternatives are needed. Again, this is clearly stated in Section
508:

(k) A text-only page, with equivalent information or functionality, shall be
provided to make a web site comply with the provisions of this part, when
compliance cannot be accomplished in any other way. The content of the
text-only page shall be updated whenever the primary page changes.

Please note the words "cannot be accomplished in any other way"
above.

In addition to creating a duplicate site maintenance need, alternative
content and/or functionality is all too often simply slapped onto a
site. While this may technically provide compliance, it can lead to
an attitude of complacency towards accessibility and site design for
alternate access devices.

Remember, accessibility is just one part of site design. You still
must make an effort to make sure that your users will be able to
effectively interact with your site no matter which user agent they
are using. You can create a site that complies with all of the
accessibility guidelines, yet still be a nightmare to use with an
alternate access device.

Just like site design for conventional visual browsers, accessibility
(ensuring cross-browser compatibility is simply accessibility applied
to visual browsers) is just one aspect of ensuring that your site
functions well, and no level of accessibility guideline compliance
alone will ensure that your users will be able to easily use your
site.


--
Andrew

Posted by Andrew at 10:56 PM

Mozilla 1.4a is out

Mozilla released version 1.4a of its browser suite this week.

This release is widely rumored to be the basis for the next Netscape release, which to this point has been based on the 1.0 branch. This would appear to make sense with the new Mozilla project plans announced in the newly revised Mozilla Roadmap, which states that the 1.4 branch will replace the 1.0 branch as the "stable" branch.

Posted by Andrew at 07:23 PM
a