RE: [WSG] Keeping state of behaviors

2007-06-08 Thread Thierry Koblentz
 On Behalf Of Breton Slivka

 On 6/8/07, Thierry Koblentz [EMAIL PROTECTED] wrote:
 I put this together, but I'm not sure it could be useful for anything...
 May be it could be used with Ajax stuff, when the back button is a
concern.

 http://www.tjkdesign.com/articles/keeping_state/keeping_track.html

 This is quite useful to me. Though I don't quite understand how it works.
 Is the iframe important to the functioning? Is there a way to do the same
thing, but make the state bookmarkable? 

I wanted to get some feedback before writing something about this solution
as I'm not sure what would be the best way to use it.
It is in fact the iframe that does all the work, I'm using its URI to
hold/keep track of the values.
I started with a regular frameset hoping that it would be possible to
bookmark the state in IE (as this browser can bookmark frameset state),
but when I saw that it didn't work I dropped the frameset for an iFrame.

---
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] WCAG Samurai Errata

2007-06-08 Thread Ben Buchanan

What is your opinion on the errata ?


It's an excellent read. Certainly therapeutic, particularly with Joe
Clarke's wonderfully acerbic wit showing in places.

I think what it truly does is define the Best Practice accessibility
which has evolved under WCAG 1.0, which made some assumptions which
were proven incorrect over time.

Realistically most developers stopped shooting for perfect compliance,
since some of the rules conflict with feedback from real live users.
Tabindex is a perfect example - if the logical flow is so busted that
you have to override it, the page should be recreated in a clearer
form. Entering default text into form inputs is another rule which the
experts tell me no longer applies.

Samurai corrects a lot of those problems and does so in language which
is usually pretty clear. The only downside is that there are still
plenty of points which could be misinterpreted or quoted out of
context to support spurious practices.

It's readable though - calls a spade a spade.

cheers,
Ben

--
--- http://www.200ok.com.au/
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson


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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Lea de Groot
On Fri, 8 Jun 2007 15:22:36 +1000, Kane Tapping wrote:
 I have been reading with interest the WCAG Samurai Errata ( 
 http://wcagsamurai.org/errata/intro.html ) and am suprised to have not 
 found it discussed on WSG as of yet.

Thank you! I missed this announcement, somehow. What a refreshing read! 
:)

Points

- no noscript?
I still use it to add a submit button to dropdowns which are otherwise 
javascript driven - I thought I was doing a good thing! (Wah! :( )
Hmm.. its in the introduction, but not in the document. Thats not 
right, surely?

- Guideline 10
Do not add non-link, printable characters (surrounded by spaces or 
not) between adjacent links unless the semantics of the document 
naturally would include such characters.
Am I right in interpeting this as that we *don't* need to make sure 
there are extra characters between links! Wow! Cool! :)

:reads more:

warmly,
Lea
-- 
Lea de Groot
Elysian Systems
Brisbane, Australia


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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

On 08/06/07, Frank Palinkas [EMAIL PROTECTED] wrote:


 /* Guideline 9.4: Do not attempt to create your own tab order. That is a
job for a browser and adaptive technology. */

When and where needed (in web forms for instance), I create a tabindex
order starting with the number 11 and proceed from there. This usually
bypasses the generic built-in browser tab order.



So what would happen on a page with 15 links above the form? Presumably a
keyboard user would tab through the first 10, then just down to the form,
through that, and then back to the last 5, then move onto any links after
the form. Not exactly expected behaviour.

/* Guideline 9.5: Don't provide your own keyboard shortcuts. That is a job

for a browser or adaptive technology. */

I provide keyboard shortcuts for global navigation situated on each web
page. I cross-browser test to make sure each character I'm using for the Alt
+ key shortcut doesn't interfere with generic browser shortcuts.


I think it's been shown that just about all keys interfere with someone's
shortcuts, whether it's a browser, screenreader, foreign characters, or
whatever.

Matthew.


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

Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

On 08/06/07, Lea de Groot [EMAIL PROTECTED] wrote:


- no noscript?
I still use it to add a submit button to dropdowns which are otherwise
javascript driven - I thought I was doing a good thing!



Auto-submitting dropdowns are not usable by keyboard users.

Matthew.


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

Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

I like the way that the footer links rollover to black text on dark blue
background - very accessible... ;)

Matthew.


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

RE: [WSG] WCAG Samurai Errata

2007-06-08 Thread Frank Palinkas
Hi Matthew,

 

Thanks for your comments.

 

/* So what would happen on a page with 15 links above the form? Presumably a
keyboard user would tab through the first 10, then just down to the form,
through that, and then back to the last 5, then move onto any links after the
form. Not exactly expected behaviour. */

 

