Re: [WSG] SilverLight

2007-10-30 Thread Derek Featherstone
On 10/30/07, Christian Montoya wrote:

On 10/30/07, Derek Featherstone [EMAIL PROTECTED] wrote:
 Christian - do you have a reference for that anywhere? I'd be really
 interested in seeing it (as I'm sure others would be too!)

Just read the spec on XAML, which is what Silverlight uses:
http://msdn2.microsoft.com/en-us/library/ms752059.aspx

Hi Christian - I actually meant a reference on this part of your
statement:

[because Silverlight uses XML] Microsoft claims that Silverlight is
much easier for screen readers, search spiders, etc. to work with.

Can you show us where they claim it is much easier for screen readers,
search spiders to work with? THAT is what I want to see...

Thanks, and sorry for my lack of clarity...
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: +1 613-599-9784  1-866-932-4878 (toll-free in North America)
Work:  http://www.furtherahead.com
Blog:  http://www.boxofchocolates.ca
Learn: http://north.webdirections.org


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



Re: [WSG] SilverLight

2007-10-29 Thread Derek Featherstone
On 10/29/07, Christian Montoya wrote:

... Silverlight is rendered XML while Flash is a compiled format.
Therefore, Microsoft claims that Silverlight is much easier for screen
readers, search spiders, etc. to work with.

Christian - do you have a reference for that anywhere? I'd be really
interested in seeing it (as I'm sure others would be too!)

Thanks, in advance...
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: +1 613-599-9784  1-866-932-4878 (toll-free in North America)
Work:  http://www.furtherahead.com
Blog:  http://www.boxofchocolates.ca
Learn: http://north.webdirections.org


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



Re: [WSG] CSS Driven?

2005-12-16 Thread Derek Featherstone
On 12/16/05, Thomas Livingston wrote:

If I have to use a table now, it it _not_ going to be a horrible retro
nested mess. It's to achieve something I can't achieve otherwise.

Hi Tom - I don't mean this as a sarcastic question or anything. I fully
admit I may have missed this if it was already discussed, but I'm
curious to know if you have examples of this - things you couldn't have
achieved in other ways?

It sounds odd, but if you have examples, I'd be very curious to see
them... 

Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



Re: [WSG] positive-discrimination === not positive and IMG properties

2005-12-15 Thread Derek Featherstone
On 12/15/05, Ben Curtis wrote:

The alt text is removed from the element if the image is loaded. It's  
a very simple htc that runs this code for each image after the page  
loads:

   if (element.complete) element.alt = '';

You attach it to the img selector in your css, or a more specific  
selector if you don't want all images to be affected.

I can't see why you'd want it to have an effect on any images, to be
honest.

I would assume that the blind have their browsers set to not load
images. I may be dreadfully wrong in that assumption, but if the
images don't load then this code has no effect and the alt text
remains.

Dreadfully wrong. Well, you said it, not me :-)

The blind have just as many varied setups and configurations as the
unblind. If you take away alt text, you take away *critical*
information.

Even if you target specific images via CSS selectors, I'd question
whether nor not it should be removed at all. After all - how do you
decide which ones to take away and which ones not to take away?

OK - let me rephrase that to be more clear:

Don't remove the alt text - it is there for a reason and taking it away
is the opposite of web standards.

Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



Re: [WSG] Accessibility: Default placeholders

2005-11-13 Thread Derek Featherstone
On 11/14/05, Geoff Deering wrote:

Why can't the braille software detect an empty form element and inform
the user it requires data?  Is this an authoring tool problem or a
problem with the way standards are prescribed?

Agreed, Geoff. We really do need to know more. We'll need to add this to
the hitlist for the WaSP Accessibility Task Force. It is something that
is of concern to all - I'll see about running some tests with a local
braille display user and see what I can determine from his tests... 



Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



Re: [WSG] Accessibility: Default placeholders

2005-11-13 Thread Derek Featherstone
On 11/14/05, Geoff Deering wrote:

Mandatory data fields, Required data, fields that require correct data 
after validation should all be grouped together with a 
*fieldsetlegend*.  This informs all users of the requirements of that 
data.

Indeed - one of my favourite techniques: 

http://simplyaccessible.org/examples/required-form-fields

This standard of putting an asterisks * after (or before an input
field) does not only not inform an unsighted user, it often gives the
indication after they have tabbed through the field, to late for them
to manage their input without back tracking.

Agreed.  Putting them after *visually* and leaving them before in source
order, and as part of the label can be really useful - its semantically
meaningful, can be emphasized (using label em /em/label) as
shown in the second example on that page is useful. You could easily use
the same technique to emphasize the text required instead of an
asterisk.


Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



Re: [WSG] simplyaccessible.org

2005-10-11 Thread Derek Featherstone
On 10/12/05, Nick Lo wrote:

I did want to comment that the form error in the label suggestions 
Derek gave have really got me thinking about how my CMS returns users 
to forms and alerts them.

Hi Nick,

That's good - that was my intent! Actually, that was my intent with most
of what is already there, and will be there soon (read: there are more
examples on the way - and, incidentally I've added a feed to the site so
that people can be notified when I post a new example. I can't guarantee
I'll be posting a lot more there beyond what I presented at WE05, but I
will be posting the rest of those examples over the next while)

I presume that what would be best would be a combination of a message
like

Please check the errors indicated in the form below

at the top of the form and have the this must not be blank on
the relevant field(s)?

I think that would be very reasonable, yes.

For what it's worth, I've had a tough time abstracting the examples,
both in preparation for presenting them at WE05, and for posting them on
the web. Not presenting them in context makes certain parts difficult -
cf. my use of the zoom layout to change *only* the form layout itself,
and nothing about the colours/contrast/size of the rest of the page. At
a certain point, though, I needed to leave the rest to your
imagination.

Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



Re: [WSG] simplyaccessible.org

2005-10-10 Thread Derek Featherstone
On 10/11/05, Terrence Wood wrote:

Derek, can you update your examoples to use fieldsets instead of divs
to group the form controls together?

I do use fieldsets to group form controls together but in most cases,
there is one fieldset around all the items in one form - the divs are
there to provide additional style hooks to create CSS based form layouts
and to allow me to create rows without using tables. Or am I
misinterpreting what you are saying here?

Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] simplyaccessible.org

