[WSG] Daniel Beckitt is out of the office.

[daniel . b . beckitt]

I will be out of the office starting  22/06/2007 and will not return until
28/06/2007.

I will respond to your message when I return.

For urgent enquiries, please contact the Highway21 Team on 3032 3456.


***
WARNING: This e-mail (including any attachments) may contain legally
privileged, confidential or private information and may be protected by
copyright. You may only use it if you are the person(s) it was intended
to be sent to and if you use it in an authorised way.  No one is 
allowed to use, review, alter, transmit, disclose, distribute, print 
or copy this e-mail without appropriate authority.

If this e-mail was not intended for you and was sent to you by mistake,
please telephone or e-mail me immediately, destroy any hardcopies of
this e-mail and delete it and any copies of it from your computer
system. Any right which the sender may have under copyright law, and 
any legal privilege and confidentiality attached to this e-mail is not 
waived or destroyed by that mistake.

It is your responsibility to ensure that this e-mail does not contain
and is not affected by computer viruses, defects or interference by
third parties or replication problems (including incompatibility with
your computer system).

Opinions contained in this e-mail do not necessarily reflect the
opinions of the Queensland Department of Main Roads, Queensland
Transport or Maritime Safety Queensland, or endorsed organisations
utilising the same infrastructure.
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] IE7 zoom collapses horizontal tab navigation

[Miles Tillinger]

This is a centered tab menu based on Alistapart's Sliding Doors concept.
The IE7 zoom tool is making the anchor text in the tabs 'collapse' away
from the tab background images.  See example:
http://www.streetdaddy.com/temp/ce/
 
It only happens when the li is display: block (needed to center the ul).
Its fine if the li's are floated.
 
I can't seem to find a fix for the problem, but it must be out there...
anyone?
 
Cheers,
 
Miles.
 

IMPORTANT: This e-mail, including any attachments, may contain private or 
confidential information.
If you think you may not be the intended recipient, or if you have received 
this e-mail in error, please contact the sender immediately and delete all 
copies of this e-mail. 
If you are not the intended recipient, you must not reproduce any part of this 
e-mail or disclose its contents to any other party. 
This email represents the views of the individual sender, which do not 
necessarily reflect those of education.au limited except where the sender 
expressly states otherwise. 
It is your responsibility to scan this email and any files transmitted with it 
for viruses or any other defects. education.au limited will not be liable for 
any loss, damage or consequence caused directly or indirectly by this email.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] intuitive text resizer for accessibility toolbar

[Benedict Wyss]

Ya gotta love the WSG,

This is exactly why I post here, where people respond with decent honest
answers with out too much in the way of restriction.

For that I thank you! :-)

All right, so I exaggerated on the "Government Standard", you got me.;-)


I am still unsure on how to proceed, so bare with me a little longer.

Even though I agree on the fixed reasonable font size but, with some sites
there is an over stuffing of content and we have managed to trim the content
owners down on this and so arrive at an agreed amount that if fixed at a
larger font will turn the page into more than necessary scrolling which in
the end leads to a percentage not willing to scroll too much. (no there are
not masses of content).

So even faced with the official W3C standards we still have to compromise
whether we like it or not and so I ask the pointed question - What is the
happy medium?

Please don't quote the various Standards bibles because I am not about that,
we as web developers need to live with in these standards and if a few
conflict with each other then that is what we can come here to discuss and
agree on. (correct me if I am wrong).

So do I approach the powers that be and indicate it is unnecessary to have
this option or do I find a happy medium like I suggested in the previous
post? (my aim being to accommodate the W3C/ Accessibility / IA / etc
Standards and funnily enough provide a decent site for the intended
audience).

Yours Faithfully,

Ben

PS: Side Question: does everyone else see multiple entries for each of my
posts or does this only appear spasmodically on gmail? (I only send it
once). Is there a setting to change?

On 6/22/07, Philip Kiff <[EMAIL PROTECTED]> wrote:


Benedict Wyss wrote:
> My idea is to have a basic font size to allow a reasonable amount of
> content with less scrolling and then in an accessibility toolbar give
> the visitor the oportunity to increase the font size in the main
> content area. This to me seems like a decent compromise. I am open to
> correction on that, but it seems fair though.
>
> So I will still need to place a text resizing mechanism to cover that
> government standard for the site.