I always add a Skip Navigation button directly after the h1 topic enabling a
user to bypass both global and internal page links. This moves the focus to
the first subtopic. I use 11 as a starting guide, not as a rule.

 

/* I think it's been shown that just about all keys interfere with someone's
shortcuts, whether it's a browser, screenreader, foreign characters, or
whatever. */

 

Interesting. Please tell me where this info is shown? I'd like to know more.

 

Kind regards,

Frank

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Pennell
Sent: Friday, 08 June, 2007 8:26 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] WCAG Samurai Errata

 

On 08/06/07, Frank Palinkas [EMAIL PROTECTED] wrote:

/* Guideline 9.4: Do not attempt to create your own tab order. That
is a job for a browser and adaptive technology. */

When and where needed (in web forms for instance), I create a
tabindex order starting with the number 11 and proceed from there. This
usually bypasses the generic built-in browser tab order.


So what would happen on a page with 15 links above the form? Presumably a
keyboard user would tab through the first 10, then just down to the form,
through that, and then back to the last 5, then move onto any links after the
form. Not exactly expected behaviour. 

 

/* Guideline 9.5: Don't provide your own keyboard shortcuts. That is
a job for a browser or adaptive technology. */

I provide keyboard shortcuts for global navigation situated on each
web page. I cross-browser test to make sure each character I'm using for the
Alt + key shortcut doesn't interfere with generic browser shortcuts.

I think it's been shown that just about all keys interfere with someone's
shortcuts, whether it's a browser, screenreader, foreign characters, or
whatever. 

Matthew.


***
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] WCAG Samurai Errata

2007-06-08 Thread Kane Tapping
Hi ,

 - no noscript?
 I still use it to add a submit button to dropdowns which are otherwise 
 javascript driven - I thought I was doing a good thing! (Wah! :( )
 Hmm.. its in the introduction, but not in the document. Thats not 
 right, surely?

I took this one to mean that you should be writing your form in a 
accessible and non-js way first then use JS to HIJAX (
http://ajaxian.com/archives/hijax-graceful-degration) that version to 
provide enhanced useability.This way you get a perfectly useable form 
without JS and enhanced usability when it is enabled.

Kind Regards,

Kane Tapping
Web Standards Developer
Web and Content Management Services
Griffith University. 4111. Australia.
[EMAIL PROTECTED]
Phone: +61 (0)7 3735 7630



[EMAIL PROTECTED] wrote on 08/06/2007 04:19:08 PM:

 On Fri, 8 Jun 2007 15:22:36 +1000, Kane Tapping wrote:
  I have been reading with interest the WCAG Samurai Errata ( 
  http://wcagsamurai.org/errata/intro.html ) and am suprised to have not 

  found it discussed on WSG as of yet.
 
 Thank you! I missed this announcement, somehow. What a refreshing read! 
 :)
 
 Points
 
 - no noscript?
 I still use it to add a submit button to dropdowns which are otherwise 
 javascript driven - I thought I was doing a good thing! (Wah! :( )
 Hmm.. its in the introduction, but not in the document. Thats not 
 right, surely?
 
 - Guideline 10
 Do not add non-link, printable characters (surrounded by spaces or 
 not) between adjacent links unless the semantics of the document 
 naturally would include such characters.
 Am I right in interpeting this as that we *don't* need to make sure 
 there are extra characters between links! Wow! Cool! :)
 
 :reads more:
 
 warmly,
 Lea
 -- 
 Lea de Groot
 Elysian Systems
 Brisbane, Australia
 
 
 ***
 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] WCAG Samurai Errata

2007-06-08 Thread Lea de Groot
On Fri, 8 Jun 2007 07:27:46 +0100, Matthew Pennell wrote:
 Auto-submitting dropdowns are not usable by keyboard users.

More information, please? :)