2005-10-10 Thread Derek Featherstone
On 10/11/05, Terrence Wood wrote:

Agreed, you are absolutely correct. Doh! I didn't acutally check the
source code, no wonder my earlier post was confusing. Sorry Derek.

No worries... 

If anyone *is* interested in replicating Dereks layout without the
extra div's try this:

snip /

for what it's worth - I did try using that at certain points, but
generally preferred to add in explicit divs to provide another hook for
styling. YMMV - I also preferred to place each row in a block level
element so that without author styles each form field and its label is
still on a row of its own, though that use case may not be as important.

Now then, I'd better get back to it so that I can post the second round
of examples... :)

Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



Re: [WSG] Meta Keywords?

2005-10-06 Thread Derek Featherstone
On 10/7/05, John Allsopp wrote:

Get them to ask Hitwise to justify the recommendation, based on  
anything other than handwaving and superstition.

I'd be interested in their response :-)

I think it is safe to say that we would *all* be interested in their
response, if they prepare one at all...

Cheers,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] implicit / explicit labels which is better?

2005-08-02 Thread Derek Featherstone
On 8/2/05, Patrick Lauke wrote:

Mozilla, Firefox, Opera, K-Meleon all cope just as well with an
implicit label, making it clickable. Not sure about Safari...anybody
care to do a super-quick check?

From what I remember, Safari doesn't support clickable labels at all.
Not so cool. Mental note - look at the User Agent Accessibility
Guideilnes to see if this is *required* or optional. Mental note 2 -
send something off to Dave Hyatt to find out if this can be/will be
fixed.

Oh, and if anyone wants to take care of those two mental notes above for
me, that would be great as well... :)

Best regards,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: Re: [WSG] AJAX and accesibility

2005-06-29 Thread Derek Featherstone
On 6/29/05, Drake, Ted C.  wrote:

re:
http://www.boxofchocolates.ca/archives/2005/06/12/javascript-and-
accessibility
 
After reading this post, I began thinking that the solution may be to
seperate javascripts into basic and advanced sets. Just as we import
advanced style sheets to avoid confusing early browsers, perhaps we
can set an option to turn off advanced scripting. 

snip /

Are there any JavaScript people on this list that could comment?

As both a JavaScript and an accessibility person, I'll step in for a
moment.  We (the WaSP Accessibility Task Force) will be looking at all
possibilities in depth to determine what kind of scripting and
techniques are to be considered safe to be used with screen readers
and other assistive technology (we need best practices for dealing with
screen magnifiers as well, and need a better understanding of the
implications of AJAX type techniques for that group of people)