I'm not sure what you mean by "government standard" here.  There is some
debate about whether "text resizer" widgets are a good idea at all, and I
don't think that there is any government standard that explicitly requires
them.  There are a variety of arguments about this, but a couple quick
ones
are: is the widget usable without JavaScript? (This is required for the
site
to meet W3C WCAG 1.0 Priority 1 Guidelines). Is it usable without cookies?
How can you inform a visitor that the widget exists, and what it will do,
if
they cannot read the text on the site to begin with?

What is usually required from a standards perspective, at minimum, is that
a
site use relative font sizes in a way that allows a visitor to increase
the
font size of the site using browser controls.  Some very respectable sites
provide a link to "increase text size" that offer simply an explanation of
how to increase the text size in different browsers, rather than trying to

change the size of the fonts being sent to the browser.


> [...] I worked on
> the assumption that lower that normal font sizes are unneccessary but
> as a standard we are obliged to offer a larger text size alternative,
> and one that differs from the cnrt+/- that applies to the whole site.

I don't think you are obliged to offer "a larger text size alternative,
and
one that differs from the cnrt+/- that applies to the whole site."


> On 6/21/07, Felix Miata wrote:
> I think what you want is to reinvent the wheel and clutter your page
> duplicating browser tools. One job of a modern web browser to provide
> its user with whatever text size adjustment is required to
> make a page comfortable and/or usable.
> [] All you need to do is
> accommodate them all by leaving the base size as you found it and
> setting only contextual sizes relative to the base size presumptively
> chosen by each individual user.

I'd have to agree with Felix on this one, particularly for a site whose
target market includes large numbers of seniors.  Seniors are more likely
to
be unfamiliar with how web browsers work than the younger population, and
as
a result, they will be less likely to know how to change the font size in
their browsers, and they will also be less likely to understand the
function
of font resizing widgets on a page, no matter how you present them.  And
given that deteriorating vision is such a common issue for that
population,
the best approach for a site targeting that market would be to use a large
enough default size that most users can use it.  To do this, I would
seriously consider following Felix's recommendation of leaving the base
size
as you found it.

Phil.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsg

[WSG] Accessibility and "fly out" menus

[Mary-Anne . Nayler]

I was wondering how members here feel about the accessibility of "Fly Out" 

menus. The type I'm talking about are CSS based, ie no JavaScript but I'd 
be interested to hear what people think about those that utilise 
JavaScript. 


~~
Mary-Anne Nayler
Senior Web Designer/Developer
Web Services Section
Medicare Australia
(02) 6124 6681






NOTICE - This message is intended only for the use of the addressee named above 
and may contain privileged and confidential information. If you are not the 
intended recipient of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it. If you received this 
message in error please notify Medicare Australia immediately. Any views 
expressed in this message are those of the individual sender, except where the 
sender specifically states them to be the views of Medicare Australia.
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessibility and "fly out" menus

[Sander Aarts]

Ross Bruniges schreef:

the whole point is that there shouldn't be a javaScript-free menu that provides 
this functionality!! CSS is merely a format for styling documents and should 
not be used for functionality like that!
  
I've heard this a lot, but if changing color on hovering a link is 
styling (which I think it is) than I guess a dropdown menu can be seen 
as styling as well. I'm not saying dropdowns should be done by CSS, but 
I don't see why it should definitely not be done that way. In the end 
you'll need CSS anyway, if only for the absolute positioning. Same goes 
for JavaScript if you want your menu to drop down in IE6.
In my opinion the balance between these 2 additional layers just depends 
both on your personal preferences and (most of all) on what you expect 
from the final result.


If you make shure that, by making the main buttons clickable as well, 
the dropdown menus only provide extra shortcuts and not the only way of 
navigating through the site everyone should be able to access your site. 
Providing an option to turn off the dropdowns is of course a nice extra 
(if passed on from one page to another).



cheers,
Sander


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] future standards

[Sander Aarts]

Alan Trick schreef:

I've become a bit cynical with the W3C and their recent slowness to come
out with workable specs (XHTML 2 anyone?). There has only been a very
small advance in web technology in the last few years I've been in the
industry. The WHATWG seems to be taking up the torch well. I hope the
W3C can get in on it though.