warmly,
Lea
-- 
Lea de Groot
Elysian Systems
Brisbane, Australia


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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Lea de Groot
On Fri, 8 Jun 2007 16:49:00 +1000, Kane Tapping wrote:
 I took this one to mean that you should be writing your form in a 
 accessible and non-js way first then use JS to HIJAX (
 http://ajaxian.com/archives/hijax-graceful-degration) that version to 
 provide enhanced useability.This way you get a perfectly useable form 
 without JS and enhanced usability when it is enabled.

I have considered that, and there are very, very few places where I 
would use a noscript element - the 'select dropdown' is probably the 
only *common* implementation I do.
The only problem with the 'make it plain, then pretty it with JS' 
approach is the Redraw Problem.
The first thing to bear in mind is that for the majority of 
applications more than 95% of your visitors will be using a plain 
vanilla graphical browser.
While a web page/app must be accessiible, it must also service your 
majority audience *perfectly*.
Having elements pop in and out on a slow connection is very confusing 
for Joe Public, and if its a page or site that will take their money 
its important Not to make them feel in anyway insecure on what is 
happening.
Because of this, I've made a specific decision that, rather than having 
a: 
 select + button, then use JS to remove the button and add an onclick, 
I have: 
 select + noscripted-button, and use js to add an onclick 
(actually, I think its an onchange - I'd have to go look).
This gives an almost identical experience to non-js browsers and a 
perfect experience to Joe Public's vanilla browser, and avoids elements 
popping in and out on the screen.
If its below the fold it doesn't matter so much
If the element is very visible at the top of the page then its 
important.
It would probably be worthwhile to consider browsers that do js, but 
don't support onchange but I haven't looked into it - its a pretty old 
element.

IMHO

warmly,
Lea
-- 
Lea de Groot
Elysian Systems
Brisbane, Australia


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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

This is an interesting one:

If images must be used for list bullets, do so only using CSS, as with ul
{ list-style: url(arrow.gif) disc }

Like a lot of people, I use CSS background-image to place a graphic at the
top left of LI items, with a bit of left padding so the text makes space.
What is the justification for this new 'rule' - how does background-image
negatively affect accessibility in a way that graphical list-style doesn't?

Matthew.


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

RE: [WSG] WCAG Samurai Errata

2007-06-08 Thread Jason Turnbull
Matthew Pennell wrote:
 I think it's been shown that just about all keys interfere with someone's
shortcuts, 
 whether it's a browser, screenreader, foreign characters, or whatever.

Frank Palinkas wrote:
 Interesting. Please tell me where this info is shown? I'd like to know
more.

Some Info:
http://www.wats.ca/show.php?contentid=32 
http://www.wats.ca/show.php?contentid=43
http://juicystudio.com/article/firefox2-accesskeys.php

Regards
Jason



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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

On 08/06/07, Lea de Groot [EMAIL PROTECTED] wrote:


On Fri, 8 Jun 2007 07:27:46 +0100, Matthew Pennell wrote:
 Auto-submitting dropdowns are not usable by keyboard users.

More information, please? :)



Auto-submit dropdowns mostly work by triggering the onchange event of the
SELECT element. This is fired when you select a different OPTION using a
mouse - however, if you are using a keyboard, it is fired when you press the
down arrow to move through the list. You therefore can't select anything but
the first OPTION, as it triggers the onchange event and submits the form.

Matthew.


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

RE: [WSG] Use of PDFs - Accessibility issues

2007-06-08 Thread Web Dandy Design
Hi,

Have you tried RiverDocs: http://www.riverdocs.com/index.htm. You can sign
up for a free evaluation licence for 14 days (no restrictions):
http://www.riverdocs.com/product/download/index.html. 

The price is £399. If you are a member of GAWDS the cost is £299 until 22
June.

Regards,

Elaine
Web Designer
http://www.webdandy.co.uk

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Frank Palinkas
Sent: 08 June 2007 06:19
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] Use of PDFs - Accessibility issues

Hi Michael,

Not sure if this will help you, but on occasion I've been presented with
.pdf
files to convert to (x)html for web-based tech docs. I do this manually by
creating templates in the Visual Studio 2005 markup source code editors, and
then copy and paste the content from the .pdf's. This way I have complete
control over the structure, presentation and behavior of the resulting web
doc.

This is ok if the .pdf's haven't been secured by a user name and password.
If
they have, then I'm outta luck as the copy/paste routine won't work.
Personally, I wouldn't trust any .pdf to .html conversion app. If they
exist,
I feel it would create more work than what I already have to do in this
scenario.

Kind regards,

Frank M. Palinkas
Microsoft M.V.P. - Windows Help
W3C HTML Working Group (H.T.M.L.W.G.) - Invited Expert
M.C.P., M.C.T., M.C.S.E., M.C.D.B.A., A+   
Senior Technical Communicator 
Web Standards  Accessibility Designer 

website: http://frank.helpware.net 
email: [EMAIL PROTECTED] | [EMAIL PROTECTED]
 
Member: 
Society for Technical Communications (S.T.C.) 
Guild of Accessible Web Designers (G.A.W.D.S.)
Web Standards Group (W.S.G.) 

Supergroup Trading Ltd. 
Sandhurst, Gauteng, South Africa 
website: http://www.supergroup.co.za