In principle, I don't see anything wrong with a layered approach to
JavaScript, much in the same way we layer style sheets. Once we better
understand the finer points of the interaction between JavaScript and
screen readers (for example), we could in theory determine which things
will be safe, and then allow a preferences page to turn off specific
portions of the JavaScript.

I like your idea of allowing the user to turn off and on portions of the
JavaScript via preferences - I don't usually advocate this approach on
its own, but in this case, though, it is likely that if they disable JS
completely, other sites will stop working as expected. Yes, I know - too
bad for the other sites because it is their own fault in the first
place. Erring on the side of caution though, a scripting preferences
might be useful and less likely to cause other problems.

There are a couple of tricky points that we'd need to sort out -
directing people to preferences to make the change, ensuring that it is
well explained without being too techie, and to avoid having too many
options - in my opinion, it needs to be limited to all scripting,
core only, and no scripting options - otherwise it gets too difficult
to understand.

Hope this helps - there are parts I'm being deliberately vague about as
the Task Force is only just getting started and we have a lot of work to
do... Please be reassured that we are looking at this very seriously
with a very talented group of people, and hopefully we'll be making some
good progress soon.

Best regards,
Derek.
-- 
Derek Featherstone   [EMAIL PROTECTED]
tel: 613-599-9784  1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal:http://www.boxofchocolates.ca
**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] CSS List Separator

2005-06-14 Thread Derek Featherstone
On Tuesday, June 14, 2005 9:56 PM, Terrence Wood wrote:
 I completely agree, and have been involved in translating legislation
 into a web format. It's a shame that the start attribute has been
 deprecated in XHTML (last I looked).

Well, there is always HTML 4.01 for these cases (legislation, such as John
has suggested). In such cases, we can still use perfectly well-formed, valid
markup. And, in this case, I would argue more semantically correct markup,
and likely a better choice of DOCTYPE.

As has already been said, simply choosing the right DOCTYPE for the job may
not be enough, though, given that we still don't really know to what degree
punctuation matters.

Cheers,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Development: http://www.furtherahead.com
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] Best way to train someone in css and web standards

2005-05-23 Thread Derek Featherstone
On Monday, May 23, 2005 7:35 AM, Cole Kuryakin - x7m wrote:

 By proficiency, I mean that I can give them a Photoshop design comp,
 and they will be able to create an XHTML code foundation as well as a
 CSS style and positioning spec without too much whining and
 head-scratching.   
 
 My plan is to get them completely compeletely trained in these areas
 before letting them dive into any real project development. 

Hi Cole,

Just a few quick points re: getting these people up to speed.

Books and blogs are the order of the day. You might have a suggested reading
list for them, including as Kay suggested, Zeldman's Designing With Web
Standards. I would also suggest Dan Cederholm's Web Standards Solutions.
While that book may seem to be too advanced at the beginning, it digs deep
into code and samples. Like Dan's SimpleQuiz series from his blog, there
is a lot more to semantics and code then meets the eye, and that can be
enlightening for developers to see. Add into the mix a healthy dose of blogs
so that they can keep up with and find the latest and greatest, even if it
is only 4 or 5 blogs.

Web Design World 2004 was held in Boston in December 2004. Molly Holzchlag
and Ethan Marcotte did a presentation that is archived online. In that
presentation, Ethan deconstructs the conversion of one of Harvard
University's web sites from tables to CSS layout. While it doesn't
demonstrate every aspect of the code, nor converting a PhotoShop comp into a
CSS based layout, I find that it does a great job of demonstrating the
ethos and principles behind modern web development. 

The presentation is linked from here:
http://www.ftponline.com/reports/wdwboston/2004/holzschlag/
When you click on the link for the presentation, instead of http: it lists
mms:  I'm not exactly sure what that protocol is, but clicking the link
brings up a message about launching an external app. I just changed it to
http: instead of mms: and it worked fine.

Finally, re: my plan is to get them completely trained in these areas
before letting them dive into any real project development