Both W3C and WHATWG are working on the same specs now for (X)HTML5. So 
as a result they're on the same speed, although most input is probably 
coming from the WHATWG side.


cheers,
Sander


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Triggering POSTs with links?

[Sander Aarts]

Why do need a POST anyway if I may ask?

cheers,
Sander


Richard Ishida schreef:
I put together a box that expands to accommodate larger text in translation, but I forgot that text on a submit button doesn't wrap :O 


Original: 
http://www.w3.org/International/questions/qa-css-charset.en.php#endlinks (see 
the box to the right)
First problematic translation: 
http://www.w3.org/International/questions/qa-css-charset.fr.php#endlinks

I want the text "Send us a comment" to look like a link, but trigger a POST, so 
I put the text in a submit button and styled it. Unfortunately the longer translations 
won't wrap that way.




http://www.w3.org/International/questions/qa-css-charset.fr.php"; type="hidden">
 



Does anyone know a better way to do this?  I was hoping to avoid using 
JavaScript, if possible.

Cheers,
RI



Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/People/Ishida/

http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/
 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***


  



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Triggering POSTs with links?

[Sander Aarts]

Richard Ishida schreef:

It's annoying that it doesn't work so well in Opera, but I'd rather give the
problem to Opera users than IE users.

Ouch! That hurts man...


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Javascript problem

[Thierry Koblentz]

> On Behalf Of Paul Collins
 
> I have a script that adds colours to a all the columns in  a table. It
> works fine, the only problem is, it is trying to apply the code to all
> pages, when the table is only on a couple. So when I am viewing all
> other pages, it comes up with this error:
> 
> document.getElementById(tableID) has no properties
> 
> So, what I would like to do, is add a checker to the script to see if
> the table actually exists before doing the rest of the code.
> Unfortunately, I am a novice to this and I've been stuffing around for
> a while and can't get it to work.
> 
> Here is the teh script, it is worth mentioning that this is the only
> table on the site, so that may help with the re-working of the code,
> although it would be nice to have a checker that looks for the
> specific table id.
> 
> Thanks in advance:
> 
> // script to add alternating table background colours
> var
> colors=["#E5D9DB","#C5D3D8","#DBCBBE","#E9DBC7","#D4E0E0","#C5CEC7"];
>   function alternateRows(tableID,numberOfColors,colorArray){


>   var
> trs=document.getElementById(tableID).getElementsByTagName("TD");
>   len=trs.length;
>   var myColors=colorArray.slice(0,numberOfColors);
>   while(len--){
> 
>   trs[len].style.backgroundColor=colors[len%myColors.length];
>   }
>   }
> 
> // add onload event
> addLoadEvent(function() {
>   alternateRows("caseStudiesTable",6,colors);
>   }
> );

Try this:

addLoadEvent(function() {
if(document.getElementById("caseStudiesTable"))
alternateRows("caseStudiesTable",6,colors);
}

---
Regards,
Thierry | www.TJKDesign.com






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Javascript problem

[Dan Dorman]

On 6/21/07, Dan Dorman <[EMAIL PROTECTED]> wrote:

function alternateRows(tableID,numberOfColors,colorArray){
  [snipped]
  if (table) {
var trs=document.getElementById(tableID).getElementsByTagName("TD");
[snipped]
}
  }
}


Whoops!  I got a little careless.  The line starting with "var
trs...", while it will still work, is needlessly verbose, since you've
already got the results of getElementById. You can rewrite that line
as:

var trs = table.getElementsByTagName("TD")

to save a few processor cycles and a few keystrokes.

Dan Dorman


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Javascript problem

[Matthew Pennell]

On 21/06/07, Paul Collins <[EMAIL PROTECTED]> wrote:


So, what I would like to do, is add a checker to the script to see if
the table actually exists before doing the rest of the code.
Unfortunately, I am a novice to this and I've been stuffing around for
a while and can't get it to work.



Simple solution - add this line to the start of your function:

if (!document.getElementById(tableID)) return;

--




Matthew Pennell //
m: 07904 432123 //
www.thewatchmakerproject.com


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Javascript problem

[Peter Leing]

Try the following. It will check to see if the element exists before executing 
the alternateRows() function.