Work:   +27 011 523 4931 
Home:   +27 011 455 5287 
Fax:    +27 011 455 3112 
Mobile: +27 074 109 1908


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael MD
Sent: Friday, 08 June, 2007 6:41 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Use of PDFs - Accessibility issues



 Here is the thread that discussed making PDFs accessible:
 http://www.mail-archive.com/wsg@webstandardsgroup.org/msg28067.html

 The effort involved in creating the PDFs in an accessible format will be
 significant.

 Handheld users frequently avoid opening PDFs since they are often a large
 file size - bandwidth and cost being the limiting factors here.


how many mobile phone can read pdf? .. I suspect not many yet  ... (I have 
yet to see one which can)

btw does anyone know of anything that can export html (even if it is crap 
html) from a pdf ?

(apart from Acrobat Pro itself  - I can't justify spending that sort of 
money for just the occasional attempt to extract useful content from that 
occasasional pdf sent by clueless media publicists which would otherwise 
just be deleted)





***
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]
***




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



RE: [WSG] WCAG Samurai Errata

2007-06-08 Thread Frank Palinkas
Thanks Jason,

That's what I'm looking for. Also, I think Gez Lemon's comment about letting
a user set their own access keys makes a lot of sense to me.

Kind regards,

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jason Turnbull
Sent: Friday, 08 June, 2007 9:53 AM
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] WCAG Samurai Errata

Matthew Pennell wrote:
 I think it's been shown that just about all keys interfere with someone's
shortcuts, 
 whether it's a browser, screenreader, foreign characters, or whatever.

Frank Palinkas wrote:
 Interesting. Please tell me where this info is shown? I'd like to know
more.

Some Info:
http://www.wats.ca/show.php?contentid=32 
http://www.wats.ca/show.php?contentid=43
http://juicystudio.com/article/firefox2-accesskeys.php

Regards
Jason



***
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] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

Another interesting one, under Guideline 12 (although it actually relates to
WCAG 13.8):

Do not place distinguishing information at the beginning of headings,
paragraphs, lists, etc. unless document semantics warrant it.

I'd always interpreted that guideline as being a nod to both usability and
cognitive disability, with the added bonus that it means screenreader users
don't have to listen to the entire sentence before being in a position to
decide if it is relevant to them - for example:

Bad: Read more information and download supporting material on California
Forest Fires
Good: Californian Forest Fires - more information and support material

So why is this bad, and why does the Samurai's new 'rule' seem to be
recommending that we actively avoid putting distinguishing information at
the start of sentences? Doesn't make sense to me.

Matthew.


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

RE: [WSG] Print style sheets

2007-06-08 Thread michael.brockington
Generally speaking, my advice would be to use print styles as part of
the main stylesheet setup (possibly but not necessarily a separate CSS
file)
By tying your print-friendly styles to a script of any kind, you are
forcing the user to find that link and be able to use it, in order to
gain the benefit. It does depend a lot on what the site looks like to
begin with, but try turning the question around, and asking yourself
what the user would gain by being able to print the site exactly as it
looks on the screen?

Regards,
Mike
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Lucien Stals
 Sent: Friday, June 08, 2007 6:18 AM
 To: WSG
 Subject: [WSG] Print style sheets
 
 
 Hi all,
 
 I'd written a print style sheet for a site I'd done  (
 http://www.swin.edu.au/ads/ltshowcase/inspire/presentations.html  ),
 but the feedback I got was that nobody knew it was there (unless they
 printed the page).
 
 So I hit google for some suggestions on how best to do this. This has
 lead to more confusion.
 
 One site I read suggested that print style sheets can confuse users
 when what comes out of the printer differs significantly from 
 what they
 saw on the page. This is true in my case where I hide the 
 navigation and
 some background images. I also change the font and justification to
 better suit print.
 
 So do people here think it's a good idea to have a print style sheet
 that differs from the screen style sheet? 
 
 In the end, I used some javascript to allow users to switch 
 between two
 style sheets on the screen. One is designed for the screen, the other
 designed for print. This way, if they print the page, they 
 get what they
 see.
 
 What do people think about this approach. (If you are unclear from my
 description about how this works, just visit the page and toggle the
 print friendly view link near the top of the page).
 
 My approach has caused me a further problem:
 
 Because I used a link to trigger the script, clicks get added to the
 browsers history, when technically the user hasn't left the page. Any
 suggestions for how to get around this? Should I have used a select
 list?
 
 Regards,
 
 Lucien.
  
 -- 
 
 Lucien Stals
 Multimedia/Web Developer
 Academic Development and Support
 Swinburne University of Technology
 PO Box 218 Hawthorn, 3122, Australia
 email: [EMAIL PROTECTED]
 telephone: +61 3 9214 4474
 office: AD223
 
 
 Swinburne University of Technology
 CRICOS Provider Code: 00111D
 
 NOTICE
 This e-mail and any attachments are confidential and intended 
 only for the use of the addressee. They may contain 
 information that is privileged or protected by copyright. If 
 you are not the intended recipient, any dissemination, 
 distribution, printing, copying or use is strictly 
 prohibited. The University does not warrant that this e-mail 
 and any attachments are secure and there is also a risk that 
 it may be corrupted in transmission. It is your 
 responsibility to check any attachments for viruses or 
 defects before opening them. If you have received this 
 transmission in error, please contact us on +61 3 9214 8000 
 and delete it immediately from your system. We do not accept 
 liability in connection with computer virus, data corruption, 
 delay, interruption, unauthorised access or unauthorised amendment.
 
 Please consider the environment before printing this email.
 
 
 ***
 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] WCAG Samurai Errata