In my opinion, this isn't really a good idea. Here are some things to
consider (this is mostly my opinion, based on my experience both as a
developer and instructor):
1. if they only know basic HTML, getting them up to speed will take a while.
If they are doing nothing but training, they'll quite possibly get bored,
and web standards will be to blame.
2. learning these new techniques are best done with real projects. Contrived
examples are usually ok, but work on a real project is much more effective
for learning as they are doing something real and will have different
motivation for getting the job done.
3. From a learning perspective, you have to start small. Get them working on
a small component of a real site. Something like a nav bar, or a footer
using only semntically sound HTML and CSS would be useful. Get them to do it
on its own, and then you show them how that fits into the big picture of
the rest of the site (which you will presumably be doing).
4. For those small pieces, point them in the right direction - get them
started by showing them some examples, and see if they can make something
work using the examples as a model. You can then work with them to
deconstruct their attempts and really help them understand what is going on.
5. You have to keep challenging them - they need to move from creating a nav
bar with HTML and CSS to being responsible for the entire header, to header
plus footer plus secondary nav perhaps, and then responsible for all an
entire site.


OK, I could write forever about this, but that is more than enough to digest
for now...

Hope this is helpful to you...

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Development: http://www.furtherahead.com
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] markup readability (was: newspaper format)

2005-04-17 Thread Derek Featherstone
On Sunday, April 17, 2005 7:29 PM, Richard Czeiger wrote:
 Maybe we can formalise this list so that it becomes a
 'see-if-any-of-these-are-relevant-first' list of values that
 people can use. If what they need is not on the list then they can
 make up their own... 

You may be interested in checking out What's in a name?, by Andy Clarke
from May 2004:

http://www.stuffandnonsense.co.uk/archives/whats_in_a_name.html

Andy looks at the same question, with some interesting results via
surveying a number of popular sites looking for emergent conventions so
to speak.

A good read, and definitely worth considering.

Cheers,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Development: http://www.furtherahead.com
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca


**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: Focus highlighting, was Re: [WSG] Some links for light reading (30/11/04)

2004-11-30 Thread Derek Featherstone
On Tuesday, November 30, 2004 9:09 AM, Kornel Lesinski wrote:
Does that really matter?

Yes, focus highlighting does matter. I come across this daily -- and I'm a
keyboard user by choice... 

In Firefox and IE there is a focus border anyway.

Which isn't exactly prominent - it provides a faint outline around the
element. Changing the background and text colours in the CSS is much more
prominent and is easier to spot. Besides, we add :hover effects to things
for mouse users - why wouldn't we also provide similar benefit to keyboard
users?

IE doesn't support :focus or outlines, so there isn't much you can
 help.

Right, however, IE (mistakenly, I suspect) treats :active the same as
:focus. Adding a separate rule for IE and :active will provide the benefits
for IE keyboard users...

For example:

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: Focus highlighting, was Re: [WSG] Some links for light reading (30/11/04)

2004-11-30 Thread Derek Featherstone
Sorry about that -- it appears that pressing enter while holding down the
control key sends the message ( a new keystroke I didn't know about...)
Here's the complete message I was trying to send:


On Tuesday, November 30, 2004 9:09 AM, Kornel Lesinski wrote:
Does that really matter?

Yes, focus highlighting does matter. I come across this daily -- and I'm a
keyboard user by choice, not someone who has no choice but to use the
keyboard...

In Firefox and IE there is a focus border anyway.

Which isn't exactly prominent - it provides a faint outline around the
element. Changing the background and text colours in the CSS is much more
prominent and is easier to spot. Besides, we add :hover effects to things
for mouse users - why wouldn't we also provide similar benefit to keyboard
users?

IE doesn't support :focus or outlines, so there isn't much you can
 help.

Right, however, IE (mistakenly, I suspect) treats :active the same as
:focus. Adding a separate rule for IE and :active will provide the benefits
for IE keyboard users...

For example:

a:focus {color: #346095; background-color:#fff;}
a:hover {color: #346095; background-color:#fff;}
a:active {color: #346095; background-color:#fff;}

So, please, please, if you want to make your sites more accessible to
keyboard users, add :focus and :active rules to match your :hover rule.


Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: Focus highlighting, was Re: [WSG] Some links for light reading (30/11/04)

2004-11-30 Thread Derek Featherstone
On Tuesday, November 30, 2004 10:19 AM, Patrick Lauke wrote:

 And you can group the above and save yourself repetition. In one
 of my stylesheets, for instance, I have
 
 #navbar li a:focus,
 #navbar li a:hover,
 #navbar a:active {
 background: #fbfbfb;
 }

I seem to recall Tommy talking about a problem when all three are specified
in the same rule, but I can't recall right now. Though perhaps it was only
mentioned and never resolved. Might be able to find it in the forum archives
somewhere... http://www.accessifyforum.com

I'll let you/everyone know if I find anything

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca





**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] IE's New JavaScript Blocking Feature

2004-11-26 Thread Derek Featherstone
On Friday, November 26, 2004 2:53 PM, Mark Harwood wrote:
 The best and only way i do pop-ups is
 
 href=http://google.com/; onclick=window.open(this.href,
 'popupwindow', 'width=400,height=300,scrollbars,resizable');return
 false; 
 
 this allows you to do whatever you like with the link and also makes
 it valid, right click-able and so forth..
 
 Remeber to put onKeypress too

Please, don't add onkeypress to this in the name of device independence...
Onclick works just fine for keyboard users and for users that use
alternative devices that emulate keyboard usage. If you add onkeypress you
will quite possibly do more harm than good -- someone that uses a keyboard
for navigation etc won't be able to go anywhere because the pop up will keep
appearing.

If I'm on that particular link myself, even pressing the tab key to move to
the next link will cause the dialog to appear. Trying to open a new tab with
Ctrl + T, or open my feedreader (Sage) with Ctrl + S will cause the popup to
appear. It can actually become quite frustrating when onkeypress is used
like this...

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] IE's New JavaScript Blocking Feature