addLoadEvent(function() {
if(document.getElementById("caseStudiesTable")) {
alternateRows("caseStudiesTable",6,colors);
}
});

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Collins
Sent: Thursday, June 21, 2007 1:57 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] Javascript problem

Hi all,

I hope this is on topic, please ignore it if not, I have a small
Jscript problem that shouldn't be hard to sort out, but I am not great
with these things...

I have a script that adds colours to a all the columns in  a table. It
works fine, the only problem is, it is trying to apply the code to all
pages, when the table is only on a couple. So when I am viewing all
other pages, it comes up with this error:

document.getElementById(tableID) has no properties

So, what I would like to do, is add a checker to the script to see if
the table actually exists before doing the rest of the code.
Unfortunately, I am a novice to this and I've been stuffing around for
a while and can't get it to work.

Here is the teh script, it is worth mentioning that this is the only
table on the site, so that may help with the re-working of the code,
although it would be nice to have a checker that looks for the
specific table id.

Thanks in advance:

// script to add alternating table background colours
var colors=["#E5D9DB","#C5D3D8","#DBCBBE","#E9DBC7","#D4E0E0","#C5CEC7"];
function alternateRows(tableID,numberOfColors,colorArray){
var 
trs=document.getElementById(tableID).getElementsByTagName("TD");
len=trs.length;
var myColors=colorArray.slice(0,numberOfColors);
while(len--){

trs[len].style.backgroundColor=colors[len%myColors.length];
}
}

// add onload event
addLoadEvent(function() {
alternateRows("caseStudiesTable",6,colors);
}
);


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***


**
NOTICE:  The information contained in this message is intended for the 
addressess(s) only and may be confidential, proprietary, or legally
privileged.  If you have received this message in error or there are any
problems with the transmission, please immediately notify us by return
e-mail.  The unauthorized use, disclosure, copying, or alteration of this
message is strictly forbidden.  The sender will not be liable for any 
damages arising from alteration of the contents of this message by a 
third-party or as a result of any virus being transmitted.  This notice
is automatically appended to each e-mail message transmitted from the
sender's e-mail domain.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Javascript problem

[Dan Dorman]

On 6/21/07, Paul Collins <[EMAIL PROTECTED]> wrote:

I hope this is on topic, please ignore it if not, I have a small
Jscript problem that shouldn't be hard to sort out, but I am not great
with these things...


I'm assuming from the subject that you're actually referring to
Javascript. Jscript is a similar implementation by Microsoft that's
just different enough to screw things up.


So when I am viewing all other pages, it comes up with this error:

document.getElementById(tableID) has no properties


Since there isn't an element with an id attribute equal to tableID,
getElementById returns null.  However, in your script:


var 
trs=document.getElementById(tableID).getElementsByTagName("TD");


... you're using the method getElementsByTagName of the element object
returned by getElementById.  This is fine, as long as getElementById
returns something, as it does when the table is present on the page.
However, when the table isn't there, getElementById returns null ...
and null doesn't have any properties (or methods), hence the error.
You're basically saying:

var trs = null.getElementsByTagName("TD")

However, it's a simple fix:  run getElementById on its own, check that
it returned something, then run getElementsByTagName on the element
which you now know exists.  Something like so:

function alternateRows(tableID,numberOfColors,colorArray){
 var table = document.getElementById(tableID);
 if (table) {
   var trs=document.getElementById(tableID).getElementsByTagName("TD");
   len=trs.length;
   var myColors=colorArray.slice(0,numberOfColors);
   while(len--){
 trs[len].style.backgroundColor=colors[len%myColors.length];
   }
 }
}

The stuff inside the if statement won't execute unless table exists.
Hope that helps!

Dan Dorman


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] Javascript problem

[Paul Collins]

Hi all,

I hope this is on topic, please ignore it if not, I have a small
Jscript problem that shouldn't be hard to sort out, but I am not great
with these things...

I have a script that adds colours to a all the columns in  a table. It
works fine, the only problem is, it is trying to apply the code to all
pages, when the table is only on a couple. So when I am viewing all
other pages, it comes up with this error:

document.getElementById(tableID) has no properties

So, what I would like to do, is add a checker to the script to see if
the table actually exists before doing the rest of the code.
Unfortunately, I am a novice to this and I've been stuffing around for
a while and can't get it to work.