2007-06-08 Thread Stuart Foulstone
Hi,

I think the as with here means as example.  The point is the use of
CSS to avoid using an img tag in the HTML.

The fact that they give the most sensible way of doing this as an example 
does not preclude you using other CSS to acheve the same result.

Stuart.

On Fri, June 8, 2007 9:21 am, Matthew Pennell wrote:
 This is an interesting one:

 If images must be used for list bullets, do so only using CSS, as with ul
 { list-style: url(arrow.gif) disc }

 Like a lot of people, I use CSS background-image to place a graphic at the
 top left of LI items, with a bit of left padding so the text makes space.
 What is the justification for this new 'rule' - how does background-image
 negatively affect accessibility in a way that graphical list-style
 doesn't?

 Matthew.


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


-- 
Stuart Foulstone.
http://www.bigeasyweb.co.uk
BigEasy Web Design
69 Flockton Court
Rockingham Street
Sheffield
S1 4EB

Tel. 07751 413451


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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

On 08/06/07, Stuart Foulstone [EMAIL PROTECTED] wrote:


I think the as with here means as example.  The point is the use of
CSS to avoid using an img tag in the HTML.

The fact that they give the most sensible way of doing this as an example
does not preclude you using other CSS to acheve the same result.



That would make sense - it could probably do with being reworded so as to
avoid confusion.

Matthew,


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

Re: [WSG] Use of PDFs - Accessibility issues

2007-06-08 Thread Nick Roper
Many thanks to everyone for posts and personal replies on this thread. I 
appreciate you all taking the time to respond.


The opinions that most people have kindly put forward are very similar 
to my own, but I guess that I wanted to make sure that I wasn't about to 
give an inappropriate 'knee-jerk' response to the client, or was unaware 
of options that might be appropriate. I intend making a counter-proposal 
along the lines that have been suggested and will let you know what happens.


Regards,

Nick

Andrew Maben wrote:


On Jun 7, 2007, at 6:16 PM, Nick Gleitzman wrote:


Nick Roper wrote:

Just to confirm, the recommendation from the agency is to replace 
existing html content with PDF version, not to provide PDFs as an 
additional alternative.


Nick, you've made it fairly clear that your question is about 
accessiblity in PDFs, rather than whether or not it's a good idea to 
use them - but I'm afraid the most common answer you're likely to get 
is going to be: don't rely on them exclusively.


The web is for HTML; the ability to deliver other file types is 
possible, but not the best option if accessiblity is desired. As 
printable alternatives, sure, I guess (but what's wrong with a good 
print style sheet?) - but I'm thinking of a number of Aust Govt sites 
which insist on delivering critical info as PDFs and even Word docs, 
which I find astonishingly short-sighted, as well as probably an abuse 
of accessiblity guidelines, if not legislation. What if I don't have 
Word installed (and why should I?)?


The site may certainly need an IA overhaul, if it's been mangled over 
time by too many cooks - but that's no reason to stop using HTML in 
favour of PDF, surely. I think the site owners should have it pointed 
out to them that the agency's recommendations are simply out of touch 
with what's needed.


 From WCAG Samurai Errata:

*We ban most PDFs*: PDFs that should be HTML are banned unless they are 
accompanied by HTML. All other PDFs have to be tagged.


Andrew

 


109B SE 4th Av
Gainesville
FL 32601

Cell: 352-870-6661

http://www.andrewmaben. http://www.andrewmaben.com/net
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]

/In a well designed user interface, the user should not 
need //instructions./




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


--
Nick Roper
partner
logical elements


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



Re: [WSG] Use of PDFs - Accessibility issues

2007-06-08 Thread Andrew Maben


On Jun 7, 2007, at 6:16 PM, Nick Gleitzman wrote:


Nick Roper wrote:

Just to confirm, the recommendation from the agency is to replace  
existing html content with PDF version, not to provide PDFs as an  
additional alternative.


Nick, you've made it fairly clear that your question is about  
accessiblity in PDFs, rather than whether or not it's a good idea  
to use them - but I'm afraid the most common answer you're likely  
to get is going to be: don't rely on them exclusively.


