Re: [WSG] WCAG Samurai Errata

[Keryx Web]

Tee G.Peng wrote:


Hi, I finally got a chance to read the WCAG Samurai Errata. Maybe 
something to do with my understanding in English, I see there is 
autority tone in there.


Guideline 11, bullet point 3, point 4: "I really mean this..."


Not so convincing, perhaps?


Lars Gunther


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

Re: [WSG] WCAG Samurai Errata

[Alastair Campbell]

Oops, Joe's just posted the comments email address: samurai at the 
domain wcagsamurai.org


Apologies,

-Alastair



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

Re: [WSG] WCAG Samurai Errata

[Alastair Campbell]

Steve Green wrote:

The process for commenting is a bit shambolic, and it is not clear that
comments are particularly welcome. There is no stated process, so people
have been commenting in various places in the blogs


If you check the various blogs, you'll see Joe has been following them
closely (probably via technorati), and he will take in comments by email
as well (his name @joeclark.org).

I've also been looking through things, and will post some more comments
on the reviewsamurai blog.

Cheers,

-Alastair






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

RE: [WSG] WCAG Samurai Errata

[Steve Green]

The Samurai Errata have no official status so there are no certificates or
validators. They have "authority tone" because that's Joe Clark's style, not
because they have any authority. They are some good ideas written by some
clever people (or one clever person if you believe some of the theories).

I suspect they are hoping that the W3C adopt the Errata, which would be a
good thing in my opinion. If they do not, I suspect the Errata will have
about zero uptake in the commercial world. It's hard enough to explain the
need for accessibility without explaining that you're going to ignore the
only globally accepted set of guidelines in favour of an unofficial set
written by a self-appointed group of people, all but one of whom are
unknown.

I have submitted my comments to the Samurai, and they can be seen at
http://www.accessibility.co.uk/wcag_samurai_errata.htm

The process for commenting is a bit shambolic, and it is not clear that
comments are particularly welcome. There is no stated process, so people
have been commenting in various places in the blogs of the two peer
reviewers so they are very fragmented.

Steve

 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tee G.Peng
Sent: 11 June 2007 07:12
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] WCAG Samurai Errata


On Jun 7, 2007, at 10:22 PM, 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.
>

Hi, I finally got a chance to read the WCAG Samurai Errata. Maybe  
something to do with my understanding in English, I see there is  
autority tone in there. Overall impression is it's a good thing, it  
seems the standard is higher (maybe it was because I am always so  
confused with the WCAG ambiguous used of language thus never able to  
fully understand) in claiming an accessible site.

Curious, is there an entity to issue certificate or safegaurd what  
sites can really claim to be WCAG Samurai Errata compliance? Will the  
validators be update to cater  for Samurai Errata? Or just our  
judegement with human eyes and best parctise be the call?

Lastly, I did not aware we can do this ? Did a brief reading in CSS 3  
spec and I tried testing it in Safari, Firefox and Opera  (thought  
one of the browsers has already supported some of CSS3 elements) but  
none of them work.
"
If images must be used for list bullets, do so only using CSS, as  
with ul { list-style: url("arrow.gif") disc }"


tee


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

[Philippe Wittenbergh]

On Jun 11, 2007, at 3:12 PM, Tee G.Peng wrote:

Lastly, I did not aware we can do this ? Did a brief reading in CSS  
3 spec and I tried testing it in Safari, Firefox and Opera   
(thought one of the browsers has already supported some of CSS3  
elements) but none of them work.

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


That works perfectly fine in all 3 mentioned browsers. Even IE 7  
should work reasonably.
 You'll see an image 'arrow.gif', and if you have display of images  
turned off in your browser, you'll a disc. It is a good practice.


CSS 1/CSS 2.1 syntax btw.
You could also write ul { list-style: disc url('arrow.gif');}

Philippe
---
Philippe Wittenbergh






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

Re: [WSG] WCAG Samurai Errata

[Tee G . Peng]

On Jun 7, 2007, at 10:22 PM, 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.




Hi, I finally got a chance to read the WCAG Samurai Errata. Maybe  
something to do with my understanding in English, I see there is  
autority tone in there. Overall impression is it's a good thing, it  
seems the standard is higher (maybe it was because I am always so  
confused with the WCAG ambiguous used of language thus never able to  
fully understand) in claiming an accessible site.


Curious, is there an entity to issue certificate or safegaurd what  
sites can really claim to be WCAG Samurai Errata compliance? Will the  
validators be update to cater  for Samurai Errata? Or just our  
judegement with human eyes and best parctise be the call?


Lastly, I did not aware we can do this ? Did a brief reading in CSS 3  
spec and I tried testing it in Safari, Firefox and Opera  (thought  
one of the browsers has already supported some of CSS3 elements) but  
none of them work.

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



tee


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

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

[Darren West]

Maybe then a tip could be added to explain that functionality

something like:



 Internet Explorer users can use Alt+Down Arrow to open the SELECT element