Here is the teh script, it is worth mentioning that this is the only
table on the site, so that may help with the re-working of the code,
although it would be nice to have a checker that looks for the
specific table id.

Thanks in advance:

// script to add alternating table background colours
var colors=["#E5D9DB","#C5D3D8","#DBCBBE","#E9DBC7","#D4E0E0","#C5CEC7"];
function alternateRows(tableID,numberOfColors,colorArray){
var 
trs=document.getElementById(tableID).getElementsByTagName("TD");
len=trs.length;
var myColors=colorArray.slice(0,numberOfColors);
while(len--){

trs[len].style.backgroundColor=colors[len%myColors.length];
}
}

// add onload event
addLoadEvent(function() {
alternateRows("caseStudiesTable",6,colors);
}
);


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] Out of Office AutoReply: *****SPAM***** digest for wsg@webstandardsgroup.org

[McNally, Peter R]

I will be out of the office on Thursday 06/21/07 and Friday 06/22/07.  I will 
be back in the office on Monday 06/25/07.  

I will be on vacation and not checking email or voicemail during this time.  I 
will respond to all emails when I return.  


Thanks, 

Pete


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] Safari Web Inspector

[Nick Fitzsimons]

Hi all,

Just thought people here might like to know that the WebKit team have  
just announced their new Web Inspector in nightly builds of Safari  
for Mac & Windows:



Just had a play, and it looks like it offers most of the goodies  
we've come to expect from Firebug, although Drosera (the JS debugger  
bundled with nightly builds) still seems to make WebKit suck up a lot  
of processor cycles...


Oh, and although nightly builds aren't as stable as the public beta,  
they will run side-by-side with your current installation, making  
testing for the future while browsing in the present much easier.  
(That doesn't apply to Windows, obviously, although I assume the  
nightly will co-exist with the beta - can't be bothered to open up  
Windows and test, though.)


Enjoy!

Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Accessibility and "fly out" menus

[Philip Kiff]

Mary-Anne.Nayler wrote:
> I was wondering how members here feel about the accessibility of "Fly
> Out" menus. The type I'm talking about are CSS based, ie no
> JavaScript but I'd be interested to hear what people think about
> those that utilise JavaScript.

There was a discussion about this *exact* same topic on this list just one
to two weeks ago:
http://www.mail-archive.com/wsg@webstandardsgroup.org/msg29150.html
and
http://www.mail-archive.com/wsg@webstandardsgroup.org/msg28989.html

Those earlier threads address the questions of CSS vs. JavaScript
flyout/dropdowm menus, keyboard navigation, hover delays, etc.

Additional older threads on the same topic can be found in the archives:
http://www.mail-archive.com/wsg@webstandardsgroup.org/

Phil.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] intuitive text resizer for accessibility toolbar

[Philip Kiff]

Benedict Wyss wrote:
> My idea is to have a basic font size to allow a reasonable amount of
> content with less scrolling and then in an accessibility toolbar give
> the visitor the oportunity to increase the font size in the main
> content area. This to me seems like a decent compromise. I am open to
> correction on that, but it seems fair though.
>
> So I will still need to place a text resizing mechanism to cover that
> government standard for the site.

I'm not sure what you mean by "government standard" here.  There is some
debate about whether "text resizer" widgets are a good idea at all, and I
don't think that there is any government standard that explicitly requires
them.  There are a variety of arguments about this, but a couple quick ones
are: is the widget usable without JavaScript? (This is required for the site
to meet W3C WCAG 1.0 Priority 1 Guidelines). Is it usable without cookies?
How can you inform a visitor that the widget exists, and what it will do, if
they cannot read the text on the site to begin with?

What is usually required from a standards perspective, at minimum, is that a
site use relative font sizes in a way that allows a visitor to increase the
font size of the site using browser controls.  Some very respectable sites
provide a link to "increase text size" that offer simply an explanation of
how to increase the text size in different browsers, rather than trying to
change the size of the fonts being sent to the browser.


> [...] I worked on
> the assumption that lower that normal font sizes are unneccessary but
> as a standard we are obliged to offer a larger text size alternative,
> and one that differs from the cnrt+/- that applies to the whole site.

I don't think you are obliged to offer "a larger text size alternative, and
one that differs from the cnrt+/- that applies to the whole site."