The web is for HTML; the ability to deliver other file types is  
possible, but not the best option if accessiblity is desired. As  
printable alternatives, sure, I guess (but what's wrong with a good  
print style sheet?) - but I'm thinking of a number of Aust Govt  
sites which insist on delivering critical info as PDFs and even  
Word docs, which I find astonishingly short-sighted, as well as  
probably an abuse of accessiblity guidelines, if not legislation.  
What if I don't have Word installed (and why should I?)?


The site may certainly need an IA overhaul, if it's been mangled  
over time by too many cooks - but that's no reason to stop using  
HTML in favour of PDF, surely. I think the site owners should have  
it pointed out to them that the agency's recommendations are simply  
out of touch with what's needed.


From WCAG Samurai Errata:

We ban most PDFs: PDFs that should be HTML are banned unless they  
are accompanied by HTML. All other PDFs have to be tagged.


Andrew

109B SE 4th Av
Gainesville
FL 32601

Cell: 352-870-6661

http://www.andrewmaben.net
[EMAIL PROTECTED]

In a well designed user interface, the user should not need  
instructions.





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

Re: [WSG] Use of PDFs - Accessibility issues

2007-06-08 Thread Gaspar

I thing PDF may be delivery as a complement for save the doc to our computer.
And should not be the single format for a web document, only if theres
no other better way to display it.

I thing there is no format to the web more complaint than a html web page.

I like PDF when i want to save  the dock to my computer to print or
read later. But even read later i prefer to go to the web page, it
could have been updated or have more useful comments.

So i thing that marketing agency dont know nothing about web or web
accessbility. If they know they  should tell that should recommend PDF
as a complement and not to replace HTML.

Gaspar

On 08/06/07, Andrew Maben [EMAIL PROTECTED] wrote:



On Jun 7, 2007, at 6:16 PM, Nick Gleitzman wrote:

Nick Roper wrote:


Just to confirm, the recommendation from the agency is to replace existing
html content with PDF version, not to provide PDFs as an additional
alternative.

Nick, you've made it fairly clear that your question is about accessiblity
in PDFs, rather than whether or not it's a good idea to use them - but I'm
afraid the most common answer you're likely to get is going to be: don't
rely on them exclusively.

The web is for HTML; the ability to deliver other file types is possible,
but not the best option if accessiblity is desired. As printable
alternatives, sure, I guess (but what's wrong with a good print style
sheet?) - but I'm thinking of a number of Aust Govt sites which insist on
delivering critical info as PDFs and even Word docs, which I find
astonishingly short-sighted, as well as probably an abuse of accessiblity
guidelines, if not legislation. What if I don't have Word installed (and why
should I?)?

The site may certainly need an IA overhaul, if it's been mangled over time
by too many cooks - but that's no reason to stop using HTML in favour of
PDF, surely. I think the site owners should have it pointed out to them that
the agency's recommendations are simply out of touch with what's needed.

From WCAG Samurai Errata:

We ban most PDFs: PDFs that should be HTML are banned unless they are
accompanied by HTML. All other PDFs have to be tagged.

Andrew


109B SE 4th Av
Gainesville
FL 32601

Cell: 352-870-6661

http://www.andrewmaben.net
[EMAIL PROTECTED]

In a well designed user interface, the user should not need instructions.


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



--
Make it simple for the people
--
http://www.artideias.com


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



RE: [WSG] WCAG Samurai Errata

2007-06-08 Thread michael.brockington
 If you use JS to write specific styles to the document, there 
 should be
 nothing popping in and out.
 
 ---
 Regards,
 Thierry | www.TJKDesign.com


How do you work that one out? Javascript cannot run until the page has
(mostly) loaded, so I can vouch for getting a 'flash of extra content'
on many of my pages. Since the hidden content cannot be re-enabled
without JS on, I have to make the default appearance to be 'visible',
then hide it asap.

Mike


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



[WSG] JAWS Screen Reader Demo - Monday 25 June 2007

2007-06-08 Thread Steve Green
We are doing another free JAWS screen reader demo on the afternoon of Monday
25 June 2007. A couple of the places are already booked but there are still
six left. We limit the demo to 8 people so book early.

The demo starts at 1:30pm and a free light buffet is available from 12:30
for those who want to come early. We are scheduled to finish at 5:30pm but
you are welcome to stay afterwards to get some hands-on experience or look
at some more websites.

If anyone would like to attend this demo or a future one please fill in the
form at http://www.accessibility.co.uk/free_jaws_demo.htm.

Steve Green
Director
Test Partners Ltd / First Accessibility
www.testpartners.co.uk
www.accessibility.co.uk



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