and then use the arrow keys to navigate within it without triggering the
onChange event. One of our JAWS users does this as a matter of course for
every combobox because he cannot know if they have an onChange event
attached or not. However, I suspect that most people will not know that you
can do this even if they routinely use keyboard navigation.

Steve


 --
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
Behalf Of *Sander Aarts
*Sent:* 09 June 2007 05:30
*To:* wsg@webstandardsgroup.org
*Subject:* Accessible auto-submit dropdowns [WAS: Re: [WSG] WCAG Samurai
Errata]


Matthew Pennell schreef:

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.


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

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 ).


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();
}
}
}





one
two
three




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

***
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: Accessible auto-submit dropdowns [WAS: Re: [WSG] WCAG Samurai Errata]

[Steve Green]

Internet Explorer users can use Alt+Down Arrow to open the SELECT element
and then use the arrow keys to navigate within it without triggering the
onChange event. One of our JAWS users does this as a matter of course for
every combobox because he cannot know if they have an onChange event
attached or not. However, I suspect that most people will not know that you
can do this even if they routinely use keyboard navigation.
 
Steve
 

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Sander Aarts
Sent: 09 June 2007 05:30
To: wsg@webstandardsgroup.org
Subject: Accessible auto-submit dropdowns [WAS: Re: [WSG] WCAG Samurai
Errata]



Matthew Pennell schreef: 

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.


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

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 ).


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();
}
}
}





one
two
three




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


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

[Sander Aarts]

Matthew Pennell schreef:
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.


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


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 ).



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();
   }
   }
   }


   
   
   
   one
   two
   three
   
   


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

Re: [WSG] WCAG Samurai Errata

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

RE: [WSG] WCAG Samurai Errata

[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

[David Dorward]

On 8 Jun 2007, at 16:22, Thierry Koblentz wrote:
The idea is not to parse the tree looking for an element to hide,  
but rather
use document.write() to write CSS declaration(s) that'll hide that  
element

right from the start.



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.



[1] XHTML served as text/html doesn't count, and using this technique  
with such documents is inviting trouble if the document is ever  
served with the correct content type


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

[Thierry Koblentz]

> On Behalf Of [EMAIL PROTECTED]

> > If you use JS to write specific styles to the document, there
> > should be
> > nothing "popping in and out".
> 
> 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.

The idea is not to parse the tree looking for an element to hide, but rather
use document.write() to write CSS declaration(s) that'll hide that element
right from the start.
Check the solution below to see that there is a lateral jump due to links
that are added once the document is done loading, but that there is no
vertical jump due to the hiding of the DDs.
http://www.tjkdesign.com/articles/toggle_elements.asp

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

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

RE: [WSG] WCAG Samurai Errata

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

RE: [WSG] WCAG Samurai Errata

[Thierry Koblentz]

> On Behalf Of Lea de Groot
> 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.

If you use JS to write specific styles to the document, there should be
nothing "popping in and out".

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

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

[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

[Stuart Foulstone]

Hi,

I think you may be misunderstanding what is meant by "distiguishing"
information.

If you have a number of headers (or whatever) concerning "Californian
Fires", say,


Californian Forest Fires - introduction.

Californian Forest Fires - more information.


The bit that distinguishes the headings (one from another) is then the
second bit after "Californian Forest Fires", as you have in your "Good"
example.

I think the confusion is that this then allows the user to "distinguish"
the subject matter (and hence relevance) from the first bit of the
heading, "Californian Forest Fires".

More semantics I'm afraid.

Stuart


On Fri, June 8, 2007 9:39 am, Matthew Pennell wrote:
> 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]
> ***


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

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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[Frank Palinkas]

Hi Kane,

 

If it’s of help:

 

/* 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.

 

/* 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.

 

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


 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kane Tapping
Sent: Friday, 08 June, 2007 7:23 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] WCAG Samurai Errata

 



Hi,

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. 

It raises many discussion points two of which mirror my own personal
opinion... 

Guideline 9.4: Do not attempt to create your own tab order. That is a job for
a browser and adaptive technology. 
Guideline 9.5: Don’t provide your own keyboard shortcuts. That is a job for a
browser or adaptive technology.

I have always found these priority three guidelines to be counter productive
because they often conflict with the built-in navigation controls from
browsers and screen readers making the website harder to use by those you are
trying to help by following the guidelines. 

What is your opinion on the errata ? 

Kind Regards,

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



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

[WSG] WCAG Samurai Errata

[Kane Tapping]

Hi,

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.

It raises many discussion points two of which mirror my own personal 
opinion...

Guideline 9.4: Do not attempt to create your own tab order. That is a job 
for a browser and adaptive technology.
Guideline 9.5: Don’t provide your own keyboard shortcuts. That is a job 
for a browser or adaptive technology.

I have always found these priority three guidelines to be counter 
productive because they often conflict with the built-in navigation 
controls from browsers and screen readers making the website harder to use 
by those you are trying to help by following the guidelines.

What is your opinion on the errata ? 

Kind Regards,

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



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