> On 6/21/07, Felix Miata wrote:
> I think what you want is to reinvent the wheel and clutter your page
> duplicating browser tools. One job of a modern web browser to provide
> its user with whatever text size adjustment is required to
> make a page comfortable and/or usable.
> [] All you need to do is
> accommodate them all by leaving the base size as you found it and
> setting only contextual sizes relative to the base size presumptively
> chosen by each individual user.

I'd have to agree with Felix on this one, particularly for a site whose
target market includes large numbers of seniors.  Seniors are more likely to
be unfamiliar with how web browsers work than the younger population, and as
a result, they will be less likely to know how to change the font size in
their browsers, and they will also be less likely to understand the function
of font resizing widgets on a page, no matter how you present them.  And
given that deteriorating vision is such a common issue for that population,
the best approach for a site targeting that market would be to use a large
enough default size that most users can use it.  To do this, I would
seriously consider following Felix's recommendation of leaving the base size
as you found it.

Phil.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Accessibility and "fly out" menus

[Thierry Koblentz]

> On Behalf Of Brian Cummiskey
> The suckerfish menus are pretty accessible, but like all items that
> require a "hover" action, those with out a mouse may suffer a little.
> 
> http://www.htmldog.com/articles/suckerfish/dropdowns/

This solution is keyboard friendly and there is a few pixels "cussion"
around the sub-menus for pointing device users:
http://www.tjkdesign.com/articles/keyboard_friendly_dropdown_menu/EK.asp
Making it a flyout rather than a drop down is just a matter of cahnging a
few rules.

---
Regards,
Thierry | www.TJKDesign.com






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] future standards

[Alan Trick]

Hi,

I just watched a presentation from Robert O'Callahan last night and I
think some of you would enjoy it. He goes over some of the new stuff
that's coming out in Firefox and how Firefox plans to develop the web
and web standards. It includes demos of their new typography support
(ligatures and kerning), built-in video, canvas, offline, APNG, and
other stuff.

One of the really cool this is that Opera already supports a lot of this
stuff too and I think Safari is working on it. So we should have > 20%
market penetration of this stuff pretty soon. A lot of it degrades
pretty well too.

The video's at
http://www.meetup.co.nz/2007/06/21/video-june-meetup-robert-ocallahan-from-mozilla-on-firefox-3/
 there's also a short writeup on it on the New Zealand Herald 
http://www.nzherald.co.nz/section/story.cfm?c_id=5&objectid=10446902

I've become a bit cynical with the W3C and their recent slowness to come
out with workable specs (XHTML 2 anyone?). There has only been a very
small advance in web technology in the last few years I've been in the
industry. The WHATWG seems to be taking up the torch well. I hope the
W3C can get in on it though.

Alan Trick


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***


signature.asc
Description: This is a digitally signed message part

Re: [WSG] Triggering POSTs with links?

[Mike at Green-Beast.com]

Richard Ishida wrote:
> It's annoying that it doesn't work so well in Opera,
> but I'd rather give the problem to Opera users than
> IE users.  This also seems a much more sensible
> approach. I guess I should contact Opera and see if
> we can't get this 'fixed'.

I'm bummed it doesn't work as well in Opera. I just realized that last night 
before I sent it (hence the after thought disclaimer). It's a usability 
issue because Opera users will think they can click something when they 
can't. Can't rely on a title attribute of course thus I think the best 
option is to make the visible text more clear -- temporary solution, anyway.

What I just did on my daughter's blog (http://sarahcherim.com/) is change 
the label text

From:

"Use PayPal to give Sarah some college money as a way of saying thanks 
and good luck!"

To:

"Click the dancing cow to give Sarah some college money with PayPal as a 
way of saying thanks and good luck! "

And that way at least the what to do clue is visible to Opera users, and 
everyone else can get away with missing the cow and clicking the text so 
it's more like an enhancement. I had to do something. Still didn't add the 
legend, but I'll do that when I have more time to fool with it so it doesn't 
change the look.

Just a thought.

Cheers.
Mike Cherim


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***<>

Re: [WSG] intuitive text resizer for accessibility toolbar

[Benedict Wyss]

Hi Felix,