Re: [WSG] WCAG Samurai Errata

2007-06-08 Thread Matthew Pennell

On 08/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


How do you work that one out? Javascript cannot run until the page has
(mostly) loaded, so I can vouch for getting a 'flash of extra content'
on many of my pages. Since the hidden content cannot be re-enabled
without JS on, I have to make the default appearance to be 'visible',
then hide it asap.



You can run scripts as soon as the DOM has loaded, so you very rarely have
to put up with the flash of non-js content - that only really happens if you
use the window.onload event.

Matthew.


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

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

2007-06-08 Thread SHAPCOTT, Teale
Hello, 

Thank you for emailing me. 

I am currently out of the office on a team building activity and will return on 
Tuesday, June 12th.   Please note that emails sent to my mail box will not be 
actioned until this date.  If you require urgent assistance or action, please 
contact me on 040 442 4399. 

Many thanks
Teale. 

---
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its 
related entities Suncorp. 

Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 
55  or at suncorp.com.au.

The content of this e-mail is the view of the sender or stated author and does 
not necessarily reflect the view of Suncorp. The content, including 
attachments, is a confidential communication between Suncorp and the intended 
recipient. If you are not the intended recipient, any use, interference with, 
disclosure or copying of this e-mail, including attachments, is unauthorised 
and expressly prohibited. If you have received this e-mail in error please 
contact the sender immediately and delete the e-mail and any attachments from 
your system.

If this e-mail constitutes a commercial message of a type that you no longer 
wish to receive please reply to this e-mail by typing Unsubscribe in the 
subject line.




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



Re: [WSG] Use of PDFs - Accessibility issues

2007-06-08 Thread Dennis Lapcewich



[EMAIL PROTECTED] wrote on 06/07/2007 08:04:01 AM:

 Anyway, to get to the point, the customer has now been advised by a
 marketing agency that the site should be reduced in size to approx 45
 key pages, and that the majority of content for things such as
 conference room specification and rates, bedroom specs and rates, menus,
 events, golf rates, membership rates etc, should be made available in
 PDF form instead of the html pages that are on the current site.


I'm curious.  Has the marketing agency ever been questioned as to *why* the
web content should be converted from HTML to PDFs?  What are the business
reasons for the recommendation?  What are the usability reasons for this
recommendation?  Is there an ultimate cost savings in creation and
maintenance of the site by using PDFs for the majority of the content?
Will there be an improvement in accessibility for web users by converting
the content to PDFs?  What about those web users who may not have a PDF
reader installed on their computers?  (Yes, this last question may seem
nutty but how times have their been discussions about web users who
deliberately disable Flash content for whatever reasons?  The concept could
be the same for folks who disable PDF access as well.)

Has the marketing company offered cost savings in providing the web content
as PDFs instead of HTML?  Have they compared costs when it comes taking
content and publishing it as accessible HTML vs creating an accessible
content (say in Word or some other accessible document) and converting that
to an accessible PDF for publication on the site?  Will there be a
consistency in making sure all the accessible PDFs are created using the
exact same methods and procedures?

It sounds to me that the marketing agency is pushing marketing hype for its
own benefit and not creating and easy to use, and accessible content by
following the KISS Principle.

Dennis



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



RE: [WSG] WCAG Samurai Errata

2007-06-08 Thread Thierry Koblentz
 On Behalf Of David Dorward

  http://www.tjkdesign.com/articles/toggle_elements.asp
 
 Despite the claims of the article, using document.write() will not
 work in XHTML[1] documents. Browsers don't support it in XHTML mode.

You mean served with an application/xhtml+xml MIME type, but AFAIK, the
article doesn't claim this. 
It simply says: This script should work in HTML and XHTML documents. 
As a side note, it also says:
Earlier versions of this script did not use document.write(), I was using
the DOM to plug the stylesheets in the HEAD element. Unfortunately, setting
the rel attribute of the LINK element makes Safari go blank and STYLE
fails in IE Win. So, I decided to go with what works!

Anyway, IMO people who know enough to serve an XHTML document with a
different MIME type depending on browsers, should be more concerned by my
use of innerHTML in there than by document.write() ;-)

---
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] WCAG Samurai Errata

2007-06-08 Thread Al Sparber
From: Thierry Koblentz [EMAIL PROTECTED]
uments. 
 As a side note, it also says:
 Earlier versions of this script did not use document.write(), I was using
 the DOM to plug the stylesheets in the HEAD element. Unfortunately, setting
 the rel attribute of the LINK element makes Safari go blank and STYLE
 fails in IE Win. So, I decided to go with what works!

That's a wise decision in this business. It might not win points in a standards 
forum, but if the goal is a working application with reasonable backwards 
compatibility, I'm with you.