2004-11-26 Thread Derek Featherstone
On Friday, November 26, 2004 3:57 PM, Mark Harwood wrote:
 OnActivation would proberly be better to use, only reason i state to
 use onKeyPress is that validators moan if u dont use it.

That's the problem -- there is no onactivate, but that is what they
probably should have called onclick though.

As for using onkeypress, if the validators (by which I assume you mean
Bobby, et al) then, they need to get a clue. The automated tool is only
there to help, not to be the final arbiter of what is and isn't accessible.

My vote: let the automated checkers moan about this all day. Ignore them.
Don't add onkeypress in the name of accessibility and device independence...

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Development: http://www.furtherahead.com
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca


**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] IE's New JavaScript Blocking Feature

2004-11-26 Thread Derek Featherstone
On Friday, November 26, 2004 5:28 PM, Mark Harwood wrote:
 On Fri, 26 Nov 2004 16:05 , Derek Featherstone [EMAIL PROTECTED] sent:
 
 My vote: let the automated checkers moan about this all day. Ignore
 them. Don't add onkeypress in the name of accessibility and device
 independence... 
 
 Try telling that to SOCTiM who check all local council sites,
 they take the guidlines as if there written in stone!

I'm very serious about this -- I will gladly take up that battle, any day.
Send them my way, phone, email, whatever...

Building web sites (and specifically standards and acessibility) is not
about memorizing rules, but about intelligent design decisions. The sooner a
wider audience understands that (i.e., people outside our narrow slice of
existence here on WSG and other groups), the better.

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Development: http://www.furtherahead.com
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] Fieldsets can be used outside the box - Correct use of fieldset

2004-11-23 Thread Derek Featherstone
On Tuesday, November 23, 2004 11:22 AM, Ted Drake wrote:

 I think a fieldset could be used outside a form if you are
 using it to group similar links. We can fixate on the name or
 look at the purpose.  It says, the fields inside it are
 related. If the standards say it can be outside a form than
 we can use it to group similar objects.

Let's just clarify this -- the DTD says that a fieldset can be outside a
form, but only really because it is defined as a block level element. I
don't think that supercedes the intent of the element though. As you said,
look at its purpose:

The FIELDSET element allows authors to group thematically related controls
and labels.
http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET

And controls are form fields of some sort: buttons, checkboxes, radio
buttons, text boxes, textareas, file selects, etc... 
http://www.w3.org/TR/html4/interact/forms.html#h-17.2

I'd say that using fieldset and legend to present groups of links in this
way is twisting its meaning completely.

If you want the closest semantic relationship possible for presenting a list
of related links, you might consider a definition list. The title of the
group of links is the dt/dt and each of the links could be the
dd/dd. You might even use a properly-coded, semantically-structured
table to do the job.

My preference would be to use appropriate headings with a ul/ul, or even
a nested list structure, but I can't see using fieldset for it...

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] Creating Nice Pop-Ups

2004-11-10 Thread Derek Featherstone
On Wednesday, November 10, 2004 6:47 AM, Patrick Lauke wrote:

 Incidentally, I've discussed this before, but...onclick is
 implemented in practically all current browsers as a
 non-device-specific event, as it is triggered by keyboard
 access as well (on elements that can receive focus via
 keyboard tabbing, anyway, i.e. links and form elements).