you are right in everything you write..but, there are always exceptions,
in that we need to (at Veteran's Affairs) cater for visitors accross the
board. We need to consider the realestate taken up and the text size which
are oposite forces and so we need to find a happy medium.

My idea is to have a basic font size to allow a reasonable amount of content
with less scrolling and then in an accessibility toolbar give the visitor
the oportunity to increase the font size in the main content area. This to
me seems like a decent compromise. I am open to correction on that, but it
seems fair though.

So I will still need to place a text resizing mechanism to cover that
government standard for the site.

While awaiting the responses from the list I came up with a simple solution
using a few lines of JS. With the + button, the visitor can increase the (h1
to 4 and p) tags to double the size in the main content area and the -
button will return it to normal. I worked on the assumption that lower that
normal font sizes are unneccessary but as a standard we are obliged to offer
a larger text size alternative, and one that differs from the cnrt+/- that
applies to the whole site.

Cheers,

Ben



On 6/21/07, Felix Miata <[EMAIL PROTECTED]> wrote:


On 2007/06/21 00:12 (GMT-0400) Benedict Wyss apparently typed:

> I just searched on google and found a couple that left me feeling rather
> mentally limp, so your my next port of call.

> please pass back links to a text resizer that has the following ability:

I think what you want is to reinvent the wheel and clutter your page
duplicating browser tools. One job of a modern web browser to provide its
user with whatever text size adjustment is required to
make a page comfortable and/or usable. They all provide by default a size
determined by scientific tests to be a size that works well for the broadest
range of users, along with at least one tool to
tailor it to personal whim. Presumably each user has either already done
so or found doing so unnecessary. All you need to do is accommodate them all
by leaving the base size as you found it and
setting only contextual sizes relative to the base size presumptively
chosen by each individual user. http://www.w3.org/QA/Tips/font-size
http://www.lighthouse.org/accessibility/
http://www.informationarchitects.jp/100e2r?v=4
--
"Respect everyone." I Peter 2:17 NIV

Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Triggering POSTs with links?

[Richard Ishida]

Ah, that makes a lot more sense, Mike.  Thanks. 

It's annoying that it doesn't work so well in Opera, but I'd rather give the
problem to Opera users than IE users.  This also seems a much more sensible
approach. I guess I should contact Opera and see if we can't get this
'fixed'.

So now my code looks like this:

.container label.interaction {
  font-size: 130%;
  color: #e70;
  background-color: #ff; 
  border: 0; 
  margin: 0; 
  padding: 0;
  cursor: pointer;
  }



 Envoyez-nous un commentaire


 


I'm wondering whether to add a title attribute telling Opera users to click
the icon, or whether they'll figure it out.

Thanks all for the help.

RI


Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/
 
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike at 
> Green-Beast.com
> Sent: 21 June 2007 05:18
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Triggering POSTs with links?
> 
> Thierry Koblentz wrote:
> > I came up with this:
> > http://www.tjkdesign.com/lab/button.asp
> > But it requires to move the text out of the button :(
> 
> I'm sort of just catching the end of this, but are you guys 
> talking about something like what I did on my daughter's blog [1]?
> 
> [1] http://sarahcherim.com/ (look at the "Contribution Cow" 
> on the sidebar)
> 
> I didn't use button (not sure if that's was the point or just 
> making clickable image/text form posting).
> 
> Cheers.
> Mike Cherim
> 
> PS. Just a little disclaimer, looking at the image/text form 
> on that site I realized I should have used a legend instead 
> of the heading. It's not clickable in Opera either, by the 
> way -- just the image.
>  
> 
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessibility and "fly out" menus

[Ross Bruniges]

> I'm yet to see a JavaScript-free menu that:
> * Can be used without a pointing device (e.g. by keyboard or breath  switch 
> users)
 >* Doesn't vanish the moment that the mouse drifts outside the menu  
> (thus requiring fine motor control that users with, for instance,  
> arthritis are unlikely to have)

the whole point is that there shouldn't be a javaScript-free menu that provides 
this functionality!! CSS is merely a format for styling documents and should 
not be used for functionality like that!

the behavior mentioned above is something that is included in HTML, and, if you 
want things to look better the required functionality SHOULD be included with 
JavaScript.

So in summary - get those JavaScript books out ;>






  ___ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today 
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessibility and "fly out" menus

[David Dorward]