-- 
Al Sparber - PVII
http://www.projectseven.com
Extending Dreamweaver - Nav Systems | Galleries | Widgets
Authors: 42nd Street: Mastering the Art of CSS Design




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



[WSG] Paul Chandley/HeadOffice/DHS is out of the office.

2007-06-08 Thread Paul . Chandley

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

I will respond to your message when I return.

For RRHACS web publishing requests, please contact the Web Services Team -
(9096 2879, [EMAIL PROTECTED]).




_

This email contains confidential information intended only for the person named 
above and may be subject to legal privilege. If you are not the intended 
recipient, any disclosure, copying or use of this information is prohibited. 
The Department provides no guarantee that this communication is free of virus 
or that it has not been intercepted or interfered with. If you have received 
this email in error or have any other concerns regarding its transmission, 
please notify [EMAIL PROTECTED]
_



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



Re: [WSG] Print style sheets

2007-06-08 Thread Christian Montoya

On 6/7/07, Lucien Stals [EMAIL PROTECTED] wrote:


Hi all,

I'd written a print style sheet for a site I'd done  (
http://www.swin.edu.au/ads/ltshowcase/inspire/presentations.html  ),
but the feedback I got was that nobody knew it was there (unless they
printed the page).

So I hit google for some suggestions on how best to do this. This has
lead to more confusion.

One site I read suggested that print style sheets can confuse users
when what comes out of the printer differs significantly from what they
saw on the page. This is true in my case where I hide the navigation and
some background images. I also change the font and justification to
better suit print.

So do people here think it's a good idea to have a print style sheet
that differs from the screen style sheet?


Yes!


In the end, I used some javascript to allow users to switch between two
style sheets on the screen. One is designed for the screen, the other
designed for print. This way, if they print the page, they get what they
see.

What do people think about this approach. (If you are unclear from my
description about how this works, just visit the page and toggle the
print friendly view link near the top of the page).


I definitely think it is important to let users know that the result
from printing the page will be different than what they see on screen,
only because a lot of users are used to wasting all their ink printing
web pages that do not have print stylesheets, and think this is the
norm. Whether it's a matter of explaining the feature to users or
showing it on-screen, it helps the users who don't know about it.


My approach has caused me a further problem:

Because I used a link to trigger the script, clicks get added to the
browsers history, when technically the user hasn't left the page. Any
suggestions for how to get around this? Should I have used a select
list?


Isn't this problem solved by putting return false; in the event
handler? Or am I missing something?

--
--
Christian Montoya
christianmontoya.net .. designtocss.com


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



Accessible auto-submit dropdowns [WAS: Re: [WSG] WCAG Samurai Errata]

2007-06-08 Thread Sander Aarts


Matthew Pennell schreef:
On 08/06/07, *Lea de Groot* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


On Fri, 8 Jun 2007 07:27:46 +0100, Matthew Pennell wrote:
 Auto-submitting dropdowns are not usable by keyboard users.

More information, please? :)


Auto-submit dropdowns mostly work by triggering the onchange event of 
the SELECT element. This is fired when you select a different OPTION 
using a mouse - however, if you are using a keyboard, it is fired when 
you press the down arrow to move through the list. You therefore can't 
select anything but the first OPTION, as it triggers the onchange 
event and submits the form.


In Firefox you can use your keyboard in such case, but at least IE and 
Opera will submit on the first option.


I've tried to write a script that offers auto submit, but still enables 
keyboard navigation. When a keyboard is used the submit is triggered on 
blur. In Opera hitting 'enter' can be used as well to submit as this is 
the browsers normal behaviour (in IE and Firefox hitting 'enter' only 
submits the form if the focus is on an input).



Here it is (autoSubmit() needs to be called on load):


   function autoSubmit() {
   if (!document.getElementById) return;
  
   var selectNav = document.getElementById('selectNav');

   if (!selectNav) return
  
   selectNav.onfocus = function() {

   this.origVal = this.value;
   }
   selectNav.onchange = function() {
   if (this.newVal) this.origVal = this.newVal;
   this.newVal = this.value;
   }
   selectNav.onblur = selectNav.onclick = function() {
   if (this.newVal  this.newVal != this.origVal) {
   this.form.submit();
   }
   }
   }


   form
   select name=selectNav id=selectNav
   option value=/option
   option value=1one/option
   option value=2two/option
   option value=3three/option
   /select
   form


I briefly tested it in IE7, Fx2 and Op9, so it may need some tweaking 
for other browser. In real life there should (initially) be a submit 
button as well of course to grant access for those who have disabled 
JavaScript.

Hopefully it is usefull to someone.

cheers,
Sander



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