Patrick is, as usual, bang on with this. Further - unless it is done very
carefully, onkeypress redundancy makes keyboard navigation next to
impossible in various browsers. In many cases it causes unintended
consequences - like not allowing one to tab to the next link, causing popups
to occur, or changing stylesheets without the user really wanting to change
stylesheets.

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] Flyout menu questions

2004-11-08 Thread Derek Featherstone
Pringle, Ron wrote:

Ideas, criticisms, suggestions and opinions welcomed.

http://www.aurora-il.org/testsite/index.htm

Hi Ron,

I know this isn't exactly what you were looking for, but I went to do a
quick navigation test via keyboard and found that I couldn't. You should
remove the onkeypress redundancy for your style sheet switcher. As it
stands, I can't tab past the stylesheet switcher because of the onkeypress
handler.

In many browsers onkeypress can break keyboard navigation - certainly an
unintended consequence - where trying to help accessibility actually hinders
it. Onclick is a misnomer, at least the way it has been implemented in
browsers. It actually behaves more like onactivate, so onclick will be just
fine for keyboard users as well.

Hope this helps...
Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

**
The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list  getting help
**



RE: [WSG] Question on tabindex

2004-07-20 Thread Derek Featherstone
  Now, what is the best order of the tabindex? Starting with the main
  nav and ending with the footer links seems obvious, but should the
  order in between be: content, right column or right column and 
 content? 

Hi Luc -- I'd suggest you might want to just forego the tabindex completely.
You've already got quite a reasonable logical flow within that test page
anyway -- one that pretty much anyone could use, based on the order of your
source code.

Tabindex can actually cause some problems, so we generally just recommend
leaving it out. See http://www.wats.ca/articles/keyboardusageandtabindex/62
for a few more details and some test results...

Cheers,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca

*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
*



RE: [WSG] Internal CSS in XHTML served as application/xhtml+xml

2004-07-09 Thread Derek Featherstone
Patrick wrote: 
 have a read through
 http://devedge.netscape.com/viewsource/2003/xhtml-style-script/
 
 ...but to answer the question quickly: it should work if you use
 
 //![CDATA[
 //]]

Right, but that only deals with JS embedded in its own script/script
block. I've used that before if I wasn't able to remove the JS and put it in
an external file.

This breaks down though, for references like this in the page for
bookmarklets (pardon the length):

a href=javascript:var l=document.links.length;var s='';for
(i=0;il;i++){var lk=document.links[i];s+='tr valign=top';s+='td' +
lk.innerHTML + ' /td';s+='td' + lk.title + ' /td';s+='tda
href='+lk.href+'' + lk.href + '/a/td';s+='/tr';}s='Links for:
'+document.location.href+'table border=1 style='font:x-small verdana'tr
valign=topthText/ththTitle/ththURL/th/tr'+s+'/table';var
lw=window.open('', 'lw',
'');lw.document.open();lw.document.write(s);lw.document.close();
   Links and Titles
/a

Adding proper escape sequences to inline JS in this case just won't work, or
perhaps I'm missing something?

Best regards,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca

*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
*



RE: [WSG] Internal CSS in XHTML served as application/xhtml+xml

2004-07-09 Thread Derek Featherstone
 This breaks down though, for references like this in the page for
 bookmarklets (pardon the length):
 
 but wouldn't you say that bookmarklets are a bit of a
 perversion of the standard, in which case it becomes academic
 to discuss how these can be served in a standards-compliant way?

Oh, I agree completely -- I was just hoping that someone somewhere might
have come across a method that would let me serve it up properly... What
I'll likely end up doing is serve that page as text/html - it's the only
solution that I can see, if I want to serve the rest of the site as
application/xhtml+xml

I won't lose too much sleep over it... ;)

Cheers,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Accessibility:  http://www.wats.ca
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca

*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
* 



RE: [WSG] PDA Viewer

2004-07-02 Thread Derek Featherstone
Neerav wrote:
 The Opera browser for windows  mac (used in some handhelds as well
 AFAIK) has a small screen emulator at view - small screen

Or you can toggle in and out of small screen mode using Shift + F11 if you
have a predisposition to using the keyboard...

Cheers,
Derek.
-- 
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784;   toll-free: 1.866.932.4878 (North America)
Web Development: http://www.furtherahead.com
Web Accessibility:  http://www.wats.ca
Personal: http://www.boxofchocolates.ca

*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
*