On 21 Jun 2007, at 07:35, [EMAIL PROTECTED]  
wrote:
I was wondering how members here feel about the accessibility of  
"Fly Out" menus. The type I'm talking about are CSS based, ie no  
JavaScript but I'd be interested to hear what people think about  
those that utilise JavaScript.


I'm yet to see a JavaScript-free menu that:

* Can be used without a pointing device (e.g. by keyboard or breath  
switch users)
* Doesn't vanish the moment that the mouse drifts outside the menu  
(thus requiring fine motor control that users with, for instance,  
arthritis are unlikely to have)


--
David Dorward
http://dorward.me.uk/
http://blog.dorward.me.uk/




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Triggering POSTs with links?

[Chris Taylor]

Cheers, I thought that when I went back to it as well. I'll get that done
very soon.

Chris


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Thierry Koblentz
Sent: 20 June 2007 17:49
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] Triggering POSTs with links?

> On Behalf Of Chris Taylor
> Have you tried the  element? As far as I know that can be
> styled
> pretty much how you want. I used it on this page:
> http://www.searchandgo.com/weather/United-States/New-York-City/ - the
> "New
> York City exchange rates" text on the left is a button.

Clever...
I'd add a "cursor:pointer" declaration to give pointing device users a clue
that this text is "clickable".

---
Regards,
Thierry | www.TJKDesign.com





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Accessibility and "fly out" menus [SEC=UNCLASSIFIED]

[Watson, Denis]

 
As a user I have some difficulty with "fly out" and "pop up" menus.
Firstly I find them difficult visually. Although my eye sight is
reasonably good I do not like sudden movement on the screen. Secondly, I
find that such menu items can be difficult to keep the mouse on although
I do not have any movement disability.
 
In general I have an aversion to sites using these techniques and I tend
to avoid them if I can. I consider that there are definitely
accessability issues with them, especially for people who have motor
neurone problems.  
 
Denis Watson,
Web Editor,
Productivity Commission.
Email: [EMAIL PROTECTED]
Phone: 61 3 9653 2264 
Mobile: 0418 330 240 
Fax: 61 3 9653 2199
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
Sent: 21 June 2007 4:36 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] Accessibility and "fly out" menus



I was wondering how members here feel about the accessibility of "Fly
Out" menus. The type I'm talking about are CSS based, ie no JavaScript
but I'd be interested to hear what people think about those that utilise
JavaScript. 


~~
Mary-Anne Nayler
Senior Web Designer/Developer
Web Services Section
Medicare Australia
(02) 6124 6681







NOTICE - This message is intended only for the use of the addressee
named above and may contain privileged and confidential information. If
you are not the intended recipient of this message you are hereby
notified that you must not disseminate, copy or take any action based
upon it. If you received this message in error please notify Medicare
Australia immediately. Any views expressed in this message are those of
the individual sender, except where the sender specifically states them
to be the views of Medicare Australia.

***

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*** 


# Important Notice ## 
This e-mail and attachments (if any) is intended for the original 
addressee only.  If you are not the intended recipient , any use 
or dissemination of this communication is prohibited.  
Please advise the sender by return e-mail and delete the e-mail 

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessibility and "fly out" menus

[Brian Cummiskey]

[EMAIL PROTECTED] wrote:


I was wondering how members here feel about the accessibility of "Fly 
Out" menus. The type I'm talking about are CSS based, ie no JavaScript 
but I'd be interested to hear what people think about those that 
utilise JavaScript.


The suckerfish menus are pretty accessible, but like all items that 
require a "hover" action, those with out a mouse may suffer a little.


http://www.htmldog.com/articles/suckerfish/dropdowns/



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] Accessibility and "fly out" menus

[Mary-Anne . Nayler]

I was wondering how members here feel about the accessibility of "Fly Out" 
menus. The type I'm talking about are CSS based, ie no JavaScript but I'd 
be interested to hear what people think about those that utilise 
JavaScript. 


~~
Mary-Anne Nayler
Senior Web Designer/Developer
Web Services Section
Medicare Australia
(02) 6124 6681






NOTICE - This message is intended only for the use of the addressee named above 
and may contain privileged and confidential information. If you are not the 
intended recipient of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it. If you received this 
message in error please notify Medicare Australia immediately. Any views 
expressed in this message are those of the individual sender, except where the 
sender specifically states them to be the views of Medicare Australia.
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***